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

Peter Lawrence via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 20 06:50:57 PDT 2017


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



More information about the llvm-dev mailing list