<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 02/18/2014 01:02 PM, Andrew Trick
wrote:<br>
</div>
<blockquote
cite="mid:F9719F6E-3D2E-4ED7-894F-4FBF9962B55F@apple.com"
type="cite">On Feb 18, 2014, at 12:58 PM, David Chisnall <<a
moz-do-not-send="true" href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>>
wrote:
<div>
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
0px;">On 18 Feb 2014, at 19:51, Philip Reames <<a
moz-do-not-send="true"
href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>
wrote:<br>
<blockquote type="cite">On 02/17/2014 02:53 PM, Andrew Trick
wrote:<br>
<blockquote type="cite">On Feb 17, 2014, at 2:31 AM, David
Chisnall <<a moz-do-not-send="true"
href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>>
wrote:<br>
<blockquote type="cite">On 15 Feb 2014, at 23:55, Andrew
Trick <<a moz-do-not-send="true"
href="mailto:atrick@apple.com">atrick@apple.com</a>>
wrote:<br>
<blockquote type="cite">On Feb 14, 2014, at 5:18 PM,
Philip Reames <<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>
wrote:<br>
<br>
</blockquote>
Not directly related, but our canonical form for loops
involving pointers[1] turns a loop that contains a GEP
with the loop induction variable into a GEP with the
increment inside the loop. This has two annoying
properties for code generation:<br>
<br>
- The GEP with the induction variable as the offset
maps cleanly to CPU addressing modes and so we
generate better code if we don't do this
canonicalisation, and therefore end up trying to undo
it in the back end (yuck).<br>
<br>
- If the source is the start of an object, then this
behaviour is GC-hostile because it means that IR that
contains a pointer to an object start now only
contains a pointer to the middle, requiring the GC to
deal with inner pointers.<br>
<br>
It would be nice if we could have canonical forms such
that if the front end ensures that there are no inner
pointers without pointers to the object's start in the
IR, the optimisers don't break this.<br>
<br>
David<br>
<br>
[1] Are canonical forms actually documented anywhere,
or are they simply undocumented implicit contracts?<br>
</blockquote>
I would say whatever form is currently generated by IR
passes is defined as canonical. It’s not easy to
specify. At some points in the pipeline (early and late)
it’s fine to permit multiple forms of the same
expression as long as it’s canonical-enough for the
downstream analysis.<br>
<br>
If some pass is generating a suboptimal form, it’s good
to question whether it’s really necessary for any
analysis. If not, we should change it. Without a test
case, I can’t say what issue you’re running into above.<br>
</blockquote>
David, do you happen to have a test case on hand? I know
I've seen this before, but my attempt to write out a quick
example from memory failed.<br>
</blockquote>
<br>
I don't have one to hand - it's something I see in things
with fairly complex loop structures. I'll try to find one
next time I'm chasing performance issues.<br>
</div>
</blockquote>
</div>
<br>
<div>If you’re running LSR, all bets are off. When Philip says he
wants canonical IR before CodeGenPrepare, I take that to mean
anything scheduled in TargetPassConfig::addIRPasses, including
LSR, constant hoisting, etc.</div>
<div><br>
</div>
<div>-Andy</div>
</blockquote>
This is exactly what I meant. Thanks for the clarification.<br>
<br>
Philip<br>
<br>
</body>
</html>