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

Philip Reames
Sat, 15 Feb 2014 20:27:23 -0000

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>