This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: call_insn's and argument locations


  In message <Pine.LNX.4.33L2.0107021142470.25075-100000@nondot.org>you write:
  > Here are a few initial things to discuss.  I think that a mid level IR
  > should have the following attributes:
  > 
  > 1. Able to represent "any" front end language:
  >    Instead of a tree representation, I believe we should shoot for more    
>    of a 3 address code type IR (similar in form to RTL).  There are many
  >    optimizations that would be useful that operate on 3AC.
Why create a new IR at all when we can get the same capabilities with
RTL by adding the necessary features to it?


  > 2. Architecture independence:
  >    I think the IR should be completely machine independant.  To do this,
  >    there would be certain "instructions" in the IR that are higher level
  >    than standard three address code type operations... for example, a
  >    call instruction that takes all of the call arguments as operands.
While I believe it's a useful goal, I don't know if it's actually
achievable, at least in a reasonable timeframe.  I would keep this as a
goal, but allow ourselves the flexibility to have some target dependent
stuff in the IR with the goal of eventually stamping it out.


  > 3. SSA Representation:
  >    SSA is a useful representation for optimizations for many reasons, and
  >    I think that it is feasible to make it be the primary representation
  >    for the IR (SGI's compiler also uses SSA for the primary IR).
I don't think this is going to be feasible.  At least not anytime soon.

I'm aware of SGI's compiler, but also bear in mind that GCC supports about
40 different chip families, whereas SGI's compiler has been ported to 
significantly fewer.  They've also had the advantage of nearly rebuilding
their compiler from scratch in the mid-90s, wereas we have baggage from
the mid 80s that we have to jettison first :-)

Also note that SGI's isn't pure SSA.  They use SSA in their high level
optimizers, but I'm pretty sure they lose SSA form once they go into their
code generator (which has a number of optimizations unto itself).

jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]