Chris Lattner via llvm-dev
2021-Jun-09 16:03 UTC
[llvm-dev] [cfe-dev] [RFC] Introducing a byte type to LLVM
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210609/3d1431c0/attachment.html>
Hal Finkel via llvm-dev
2021-Jun-09 23:14 UTC
[llvm-dev] [cfe-dev] [RFC] Introducing a byte type to LLVM
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