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

[Hal Finkel via cfe-dev]

On 6/9/21 12:03, Chris Lattner wrote:
> On Jun 6, 2021, at 8:52 AM, Hal Finkel <hal.finkel.llvm at gmail.com> wrote:
>> I'll take this opportunity to point out that, at least historically, 
>> the reason why a desire to optimize around ptrtoint keeps resurfacing 
>> is because:
>>
>>  1. Common optimizations introduce them into code that did not 
>> otherwise have them (SROA, for example, see convertValue in SROA.cpp).
>>
>>  2. They're generated by some of the ABI code for argument passing 
>> (see clang/lib/CodeGen/TargetInfo.cpp).
>>
>>  3. They're present in certain performance-sensitive code idioms 
>> (see, for example, ADT/PointerIntPair.h).
>>
>> It seems to me that, if there's design work to do in this area, one 
>> should consider addressing these now-long-standing issues where we 
>> introduce ptrtoint by replacing this mechanism with some other one.
>>
> I completely agree.  These all have different solutions, I’d prefer to 
> tackle them one by one.
>
> -Chris
>

I agree, these different problems have three different solutions. Also, 
let me add that I see three quasi-separable discussions here (accounting 
for past discussions on the same topic):

  1. Do we have a consistency problem with how we treat pointers and 
their provenance information? The answer here is yes (see, e.g., the GVN 
examples from this thread).

  2. Do we need to do more than be as conservative as possible around 
ptrtoint/inttoptr usages? This is relevant because trying to be clever 
here is often where inconsistencies around our pointer semantics are 
exposed, although it's not always the case that problems involve 
inttoptr. Addressing the points I raised above will lessen the 
motivation to be more aggressive here (although, in itself, that will 
not fix the semantic inconsistencies around pointers).

  3. Does introducing a byte type help resolve the semantic issues 
around pointers? I don't yet understand why this might help.

Thanks again,

Hal