This is the mail archive of the
mailing list for the GCC project.
Re: Fix g++.dg/tree-ssa/ivopts-1.C for cris-elf
- From: Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: gcc-patches at gcc dot gnu dot org, ook at ucw dot cz
- Date: Mon, 29 Oct 2007 03:58:31 +0100
- Subject: Re: Fix g++.dg/tree-ssa/ivopts-1.C for cris-elf
- References: <200710290033.l9T0X5pc019553@ignucius.se.axis.com>
> I noticed some random warts in tree-ssa-loop-ivopts.c while in
> that gdb-session:
> - 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.
> - If the address cost is 0, it is "upgraded" to 1 at line 2981,
> (causing there to be no difference between costs 0 and 1). I
> see no reason for this; there's nothing saying 0 is odd for an
> address cost. In fact, (by visual inspection) the default value
> for the address cost of a register is 0. In the next stage 1, I
> suggest this be changed to just add 1 to acost unilaterally
yes, this seems like a good idea to me (additionally, I would suggest
subtracting 1 in the return statement, so that we do not change the
value in the other cases). In fact, if it improves the code on cris,
that patch might also be acceptable in stage 3 (assuming that you run
benchmarks on at least some of the primary platforms to ensure that it
does not cause performance regressions there).
> it really needs to be > 0, but I'm also unsure why that code
> takes the cost of a containing sequence; it seems to believe
> calls to memory_address can cause RTX to be generated; that'd be
> a bug, right?
No -- of course the call to memory_address can cause RTX to be
generated (it does that all the time).