[llvm-dev] beneficial optimization of undef examples needed
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 16 19:45:36 PDT 2017
Hi Peter,
Why we need an undef value is covered here:
http://sunfishcode.github.io/blog/2014/07/14/undef-introduction.html
(in short, to do SSA construction well).
For a while we did not have a literal representation for poison.
However, in practice having both undef and poison was problematic (see
the paper), so we decided to ditch undef and keep poison.
However for the new poison to provide the same functionality as the
old undef (which is now going away), we need a literal representation
for the new poison.
-- Sanjoy
On Fri, Jun 16, 2017 at 3:03 PM, Peter Lawrence via llvm-dev
<llvm-dev at lists.llvm.org> 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
More information about the llvm-dev
mailing list