Re: call_insn's and argument locations

[Chris Lattner <sabre at nondot dot org>]

> Chris> What is the limiting factor here for a new IR?

> 	The limiting factor is having an actual design on which people
> have commented, as opposed to various people doing work in secret and
> contributing a completed implementation on which the entire GCC
> development community was able to comment.

Agreed.  This is incredibly important... and although not everyone can
ever be happy, everyone should have their opinions heard...

> GCC has been approaching this limitation for years and there is no need
> to rush to solve these fundamental problems over night.

Also agreed.  It should be recognized, however, that the sooner discussion
begins the more likely that something will happen in the near to medium
range future.

> 	We have had discussions about a new IR a few times.  If we want to
> re-open that discussion to refine the ideas more, that could be useful.

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.

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.

   Note that the target machine would affect the IR generated somewhat,
   but not nearly as much as RTL is by the machine description.  For
   example, the back end would still designate what data size a "int" maps
   to, and other issues that control the dialect the front end accepts.

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

4. Type safety/explicit types:
   One of the really annoying things about RTL is that you effectively
   lose all type information when you do the Tree->RTL transition.  It
   would be very very useful to know the difference between a 32 bit
   pointer, and a 32 bit integer, for example.  The only problem with this
   model is that you get "cast" instructions occasionally to convert
   types, and that makes the IR slightly larger [but not too much I would
   think].  One nice thing about having types is that we could actually do
   real loop analyses...

Anyway, this is just some initial ideas to toss around. These ideas sound
pretty much like RTL++ in a lot of respects: it just has more semantic
information, and more machine independance in it, but is otherwise very
similar.

This may be close to what Jeff is recommending, but I'm not familiar with
his ideas/plans.

What do people think?

-Chris

http://www.nondot.org/~sabre/os/
http://www.nondot.org/MagicStats/