[cfe-dev] different IR from Clang

[Sean Silva]

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?

--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.
>
>