[llvm-dev] [RFC] Introducing a byte type to LLVM
Jeroen Dobbelaere via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 23 07:17:29 PDT 2021
> 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 18.104.22.168 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).
> this is *required*, but I also don't know an alternative. So if this remains
> case, and if we say "load i64" performs a ptrtoint when needed, then that
> 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
> not the case -- 'iN' cannot hold data with provenance.
> Kind regards,
More information about the llvm-dev