[llvm-dev] Problem with "[SimplifyCFG] Handle tail-sinking of more than 2 incoming branches"
Michael Kuperstein via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 2 13:35:23 PDT 2016
We're currently planning to disable this optimization - at least
temporarily - for cases where we'll end up creating PHIs of pointers for
performance reasons (see PR30188).
Having said that - I don't believe this is something you can rely on for
>From an IR semantics perspective, this is a completely legal transformation
that can be introduced by any optimization pass, for whatever reason. We
can't control that throughout the entire optimization stack with a TTI
hook. Two potential solutions I can see are to either (a) teach your
backend to handle it (by disambiguating these loads in a pre-ISel IR pass),
or (b) use some kind of type-system trick to make it impossible (say,
assign a different address space to each distinct pointer in the front end).
On Fri, Sep 2, 2016 at 11:39 AM, Marcello Maggioni via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I’m getting some failures on our internal testing happening after this
> I dug a little bit into it and it ended up begin caused by the fact that
> this optimization is sinking some instructions that shouldn’t be sunk
> In particular we have some loads that need to have a constant address to
> be selected, because they load from a “special address space”.
> What the optimization is doing is extracting the “getelementptr” , making
> an instruction out of it, sinking the load and using a PHI to select
> between the address.
> This breaks our selection of this types of loads.
> We need a way to tell this code to not do that.
> The solutions I kind of see for this is:
> - Add some TTI hook that stops this sinking from happening for
> instructions that don’t support that like in this case (maybe added in
> - Add some TTI hook that is a little bit coarser that stops the
> optimization to run altogether. In particular this thing is creating
> “unstructured control-flow” in some cases and this is not always good (and
> actually generally bad) on GPU targets.
> - Put the optimization in another separate pass. It seems to be doing
> stuff that is a little bit more than just “Simplifying the CFG” actually.
> It is actually making it more complex by splitting blocks around. I wonder
> if it would make sense for it to live it in a separate pass that can be
> enabled or disabled at the compiler pipeline level so that one that wants
> to opt out can just avoid to add the pass to the pipeline.
> Open for suggestions on what the best solution for this is.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev