Re: [patch] Fix behavior of TER on unrolled loops

[Daniel Berlin <dberlin at dberlin dot org>]

On Mon, 2005-08-22 at 18:32 -0400, Daniel Berlin wrote:
> On Tue, 2005-08-23 at 00:14 +0200, Bernd Schmidt wrote:
> > Daniel Berlin wrote:
> > 
> > > The middle end is supposed to be *completely target independent*.
> > > We've *already* added crap to setup addressing modes and things that
> > > don't really belong in the middle end (NOTE: I have no problem if you
> > > want the first part of the backend to be SSA on trees or something).
> > 
> > Is this a quest for theoretical perfection, or is there a really good 
> > reason why you don't want target dependencies?
> 
> You are joking right?
> 
> > Seems to me that for a lot of things, e.g. loop optimizations, you 
> > really need to know target details such as addressing modes,
> What?
> You must be thinking of different types of loop opts than i am.
> What high level loop optimization do you think requires knowledge of
> addressing modes?

I should also point out that putting target specific addressing modes,
etc, in the Il actually very badly interferes with most high level loop
opts

You really want to see everything as a nice, clean, set of array
accesses, *even if it was originally pointer arithmetic*

> 
> >  so why hide 
> > that from the compiler?
> 
> So you can have a sanely seperated, maintainable, and functional
> compiler?
> 

Otherwise, why not just have it all have complete target knowledge from
the get go, and have the frontend start trying to generate target
optimal code as soon as it can.