[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: msp430 port
From:       Richard Henderson <rth () redhat ! com>
Date:       2013-07-31 20:20:55
Message-ID: 51F971A7.8080804 () redhat ! com
[Download RAW message or body]

On 07/31/2013 07:08 AM, DJ Delorie wrote:
>>> The first doesn't have a clobber, though...
>>
>> Hmm.  Missed that.  So the only reason you'd care to include the bic
>> in the regular and pattern is if it were a smaller encoding than the
>> regular r/0/i alternative.
> 
> It is, but the separate pattern picks that out just fine.

That depends on how we get here.  Consider an AND insn with r/0/r
operands, and the second register gets spilled, and reload proves
that it held an immediate.  In that case reload will only consider
the r/0/i alternative, and the shorter bic sequence.

One can always split away the clobber post-reload.  Not that your
port currently makes significant use of the flags register to
worry about it.

>> You need to implement the "return" pattern as well as "simple_return".
>> They don't actually have to be different, implementation-wise.  See
>> the i386 version, where both named patterns expand to the same insn.
> 
> How is this an advantage from just building the return from the epilog
> expander?

The code in function.c might transform

	saves
	if arg == 0 return;
	something
	restores
	return

to

	if arg == 0 return;
	saves
	something
	restores
	return

Of course... now that I think about it, that transform really only applies
to saves using a move-like insn, not a push-like insn.  So ignore me here
and don't define simple_return.

OTOH, a normal "return" insn can still be helpful, usually predicated on
not having a stack frame.  See i386 "return" for an example here.  The
benefit will be branch-to-return will be replaced with a plain return.

>> If you only need them post-reload, follow the lead of the s390 port.
>> See the "load_multiple" and "store_multiple" expanders, and their
>> associated insns.  In this case, everything folds nicely down with
>> a match_parallel.
> 
> Will do.

See also m68k, if you'd like another example.


r~

[prev in list] [next in list] [prev in thread] [next in thread]