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

[John McCall via llvm-dev]

On 15 Jun 2021, at 1:49, Juneyoung Lee wrote:
> On Tue, Jun 15, 2021 at 1:08 AM John McCall via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> The semantics you seem to want are that LLVM’s integer types cannot 
>> carry
>> information from pointers. But I can cast a pointer to an integer in 
>> C and
>> vice-versa, and compilers have de facto defined the behavior of 
>> subsequent
>> operations like breaking the integer up (and then putting it back
>> together), adding numbers to it, and so on. So no, as a C compiler 
>> writer,
>> I do not have a choice; I will have to use a type that can validly 
>> carry
>> pointer information for integers in C.
>>
> int->ptr cast can reconstruct the pointer information, so making 
> integer
> types not carry pointer information does not necessarily mean that
> dereferencing a pointer casted from integer is UB.

What exactly is the claimed formal property of byte types, then,
that integer types will lack?  Because it seems to me that converting
from an integer gives us valid provenance in strictly more situations
than converting from bytes, since it reconstructs provenance if 
there’s
any object at that address (under still-debated restrictions),
while converting from bytes always preserves the original provenance
(if any).  I don’t understand how that can possibly give us *more*
flexibility to optimize integers.

>> Since you seem to find this sort of thing compelling, please note 
>> that
>> even a simple assignment like char c2 = c1 technically promotes 
>> through
>> int in C, and so int must be able to carry pointer information if 
>> char
>> can.
>>
> IIUC integer promotion is done when it is used as an operand of 
> arithmetic
> ops or switch's condition, so I think assignment operation is okay.

Hmm, I was misremembering the rule, you’re right.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210615/00c5e35a/attachment.html>