[LLVMdev] RFC: GEP as canonical form for pointer addressing

[Philip Reames]

On 02/15/2014 07:22 AM, Hal Finkel wrote:
> ----- Original Message -----
>> From: "Philip Reames" <listmail at philipreames.com>
>> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
>> Sent: Friday, February 14, 2014 7:18:21 PM
>> Subject: [LLVMdev] RFC: GEP as canonical form for pointer addressing
>>
>> RFC: GEP as canonical form for pointer addressing
>>
>> I would like to propose that we designate GEPs as the canonical form
>> for
>> pointer addressing in LLVM IR before CodeGenPrepare.
> Is this not already the case?
If it is, my proposal is even less controversial than I'd hoped it would 
be.  :)  However, given the number of folks who I've talked to about 
this who haven't said so, I expecting the answer is no.
> I did not think that any passes introduce inttoptr+arithmetic+inttoptr prior to CGP.
To my knowledge, none currently do.  I want to keep it that way.
> On the other hand, we don't convert inttoptr+arithmetic+inttoptr into GEP when we can (which is PR14226 -- where Eli (cc'd) said this is unsafe in general).
To be clear, this is somewhat separate from my proposal.  I only care 
that inttoptr+arithmetic+inttoptr sequences aren't inserted in the place 
of GEPs.

Having said that..., it's still an interesting point to discuss.

I read through the PR and I have to admit I don't understand why the 
pointer aliasing rules would prevent such a transform.  The final GEP is 
already "based on"* the base of the original GEP.  The transformation 
doesn't effect that at all.  Can you (or Eli) spell this out a bit for 
me?  I'm missing something.

* from "A pointer value formed by an inttoptr is /based/ on all pointer 
values that contribute (directly or indirectly) to the computation of 
the pointer’s value." in the LangRef

Philip



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140215/5b27a0ca/attachment.html>