Re: [Open64-devel] Why 5 levels of WHIRL?

[Fred C. <fr...@gm...>]

It was a evolutionary process.  The predecessors of Open64, which are 
the Cydrome compiler and the MIPS Ucode compiler, have only one level.  
Both were good at global scalar optimizations, and NOT good at LNO type 
of optimizations.  Their IR corresponds to Mid-WHIRL.   At the start of 
the Pro64 (later Open64) project in around 1994, we formed a team to 
tackle LNO.  The team brought in expertise from Stanford's SUIF project, 
and they said Mid-WHIRL is not appropriate for LNO type of 
optimizations.  As a result, they defined High-WHIRL. 

Instead of directly generating CGIR from Mid-WHIRL, the compiler team at 
SGI also found it cleaner to separate it into two steps: Lowering 
Mid-WHIRL to Low-WHIRL first, and since Low-WHIRL is closer to machine 
instructions, the CG expansion step can be made simpler.  This also 
reduces the effort in retargeting, since Low-WHIRL can still be somewhat 
target-independent.

Later, the team tackled the problem of supporting Fortran 90.  We could 
have made the Fortran front-end generates High-WHIRL, but the team also 
found it cleaner to separate the process into two steps.  Making the 
front-end generates VH WHIRL reduces the burden on the front-end because 
it does not have to worry about the code generation details of those 
array aggregate operations.  The lowering of VH WHIRL to High-WHIRL is 
also language independent, in case some other language also want to have 
Fortran 90-like constructs.  The lowering from VH to High WHIRL can also 
be modularized so it can focus on the translation and optimizations 
related to array aggregate expressions.

Looking back, I still believe it was a sound decision by the team 
because it adheres to  the good practices of software engineering.

If we only have Low WHIRL, it would still be possible to do everything 
the compiler does, but at much greater development efforts and resulting 
in less stability and slower compilation efficiencies.

 From their name, LLVM roughly corresponds to Low WHIRL.  I wonder how 
LLVM tackles the compilation problems Open64 has tackled.  People with 
exposure to LLVM are welcome to chime in.

-Fred Chow

Sun Chan wrote:
> one important reminder: The different levels progressively expose
> closer to machine level, the lower level super set of the upper. I.e.
> Lower levels always accepts the higher level form
> Sun
>
> 2009/10/25 Sun Chan <sun...@gm...>:
>   
>> Fred is the right person to do that. The design goal is such that each
>> level roughly corresponds to abstraction level that matches the
>> optimization/analysis at hand. The obvious example is that if loops
>> are fully reduced to goto's and array reduced to
>> address+offset*stride, and in different quaddruples or the like, to do
>> array dependency is very difficult. With the right abstraction level,
>> the task of writing an analyzer is much simpler.
>> Sun
>>
>> 2009/10/25 "C. Bergström" <cbe...@pa...>:
>>     
>>> I'm creating an argument and comparison that WHIRL is still an excellent
>>> IR choice for any modern static compiler.  I can easily argue against
>>> the design choice of using a single unified IR, but then the
>>> justification gets blurry on why exactly there is 5 levels?  Is this
>>> just for symmetry between the high and low levels or... ?  Citations,
>>> opinions or facts are all greatly appreciated.
>>>
>>> Thanks
>>>
>>> ./C
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Open64-devel mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>>
>>>       
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Open64-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>