This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [tree-ssa] Removal of gotos from cfg based ir


> On Fri, 2003-11-14 at 16:38, Jan Hubicka wrote:
> > > On Fri, 2003-11-14 at 15:51, Jan Hubicka wrote:
> 
> > > 
> > > Bottom line is Im just trying to find good justifiable reasons why we
> > > have to keep the CFG intact throughout compilation phases using
> > > different ILs, and that we should modify the IL to do this.
> > 
> > The reason is to give mechanizm to pass control flow specific
> > infomration for optimizers (like the profile).
> 
> > Of course with non-optimizing copilation it makes less sense, but given
> > the complexity of our code generation backend we don't want to do too
> > much code duplication when it does not save us any significant amount of
> > cycles.  But in my eyes, we should make GCC optimizer friendly, while
> > trying to keep nonoptimizing compilation fast, not making GCC
> > non-optimizing friendly making optimizers dificult.
> > 
> 
> I dont think we are making optimization any more difficult because we
> create a new CFG when we translate from one IL to another IL. I was
> never suggesting we prefer non-optimizing over optimizing. I'm sorry I
> ever suggested anything about -O0 :-)

Actually -O0 is important :) That is why I double checked that my
scheme does not hurt it seriously.
> 
> We have the same goals.  Simple is best, code duplication is bad, etc
> etc.
> 
> The bottom line is you want to do this in order to pass control flow
> specific information  from one IL to another, and you think that
> maintaining the same CFG across different ILs is a better solution than
> annotating the exisiting IL with the information and building a new CFG
> when the translation is done.
> 
> correct?

Yes, this is nice formulation.
I don't see why we do need multiple mechanizms to represent information
that is used only by CFG aware optimizers.  Inventing the annotation
mechanizm is kind of code duplication too and it is very dificult to
keep it up to date (as CFG itself is, but we has to do anyway), so it
would be very short lived anyway.

On RTL we used to represent profile by notes but it never worked very
well (in fact we never managed to use that information).  My experience
with any unrelated anotations on instruction stream is very bad.
Perhaps it can be done somehow in significantly better way, but RTL
scheme of REG_EQUIV/LOOP/SCOPE and similar notes has ever brought us
headaches.

Honza
> 
> Andrew


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