Re: [RFC] Addressing Mode Selection Issues.

[Jim Wilson <wilson at specifixinc dot com>]

On Sun, 2003-11-30 at 04:18, Naveen Sharma, Noida wrote:
> No responses on this yet. So I request again. 
> I am cc-ing SH and IA-64 maintainers this time.
> base+large_offset abstraction might benefit IA64.

My time is consumed fixing IA-64 gcc bugs, answering questions, and
trying to help review patches for bug fixes.  I am not doing any
optimization related work at this time.  I don't have time for it.  I'm
leaving it for others.

> > This is fine for targets where cost of different addressing 
> > modes doesn't vary but not optimal for others like SH. 

rtx_costs is used in a number of places to choose addresses.

> > We might say that there is no good mechanism to chose an 
> > addressing mode such that address arithmetic/spills are 
> > minimized. 

There are a number of issues with SH.  One problem with SH is a poor
choice of ABI.  There is only one register that can be used for reg+reg
addresses, which is R0.  That register is also used for function return
values.  That leads to a conflict preventing optimal use of reg+reg
addresses.  Consider a call whose result needs to be stored at a stack
slot address more than 16 (?) bytes from the base register.  You need
two r0 registers to do this efficiently.  Getting the compiler to work
correctly without a reload abort in this case requires explicitly
avoiding reg+reg uses in other cases.  If you can't change the ABI (and
I've been suggesting this for close to a decade now...) then you have to
accept some performance loss.  Another problem is that the SH
architecture was explicitly designed for small code size.  While you can
get reasonable performance from it also, its design makes this
complicated.  You have to accept some addressing inefficiencies because
of the design of the architecture.  If you don't like this, consider
using a different architecture.  There is only so much that is
reasonable for gcc to do to try to work around deficiencies of the SH
architecture.  I consider a 4-bit displacement to be a deficiency.

For IA-64, yes, the lack of reg+offset addressing is a major bummer.  We
will have to do something about it eventually.  Offhand, I don't know
what we should do to solve it.

> > One solution could be to fake the standard addressing modes, the rtl
> > optimizers are comfortable with. And change to target's 
> > addressing mode
> > in a separate pass after sched1.

It is impossible to say whether this is a good idea without implementing
it first to see.  This would be a significant change, so you need good
justification for it, such as test results for several targets.

I doubt this would work well for CISC targets.  It is asking too much
for the new optimization pass to create the complicated addresses that
exist on CISC.  Even for RISCs, it may be asking a lot.  You would need
a bunch of optimizations like cse/combine/splitting/etc to avoid
inefficiencies in the resulting instructions.  Maybe it is possible, but
you would have to implement it first to see.

You have said nothing about auto-inc addresses.  These can be a curse,
restricting scheduler freedom, but they can also be a blessing in some
cases such as inner loops.  This is another thing you new optimization
pass would have to create.

Some of the scheduler problems can be solved by extending the
schedulers.  There is no reason why the scheduler can't rewrite
instructions to schedule across an apparent register addressing
conflict.  We just have never tried to write code for that.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com