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