<div dir="ltr">I created <a href="https://reviews.llvm.org/D104013">https://reviews.llvm.org/D104013</a> - please feel free to leave comments.<div><br></div><div>Thanks,</div><div>Juneyoung </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 10, 2021 at 8:15 AM Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 6/9/21 12:03, Chris Lattner wrote:<br>
> On Jun 6, 2021, at 8:52 AM, Hal Finkel <<a href="mailto:hal.finkel.llvm@gmail.com" target="_blank">hal.finkel.llvm@gmail.com</a>> wrote:<br>
>> I'll take this opportunity to point out that, at least historically, <br>
>> the reason why a desire to optimize around ptrtoint keeps resurfacing <br>
>> is because:<br>
>><br>
>>  1. Common optimizations introduce them into code that did not <br>
>> otherwise have them (SROA, for example, see convertValue in SROA.cpp).<br>
>><br>
>>  2. They're generated by some of the ABI code for argument passing <br>
>> (see clang/lib/CodeGen/TargetInfo.cpp).<br>
>><br>
>>  3. They're present in certain performance-sensitive code idioms <br>
>> (see, for example, ADT/PointerIntPair.h).<br>
>><br>
>> It seems to me that, if there's design work to do in this area, one <br>
>> should consider addressing these now-long-standing issues where we <br>
>> introduce ptrtoint by replacing this mechanism with some other one.<br>
>><br>
> I completely agree.  These all have different solutions, I’d prefer to <br>
> tackle them one by one.<br>
><br>
> -Chris<br>
><br>
<br>
I agree, these different problems have three different solutions. Also, <br>
let me add that I see three quasi-separable discussions here (accounting <br>
for past discussions on the same topic):<br>
<br>
  1. Do we have a consistency problem with how we treat pointers and <br>
their provenance information? The answer here is yes (see, e.g., the GVN <br>
examples from this thread).<br>
<br>
  2. Do we need to do more than be as conservative as possible around <br>
ptrtoint/inttoptr usages? This is relevant because trying to be clever <br>
here is often where inconsistencies around our pointer semantics are <br>
exposed, although it's not always the case that problems involve <br>
inttoptr. Addressing the points I raised above will lessen the <br>
motivation to be more aggressive here (although, in itself, that will <br>
not fix the semantic inconsistencies around pointers).<br>
<br>
  3. Does introducing a byte type help resolve the semantic issues <br>
around pointers? I don't yet understand why this might help.<br>
<br>
Thanks again,<br>
<br>
Hal<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br></div><font size="1">Juneyoung Lee</font><div><font size="1">Software Foundation Lab, Seoul National University</font></div></div></div>