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

John Regehr via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 20 07:35:41 PDT 2017

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.


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

More information about the llvm-dev mailing list