[llvm-dev] the root cause is CP, was: A tagged architecture, the elephant in the undef / poison room

[Peter Lawrence via llvm-dev]

John,
         this is the issue at hand

[1. this function *always* executes statement S,
	F(a) {
	   If (a == a) S;
	}
   but in llvm if you inline it and “a” happens to be “undef” then nothing can
   be said about whether statement S is executed. This is indefensible.]

I am trying to force this issue because when I challenge folks to question
their assumptions regarding CSE’ing and CP’ing of “undef” all I get back
is a recitation of the usual catechism on the subject. I can’t get them
to think outside the box without this example of the consequences
of those assumptions. Unfortunately so far no one has responded to it.


The VP of engineering at my last company had a way of bringing
clarity to issues like this, he said now that robotic surgery is
becoming a reality do you want the compiler to do this if it is being
used to compile the robot software and you are scheduled for
surgery.


I also believe that the C-standard is flawed in that it uses the
term “undefined behavior” in many place where it should only
use “unspecified”, and that reading the letter rather than the spirit 
of the standard is doing a disservice to our users.  We should not
look to the standard for guidance, rather the llvm community
needs to take a stand and guide the standard.


Will you help in challenging folks to question their assumptions ?
Will you help guide the standard ?
What say you ?


Peter Lawrence.




> On Jun 19, 2017, at 9:28 PM, John Regehr <regehr at cs.utah.edu> wrote:
> 
>> ... the argument against the function-inlining
>> example is so compelling that John decided to drop out of the argument,
>> IE he gave up because it is indefensible.
> 
> Peter, it is extremely impolite to mischaracterize someone else's position.  Up to this point I assumed that you were operating in good faith but what I quoted above looks more like trolling.
> 
> John
> 

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