This is the mail archive of the 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] Temporary Expression Replacement in SSA->normal.

On Fri, 2003-11-28 at 16:42, Jan Hubicka wrote:
> > On Fri, 2003-11-28 at 16:09, Jan Hubicka wrote:
> > > > On Fri, 2003-11-28 at 15:15, Zack Weinberg wrote:

> > I would expect to see less benefit on machines with lots of registers,
> > but I haven't measured it. The original thought was to turn it off for
> > machines like that, but I dont think anyone has measured it.
> Actually the register allocator interaction should be completely solved
> by webizer.  I just tested that TER saves about 400 instructions on
> combine, when webizer is used and about 1000 instruction when webizer is
> not used.

I spent a couple of days doing runtime measurement and examination of
generated code to determine what was causing our branch to be slower,
and thats what eventually caused me to implement TER. 

> So it seems in addition to problem with temporaries expanders are still
> more smart when dealing with complex expressions.  Except for getting
> more folding I think it can be some cases where memory operand is
> involved.  Perhaps like we do for constants in CCP we may consider using
> nested loads/stores in late GIMPLE forms.
> Or perhaps make the SSA infromation visible to the expanders so they may
> ask questions about operands (their ranges, wehther they are memory
> operands load just once, or so on)

In a perfect world, the back end ought to create better code when
presented with GIMPLE, which I think is why there is a desire to pass
GIMPLE stright to the expanders. I dont think making SSA information
visible to the expanders or other mid-term solutions will accomplish
much more than TER does. 

My theory is that once we get into mainline, (or maybe before :-),
someone who works on the various bits of widgitry can use -fno-tree-ter
as input to improve that widgit. Its quite a good exercise for the
register allocators in particular, and it will provide very good source
for a rematerialization pass.  I would also think that some of the
apparent smarts in the expanders would be moved to a beefed up combiner
and/or other parts since, as Zack points out, that is the right place to
do that sort of thing.

I think those are the proper places to fix it. TER was a quick solution
to the overall problem by presenting the combiner with the same kind of
trees they currently expect to see.


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