<br><br><div class="gmail_quote">On 20 September 2012 13:51, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ah, sorry, I'm not that familiar with Open64. After briefly perusing a<br>
paper on WHIRL, I guess I was expecting the desired IR to more like<br>
the "mid WHIRL". From that point of view, my reasoning was that<br>
anything which sidesteps having to interpret the entire C/C++ lowering<br>
semantics (lowering from Clang AST) is going to be a lot easier than<br>
practically any alternative. I agree that it makes sense to lower<br>
Clang AST's if the target is "Very High" or "High" WHIRL.<br>
<br>
Are there any interesting optimizations before mid WHIRL?<br></blockquote><div> </div><div>There are lots of optimizations before "mid WHIRL", mainly are machine independent optimizations like (LNO, IPA, PREOPT) and some parts in WOPT.  "HWHILR"  preserves high level control flow structures.  In many cases, it is more effective and compact for various optimizations than low levels.  If you are interested, please refer to these documents:</div>
<div><br></div><div><a href="http://www.mcs.anl.gov/OpenAD/open64A.pdf">www.mcs.anl.gov/OpenAD/open64A.pdf</a></div><div><a href="http://sourceforge.net/projects/open64/files/open64/Documentation/">http://sourceforge.net/projects/open64/files/open64/Documentation/</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--Sean Silva<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Sep 19, 2012 at 11:26 PM, "C. Bergström"<br>
<<a href="mailto:cbergstrom@pathscale.com">cbergstrom@pathscale.com</a>> wrote:<br>
> On 09/20/12 07:41 AM, Sean Silva wrote:<br>
>><br>
>> It is going to be a LOT easier to convert from LLVM IR to Open64's IR.<br>
><br>
> Total BS<br>
> ---------------------------<br>
> "Open64's IR" is primarily WHIRL so that we're talking about the same thing.<br>
> VH WHIRL contains a crapload more source information than the thing people<br>
> primarily call "LLVM IR".  (LLVM has 2 levels of IR depending how you look<br>
> at things - Yes even LLVM IR "lowers" down to a point where it's target<br>
> specific).  To complicate this more - during phases of the compiler it goes<br>
> in/out of other IR as well.  eg SSAPRE and towards the end of the<br>
> compilation process from VL WHIRL to CGIR.<br>
><br>
> To put this in a perspective which most "Open64" people can understand -<br>
> It's like going from CGIR back up to VH WHIRL.<br>
> ---------------------------<br>
> If your intention is "production" software you might want to consider some<br>
> other factors for why this wouldn't be a good idea<br>
>     * Less SLOC is almost always easier to maintain (Introducing partial or<br>
> whole LLVM in the middle would be *huge*)<br>
>     * Compilation times of user code<br>
>     * Loss of source information and how that may translate to less<br>
> effective optimizations<br>
> ---------------------------<br>
> I've looked at this in depth and hooking into clang *before* LLVM IR is the<br>
> way to go.  From experience you could probably "hack" together something<br>
> quick to get C code to work, but compiling serious codes or full C++ is many<br>
> many "man years" of work.<br>
><br>
><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br>