Fix g++.dg/tree-ssa/ivopts-1.C for cris-elf

Hans-Peter Nilsson hans-peter.nilsson@axis.com
Mon Oct 29 12:14:00 GMT 2007


> Date: Mon, 29 Oct 2007 03:58:31 +0100
> From: Zdenek Dvorak <rakdver@kam.mff.cuni.cz>

> > - For an address to be considered validly containing a multiple
> > of a register (mult reg N), that must be valid as an address on
> > its own.  This can't be very common; I believe most machines
> > having that capability requires at least a register to that
> > mult, like (plus (mult reg N) reg).  Something for the next
> > stage 1.
> 
> well, the thing is that the only major architecture that has
> multiplication addressing modes is x86, and the code was written to work
> there.  If you have a target for that multiplier_allowed_in_address_p
> does not work, I guess you can send a patch for it now, and not wait for
> stage1 -- it is a fairly localized change, and very likely it would also
> fix a regression (as in 3.something, before removal of the old loop
> optimizer, the addressing mode would most likely be created).
> 
> If not, making the function work for a hypothetical target does not
> seem useful to me.

The point was that as an address, (mult reg N) is unusable on
its own (you need "(plus (mult reg N) reg)"), yet it's a
prerequisite for scaled addressing to be recognised there.  That
it's actually valid for x86 seems just unfortunate.  CRIS and at
least m68k (yeah, I know, major targets... :) have (plus (mult
reg N) reg).

> No -- of course the call to memory_address can cause RTX to be
> generated (it does that all the time).

Sorry, I confused it with memory_address_p :)

brgds, H-P



More information about the Gcc-patches mailing list