[llvm-dev] [cfe-dev] [RFC] Introducing a byte type to LLVM
Juneyoung Lee via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 10 02:05:11 PDT 2021
I created https://reviews.llvm.org/D104013 - please feel free to leave
On Thu, Jun 10, 2021 at 8:15 AM Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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>
> >> 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,
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev