[cfe-dev] different IR from Clang

[Yulei Sui]

On 20 September 2012 13:51, Sean Silva <silvas at purdue.edu> wrote:

> Ah, sorry, I'm not that familiar with Open64. After briefly perusing a
> paper on WHIRL, I guess I was expecting the desired IR to more like
> the "mid WHIRL". From that point of view, my reasoning was that
> anything which sidesteps having to interpret the entire C/C++ lowering
> semantics (lowering from Clang AST) is going to be a lot easier than
> practically any alternative. I agree that it makes sense to lower
> Clang AST's if the target is "Very High" or "High" WHIRL.
>
> Are there any interesting optimizations before mid WHIRL?
>

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:

www.mcs.anl.gov/OpenAD/open64A.pdf
http://sourceforge.net/projects/open64/files/open64/Documentation/


> --Sean Silva
>
> On Wed, Sep 19, 2012 at 11:26 PM, "C. Bergström"
> <cbergstrom at pathscale.com> wrote:
> > On 09/20/12 07:41 AM, Sean Silva wrote:
> >>
> >> It is going to be a LOT easier to convert from LLVM IR to Open64's IR.
> >
> > Total BS
> > ---------------------------
> > "Open64's IR" is primarily WHIRL so that we're talking about the same
> thing.
> > VH WHIRL contains a crapload more source information than the thing
> people
> > primarily call "LLVM IR".  (LLVM has 2 levels of IR depending how you
> look
> > at things - Yes even LLVM IR "lowers" down to a point where it's target
> > specific).  To complicate this more - during phases of the compiler it
> goes
> > in/out of other IR as well.  eg SSAPRE and towards the end of the
> > compilation process from VL WHIRL to CGIR.
> >
> > To put this in a perspective which most "Open64" people can understand -
> > It's like going from CGIR back up to VH WHIRL.
> > ---------------------------
> > If your intention is "production" software you might want to consider
> some
> > other factors for why this wouldn't be a good idea
> >     * Less SLOC is almost always easier to maintain (Introducing partial
> or
> > whole LLVM in the middle would be *huge*)
> >     * Compilation times of user code
> >     * Loss of source information and how that may translate to less
> > effective optimizations
> > ---------------------------
> > I've looked at this in depth and hooking into clang *before* LLVM IR is
> the
> > way to go.  From experience you could probably "hack" together something
> > quick to get C code to work, but compiling serious codes or full C++ is
> many
> > many "man years" of work.
> >
> >
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120920/392bf73f/attachment.html>