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

Peter Lawrence via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 15 10:27:40 PDT 2017


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.


More information about the llvm-dev mailing list