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

[Ralf Jung via llvm-dev]

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 6.7.3.1 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 
'restrict'.

Kind regards,
Ralf

> 
> 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
> 

-- 
Website: https://people.mpi-sws.org/~jung/