[llvm-dev] [cfe-dev] [RFC] Introducing a byte type to LLVM
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 9 16:14:43 PDT 2021
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.
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.
More information about the llvm-dev