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

[Juneyoung Lee via llvm-dev]

I created https://reviews.llvm.org/D104013 - please feel free to leave
comments.

Thanks,
Juneyoung

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>
> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210610/16e06396/attachment.html>