This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Addressing Mode Selection Issues.
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Jim Wilson <wilson at specifixinc dot com>
- Cc: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>, gcc at gcc dot gnu dot org, Alexandre Oliva <aoliva at redhat dot com>, Joern Rennecke <joern dot rennecke at superh dot com>
- Date: Sun, 30 Nov 2003 21:23:30 -0500
- Subject: Re: [RFC] Addressing Mode Selection Issues.
- References: <1B3885BC15C7024C845AAC78314766C50139D9FF@EXCH-01> <1070243896.1032.26.camel@leaf.tuliptree.org>
>>>>> Jim Wilson writes:
> 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.
Jim> It is impossible to say whether this is a good idea without implementing
Jim> it first to see. This would be a significant change, so you need good
Jim> justification for it, such as test results for several targets.
Jim> I doubt this would work well for CISC targets. It is asking too much
Jim> for the new optimization pass to create the complicated addresses that
Jim> exist on CISC. Even for RISCs, it may be asking a lot. You would need
Jim> a bunch of optimizations like cse/combine/splitting/etc to avoid
Jim> inefficiencies in the resulting instructions. Maybe it is possible, but
Jim> you would have to implement it first to see.
This is somewhat related to an optimization technique called
reassociation, which tries to create addresses to most effectively use
"free" address computations provided by the architecture. Unfortunately,
the optimization is computationally intensive and GCC doesn't need to be
any slower.
I believe that some compilers for IA-64 create offset addresses
internally, because they assume that addressing mode exists, and then
squeeze them out at a later stage. Figuring out how to do that
effectively in GCC is research project.
David