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

[John Regehr via llvm-dev]

Peter, you mischaracterized what I said, you mischaracterized (below) 
what Nuno said, and you don't appear to be listening to anything people 
are saying.

I'll request (yet again) that you tone it down -- we're trying to make 
progress on some real problems with LLVM's undefined behavior model and 
you are hurting the conversation, not helping it.

Regardless, I'm done arguing with you.

John



On 06/20/2017 07:50 AM, Peter Lawrence via llvm-dev wrote:
> Sanjoy,
>              The reason you are making a proposal
> in the first place are bug reports about the compiler
> compiling C/C++ programs not IR programs.
> I am simply presenting (actually Nuno came up with
> the idea) another bug. It happens to be written in C.
> We can translate it into IR if you prefer to discuss IR
> rather than C, however it will still be the same bug.
> 
> It is time to look at this bug head on and decide how to fix it.
> 
> Peter Lawrence.
> 
> 
>> On Jun 20, 2017, at 12:17 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>>
>> Hi Peter,
>>
>> On Mon, Jun 19, 2017 at 10:02 AM, Peter Lawrence
>> <peterl95124 at sbcglobal.net> wrote:
>>>             The point is this, you have to take a stand one way or
>>> the other on the function-inlining issue:
>>>
>>>
>>> [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.]
>>>
>>>
>>> My belief is this: that llvm exists for a utilitarian purpose,
>>
>> Agreed on this front.
>>
>>> and that llvm currently violates that utilitarian goal by violating
>>
>> You've assumed that LLVM's utility primarily lies in providing
>> programming-language like semantics that are obvious and easy to
>> program.  That isn't the case -- LLVM is a compiler framework, and its
>> IR semantics are only somewhat related to source language semantics.
>>
>>> the users expectations in the function-inlining example.
>>>
>>> So the question is, where do you stand ?
>>
>> As I said, I disagree with your characterization of LLVM's utility.
>>
>> You can always write an LLVM frontend that does not generate IR that
>> will have this kind of "odd" semantics (in fact, I *am* a proponent of
>> using "safe" languages wherever possible).  However, the safety /
>> "obviousness" of the programming language is not directly related to
>> the safety / "obviousness" of LLVM IR.
>>
>> -- Sanjoy
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>