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

[Sanjoy Das via llvm-dev]

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