<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/15/2014 07:22 AM, Hal Finkel
wrote:<br>
</div>
<blockquote
cite="mid:22947445.821.1392477777330.JavaMail.javamailuser@localhost"
type="cite">
<pre wrap="">----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Philip Reames" <a class="moz-txt-link-rfc2396E" href="mailto:listmail@philipreames.com"><listmail@philipreames.com></a>
To: "LLVM Developers Mailing List" <a class="moz-txt-link-rfc2396E" href="mailto:llvmdev@cs.uiuc.edu"><llvmdev@cs.uiuc.edu></a>
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.
</pre>
</blockquote>
<pre wrap="">
Is this not already the case? </pre>
</blockquote>
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. <br>
<blockquote
cite="mid:22947445.821.1392477777330.JavaMail.javamailuser@localhost"
type="cite">
<pre wrap="">I did not think that any passes introduce inttoptr+arithmetic+inttoptr prior to CGP. </pre>
</blockquote>
To my knowledge, none currently do. I want to keep it that way.<br>
<blockquote
cite="mid:22947445.821.1392477777330.JavaMail.javamailuser@localhost"
type="cite">
<pre wrap="">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).</pre>
</blockquote>
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. <br>
<br>
Having said that..., it's still an interesting point to discuss. <br>
<br>
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. <br>
<br>
* from "A pointer value formed by an <tt class="docutils literal"><span
class="pre">inttoptr</span></tt> is <em>based</em> on all
pointer
values that contribute (directly or indirectly) to the computation
of
the pointer’s value." in the LangRef<br>
<br>
Philip<br>
<br>
<br>
<br>
</body>
</html>