[llvm-dev] [RFC] Introducing a byte type to LLVM

[Jeroen Dobbelaere via llvm-dev]

Hi Ralf,

[..]
> 
> To add to what Juneyoung said:
> I don't think that experiment has been made. From what I can see, the
> alternative you propose leads to an internally consistent model -- one "just"
> has to account for the fact that a "load i64" might do some transformation on
> the data to actually obtain an integer result (namely, it might to ptrtoint).
> 
> However, I am a bit worried about what happens when we eventually add proper
> support for 'restrict'/'noalias': the only models I know for that one actually
> make 'ptrtoint' have side-effects on the memory state (similar to setting the
> 'exposed' flag in the C provenance TS). I can't (currently) demonstrate that

For the 'c standard', it is undefined behavior to convert a restrict pointer to
an integer and back to a pointer type.

(At least, that is my interpretation of n2573 6.7.3.1 para 3: 
   Note that "based" is defined only for expressions with pointer types.
)

For the full restrict patches, we do not track restrict provenance across a
ptr2int, except for the 'int2ptr(ptr2int %P)' (which we do, as llvm sometimes
introduced these pairs; not sure if this is still valid).

Greetings,

Jeroen Dobbelaere

> this is *required*, but I also don't know an alternative. So if this remains
> the
> case, and if we say "load i64" performs a ptrtoint when needed, then that
> would
> mean we could not do dead load elimination any more as that would remove the
> ptrtoint side-effect.
> 
> There also is the somewhat conceptual concern that LLVM ought to have a type
> that can loslessly hold all kinds of data that exist in LLVM. Currently, that
> is
> not the case -- 'iN' cannot hold data with provenance.
> 
> Kind regards,
> Ralf