[LLVMdev] Passes propose passes

[Carl-Philip Hänsch]

When you think this fixes bug 11235 and all test cases that are more
complex than that, why not?

2011/12/5 Devang Patel <dpatel at apple.com>

>
> On Dec 2, 2011, at 11:56 AM, Carl-Philip Hänsch wrote:
>
> While trying to find a solution for this bug
> http://llvm.org/bugs/show_bug.cgi?id=11235 ,
> I came to the conclusion that the following things can happen while
> optimizing:
>  - after gvn, I get new constants which are inserted into br and
> add/sum/..., so there should be at least one more jump-threading and/or
> instsimplify
>  - after instsimplify, I get new constants which are inserted into br, so
> there should be one more jump-threading pass
>  - after jump-threading, new bigger blocks occur with redundant loads
> which need an other gvn pass
>
> At least for -O3 we will need those optimizations.
> Is there a kind of "I need at least one more $XYZ pass" call that can be
> invoked from a Pass?
>
> So my suggestion to implement in LLVM is:
>  - Detect where exactly constants are inserted
>  - Detect which pass is responsible to continue folding it
>  - Insert that pass if allowed and if it is not in the queue by a
> ProposePass function
>
> ProposePass should decide wether it's worth to further constant fold the
> block by running the proposed pass. Once accepted, the pass should be
> inserted into the pass queue at a position where it is most effective.
>
> What do you think about that idea? How much would be the effort of
> implementing it? Does it fit the layering design?
>
>
> This looks like a slippery slope towards finding optimal optimization pass
> sequence.
>
> Why not fix pass sequence manually by updating PassManagerBuilder directly
> ?
> -
> Devang
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111205/6fc526a8/attachment.html>