[llvm-dev] Function Inlining and undef / poison question

John Regehr via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 15 15:12:56 PDT 2017

Hi Peter, I don't see what you're driving at here. You can perhaps move 
the discussion forward with a complete, compilable example.


On 6/15/17 11:27 AM, Peter Lawrence via llvm-dev wrote:
> Nuno,
>           One of your recent emails got me thinking about inlining.
> I say this function is always well defined,
> And it always executes statement S
> F(a)
> {
>    If (a == a) S;
> }
> And that if this function is inlined it must still be well defined,
> And still always execute statement S
> But if I read your example correctly you feel that the result
> of inlining is undefined behavior because “if (undef == undef)”
> and “if (poison == poison)” is undefined behavior  ?
> I say that if the compiler makes it so that the programmer cannot
> correctly reason about how their program executes then there is
> something wrong with the compiler.
> My own opinion about this is that it is yet another example of why
> "Since each use of ‘undef’ can yield a different result…”
> is such a bad definition, and should never have been accepted into
> the IR in the first place.
> IIUC, both “undef” and “poison” share this undesirable definition
> for which “freeze” is proposed as a fix, but if I understand your
> logic correctly there is no way to fix this example with “freeze” ?
> IMHO "freeze” is a bandaid over a bad definition, that doesn’t
> seem to solve the inlining problem, and we should fix the definition
> rather than add a bandaid.
> 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