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

[John Regehr via llvm-dev]

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

John


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
>