<div dir="ltr">Hi Hal,<div><br></div><div>We compile in three stages:</div><div><ul><li>clang -O -S -emit-llvm</li><li>opt -load Private.so -expandgep -O1 -dumpPrivate -S</li><li>privateCG</li></ul>We could never get close to building an LLVM backend for our target,</div><div>so we wrote our own. Originally it worked on the LLVM IR created by</div><div>clang using -emit-llvm. More recently, I wrote a pass to expand GEPs</div><div>and we run that using opt, followed by O1, and a pass that spits out</div><div>the IR in an easy-to-parse form for consumption by our code generator.</div><div><br></div><div>If I have to write my own versions of value numbering and licm,</div><div>I would either put them immediate after expanding the GEPs</div><div>(so I can take advantage of al the LLVM support)</div><div>or as an early part of our code generator</div><div>(so I can understand/control what's going on).</div><div><br></div><div>Preston</div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 9:54 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Preston Briggs via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
> To: "Mehdi Amini" <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>><br>
> Cc: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
> Sent: Wednesday, December 9, 2015 4:25:38 PM<br>
> Subject: Re: [llvm-dev] persuading licm to do the right thing<br>
><br>
><br>
><br>
</span><div><div class="h5">> I understand that GEPs do not access memory.<br>
> They do a (possibly expensive) address calculation,<br>
> perhaps adding a few values to a label and leaving the result in a<br>
> register.<br>
> Getting a label into a register is (to me) just like loading a 64-bit<br>
> integer value<br>
> into a register. It can happen in many places and it can cost a few<br>
> instructions<br>
> and several bytes. I'd like to see such things commoned and hoisted<br>
> when possible.<br>
><br>
><br>
> I agree with you that I may be fighting the spirit of the IR.<br>
><br>
><br>
> I also agree with Daniel that the classic solution is to lower and<br>
> re-optimize.<br>
> Indeed, I tried it, sort of, by rewriting GEPs into a sequence of<br>
> adds and multiplies,<br>
> with bitcasts to gets the types right. This helps in some places, but<br>
> the<br>
> re-canonicalization defeats my efforts in others places.<br>
><br>
><br>
> So now I feel like I'm going to have to write my own LICM and VN<br>
> passes.<br>
> I can do it and it won't take that long, but I had imagined that I<br>
> could<br>
> pick and choose from the tools already available to achieve the<br>
> desired effect.<br>
> Seems not, and I'm surprised.<br>
><br>
<br>
</div></div><span class="">At what point in the pipeline do you intend to run these tools? We do have some LICM, CSE, etc. capabilities late in the pipeline (at the SDAG and MI level), and we already so some GEP splitting in CodeGenPrep just before instruction selection. Once GEPs are fully decomposed during SDAG construction these later optimizations should do the things you describe. That having been said, they have known limitations in this area, but ideally we should all work together on improving that infrastructure.<br></span><div><div class="h5"><br></div></div></blockquote></div></div></div>