This is the mail archive of the
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")
(mem (match_operand:PI 0 "register_operand" "r"))
(eq_attr "type" "ld,st,lea")
(mem (post_inc (match_operand:PI 0 "register_operand" "r")))
(eq_attr "type" "ld")
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.