Re: About Regmove !!

[tm <tm at mail dot kloo dot net>]

On Tue, 12 Nov 2002, Jeff Law wrote:

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

Is there a particular reference you have in mind which covers handling
addressing inheritance in GCSE?

To me, it seems very awkward to have address inheritance handled by GCSE.

In order to generate efficient address inheritance, the addressing mode of
an instruction may need to be changed. This implies GCSE will need to
understand all of the target CPU's addressing modes and allowable
displacements for each one.

I believe this would require dragging a lot of target-dependent
information into an optimization pass which should be mostly
target-independent. It sounds cleaner to isolate the target-dependent
addressing mode knowledge in a separate pass specifically designed for
optimizing addressing modes.

Toshi