This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Autoincrement addressing modes
- To: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Subject: Re: Autoincrement addressing modes
- From: Richard Henderson <rth at cygnus dot com>
- Date: Tue, 17 Mar 1998 01:16:32 -0800
- Cc: "Michael P. Hayes" <michaelh at ongaonga dot chch dot cri dot nz>, rth at cygnus dot com, egcs at cygnus dot com
- References: <199803170002.AAA24152@ongaonga.chch.cri.nz> <199803170004.AAA09012@phal.cygnus.co.uk>
- Reply-To: Richard Henderson <rth at cygnus dot com>
> Seconded. This even applies to some RISC pattern, e.g. sign/zero extension
> can be a register-register operation or a memory-register operation.
> The way gcc is designde we have to use a single pattern for this so that
> reload can do The Right Thing (tm).
Good point. Perhaps the thing to do then is to tie addresses
to instruction types, a-la
(define_attr "type" "ld,st,lea")
(define_address "base"
(mem (match_operand:PI 0 "register_operand" "r"))
(eq_attr "type" "ld,st,lea")
"0(%0)")
(define_address "auto_inc"
(mem (post_inc (match_operand:PI 0 "register_operand" "r")))
(eq_attr "type" "ld")
"(%0)+")
This would then let us have arbitrarily complex conditions that
the insn must satisfy before the address strictly matches.
Not sure exactly how we'd notice that insn type "ist" is a store,
for early (pre-reload) optimizations for things like auto_inc.
Perhaps with magic attributes on the addresses themselves, though
it would be nicer to discover these kinds of things rather than
having to be told.
r~