[llvm-dev] beneficial optimization of undef examples needed

[Matthias Braun via llvm-dev]

Luckily someone already did the work writing a bunch of examples down:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>

And +1 for keeping this on-topic on how to implement poison.

- Matthias

> On Jun 16, 2017, at 3:19 PM, John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> I'll repeat that open-ended requests would that end up generating lots of work for other people probably aren't going to get great results here.
> 
> John
> 
> 
> 
> On 6/16/17 4:03 PM, Peter Lawrence via llvm-dev wrote:
>> All,
>>     These discussions seem to be based on the premise that there is a
>> need for the compiler to exploit undefined behavior for performance
>> optimization reasons.
>> 
>> So far the only beneficial optimization I am aware of that relies on some
>> form of “undefined” is Dan Gohman’s original project for LP64 targets of
>> promoting i32 induction variables to i64 and hoisting sign-extension out
>> of the loop.
>> 
>> But “undef” / “poison” never appears in either the original or the transformed
>> IR for these types of loops, instead properties of “+nsw” are used to
>> justify the transformation.  The transformation does not just fall out because
>> we’ve done a good job at defining “undef” / “poison” IR nodes.
>> 
>> So I’d like to see some concrete examples of where the compiler can
>> do useful optimization based on “undef” / “poison” appearing explicitly
>> In the IR,  finding some would surely advance this discussion.
>> 
>> 
>> 
>> Peter Lawrence.
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170616/98f258f4/attachment.html>