[llvm-dev] Poison/Undef at CodeGen level Was: [poison] is select-of-select to logic+select allowed?

[Hal Finkel via llvm-dev]

On 05/26/2017 03:02 PM, Matthias Braun wrote:
>
>> Regarding SDAG, and given that poison is already there, we would need 
>> to adopt a similar solution to the IR.  Maybe right now we can get 
>> away with it because nsw is not exploited significantly (as you say). 
>>  Just because there’s no explicit poison in SDAG, just having nsw is 
>> sufficient to cause miscompilations when combined with other 
>> transformations.
>> See, for example, this bug report for InstCombine regarding 
>> select+nsw:_https://bugs.llvm.org/show_bug.cgi?id=31633_
>
> Poison/Undef at the CodeGen level is a very interesting discussion! I 
> don't think there is any documentation about posion/undef at the 
> CodeGen level and I haven't discussed this much with others, so I'd 
> like to hear further feedback:
>
> - I think we should not introduce a notion of poison (which I would 
> call "delayed UB") at the SelectionDAG/CodeGen level[1]
> - Instructions either produce UB immediately, so while there are 
> nsw/nuw flags on SelectionDAG arithmetic operatiosn I think we can 
> only assume that they produce a target specific value on overflow, but 
> not arbitrary behavior. Instructions that can produce UB should marked 
> "hasSideEffect" and code motion around it be limited.

You mean like every integer division? Having arbitrary side effects 
seems too strong.

> - Typical optimization scenarios like establishing loop trip count 
> bounds for which poison/UB is helpful should not matter for CodeGen.
> - I don't have any evidence that optimizations in CodeGen require a 
> model of poison to work. If someone can given me a counter example 
> then I'd be hard pressed to disable the optimization in MI and push it 
> towards the IR level.

I'm not sure it is always possible to push these optimizations to the IR 
level, at least not without adding more Value* ties to instructions 
(e.g. what we do with MMOs). I have some experience, for example, taking 
optimizations taking advantage of hardware-counter-based loops and 
moving into the IR level (so that we can take advantage of 
ScalarEvolution), and it works to some extent, but is also fairly hacky 
(the legality-checking part of lib/Target/PowerPC/PPCCTRLoops.cpp, for 
example, needs to understand what legalization will later do - it's the 
best we can do right now, but it's a mess). If we had better loop 
analysis at the MI level, this would be much better. We already have 
some interesting MI-level passes that do interesting things with loops 
(lib/CodeGen/MachinePipeliner.cpp, for example).

I think that we should have the same semantics here on both the IR level 
and the MI level (whatever they are). Having different semantics in this 
regard is going to be confusing (and lead to subtle bugs because 
optimizations valid in one part of the pipeline will be invalid in other 
parts). These issues often come up around speculative execution, for 
example, and I definitely think we need to be able to deal with 
speculative execution at the MI level (because speculation opportunities 
often come from legalization/isel and pseudo-instruction expansion and 
because the modeling is better at the MI level).

  -Hal

>
> - Matthias

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170526/367c8c22/attachment.html>