This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Your Jan 15 change broke the x86
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: Your Jan 15 change broke the x86
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 31 Jan 1999 14:25:29 -0700
- cc: egcs-patches at cygnus dot com, drepper at cygnus dot com
- Reply-To: law at cygnus dot com
In message <19990131131438.A17484@cygnus.com>you write:
> On Sun, Jan 31, 1999 at 01:46:55PM -0700, Jeffrey A Law wrote:
> > I'm a little suprised "bm" was shoved into memory.
>
> This is -O0, remember? Of course it lives in memory.
Oh yea. Duh.
> Yes, but they allow memory only of a very particular form. And
> at rtl generation time that form _only_ exists in push instructions
> created by expand_call. So there's no point in matching them.
Ah. Yes, the effected function is only called during rtl generation.
> Or is there? Come to think of it, how can you possibly usefully
> use "<" by itself as an input constraint from an asm? There does
> not appear to be any code whatsoever to create an address of the
> proper form, so the only way it could be used is in conjunction
> with another memory specifier. Even then I can't see how specifying
> "o<>" wins over "m" -- in an asm you can't select different code
> sequences based on alternative or whatnot.
Are autoinc addresses always offsettable? A reloaded autoinc is offsettable,
but I'm not sure a raw autoinc is offsettable.
Also some targets only allow limited autoinc addressing -- so an autoinc may
not match a 'm'. Consider a target which can do postinc loads and preinc
stores only. For such a port 'm' would not match an autoinc address.
jeff