<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Probably the issue is solvable in some Codegen prepare pass.<div class=""><br class=""></div><div class="">That said I still believe some kind of control on if we would like to implement this or not could be useful.</div><div class=""><br class=""></div><div class="">Just a question. Why implementing it in SimplifyCFG and not as a separate pass like JumpThreading or something like that? The transformation itself doesn’t seem to fit much in SimplifyCFG.<br class=""><div><blockquote type="cite" class=""><div class="">On 2 Sep 2016, at 13:35, Michael Kuperstein <<a href="mailto:mkuper@google.com" class="">mkuper@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello Marcello,<div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Having said that - I don't believe this is something you can rely on for correctness.</div><div class="">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).<br class=""></div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""> Michael</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Sep 2, 2016 at 11:39 AM, Marcello Maggioni via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br class="">
<br class="">
I’m getting some failures on our internal testing happening after this commit.<br class="">
<br class="">
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<br class="">
<br class="">
In particular we have some loads that need to have a constant address to be selected, because they load from a “special address space”.<br class="">
<br class="">
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.<br class="">
This breaks our selection of this types of loads.<br class="">
<br class="">
We need a way to tell this code to not do that.<br class="">
<br class="">
The solutions I kind of see for this is:<br class="">
<br class="">
- Add some TTI hook that stops this sinking from happening for instructions that don’t support that like in this case (maybe added in canSinkInstructions())<br class="">
<br class="">
- 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.<br class="">
<br class="">
- 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.<br class="">
<br class="">
Open for suggestions on what the best solution for this is.<br class="">
<br class="">
Thanks,<br class="">
Marcello<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>