[llvm-dev] [RFC] Introducing a byte type to LLVM
Ralf Jung via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 24 00:01:40 PDT 2021
Hi again Jeroen,
>> 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 220.127.116.11 para 3:
> Note that "based" is defined only for expressions with pointer types.
After sleeping over it, I think I want to push back against this interpretation
a bit more strongly. Consider a program snippet like
int *out = (int*) decrypt(encrypt( (uintptr_t)in ));
It doesn't matter what "encrypt" and "decrypt" do, as long as they are inverses
of each other.
"out" is definitely of pointer type. And by the dependency-based definition of
the standard, it is the case that modifying "in" to point elsewhere would also
make "out" point elsewhere. Thus "out" is 'based on' "in". And hence it is okay
to use "out" to access the object "in" points to, even in the presence of
> 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).
> Jeroen Dobbelaere
>> 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