Re: [RFC PATCH] build dominator tree and dominance frontier fast!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 2, 2018 at 11:17 AM, Dibyendu Majumdar
<mobile@xxxxxxxxxxxxxxx> wrote:
>
> Is this patch something I could try out in my repo - i.e. does it
> change the SSA gen or is it just a preparatory patch?

No, this patch does not change any SSA gen. That is for the follow up
patch. This patch only build the necessarily data structure to help the
SSA conversion. In particular, the dominator tree and dominance frontier.

The dominator tree can help quickly answer the question that if block A
will dominate block B. The dominance frontier tells you where is the boundary
of the dominance ends. We need to insert phi nodes in those boundary during
SSA conversion.

>> BTW, I really appreciate if some one can write some validation function
>> to double check the output dominator tree and DF is correct and bug free.
>>
>
> I would like to understand the whole simplification phase and review /
> participate / test it, but I struggle with the code a bit. Partly
> because I cannot visualize what is going on - and the use of unions
> makes it hard to follow even with a debugger. Any advice on how best
> to get started with this? Of course I probably need to write one

I have some idea in the project-ideas.md is relate to your frustration.
I can explain a little bit more detail.

* debug: optimization step by step log

I think one of problem hard to visualize what is going on is that,
we can't see what exactly is changed. The code optimization is a
make change to the instruction.

If we can add some debug log to show the trace of the change.
Kind of emit a instruction level diff on the IR.  It will hep us understand
exactly what changed and why.

That is a first step towards understanding what is going on.
Visibility.

* debug: fancy animation of CFG

This can be build on top of the diff change. Generate as some
some animation highlight the change make to the IR.

Pretty color etc.


> myself to really understand it - but short of that, how can I best
> understand what is going on here?

I would start with debug mode logs.

Gdb also helps. You can use gdb to "call show_instruction(insn)"
to show some IR if you are wondering what is the current IR.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux