Re: About Regmove !!

[Jeff Law <law at porcupine dot cygnus dot com>]

In message <Pine.LNX.4.21.0211121135190.12360-100000@mail.kloo.net>, tm writes:
 >On Tue, 12 Nov 2002, Jeff Law wrote:
 >> In message <Pine.LNX.4.21.0211121052080.12360-100000@mail.kloo.net>, tm wri
 >tes:
 >>  >On Tue, 12 Nov 2002, Michael Matz wrote:
 >>  >> 
 >>  >> > Does new-regalloc do address inheritance optimization?
 >>  >> 
 >>  >> No (t yet?).
 >>  >> 
 >>  >> > If not, can we retain the portion of regmove which implements this
 >>  >> > optimization?
 >>  >> 
 >>  >> Of course.
 >>  >
 >>  >Okay. Please keep this in mind.
 >> Note there are other ways to do this kind of optimization.   For example,
 >> look at how folks have integrated strength reduction and gcse.  Better
 >> yet, you get these optimizations on a global basis rather than local or
 >> extended basic block.
 >> 
 >> jeff
 >
 >Yep.
 >
 >The current implementation has one huge problem: it doesn't work well with
 >GCSE. What happens is that LEGITIMIZE_ADDRESS breaks up large offsets into
 >address arithmetic, then GCSE comes along and hoists part of the address
 >arithmetic into another basic block where regmove can't optimize it.
 >
 >It would be nice if we could run a regmove-like pass before GCSE, then use
 >GCSE as a back-end to link together the address inheritance chain across
 >basic blocks.
 >
 >Are there any obvious conceptual deficiencies with this approach?
Other than it should be a whole lot easier to have it integrated with
gcse.  ie, you don't need separate passes to do this optimization.  It
can (and should) be part of gcse.

regmove as it stands is, err, lame, unmanagable and can be done more
effectively with well known, well understood optimization algorithms.

jeff