This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)


On 06/10/2014 04:03 PM, Joern Rennecke wrote:
> On 13 May 2014 22:41, Oleg Endo <oleg.endo@t-online.de> wrote:
>
>> Right.  I was thinking to add FPSCR.SZ mode switching to SH, in order to
>> do float vector moves.  For that SZ and PR need to be switched both at
>> the same time (only SH4A has both, fpchg and fschg).  So basically I'd
>> add another mode entity, which would emit SZ mode changes in addition to
>> the PR mode changes.  But then adjacent FPSCR-changing insns could be
>> combined ... any idea/suggestion how to accomplish that?
> If they are sufficiently adjacent, you can use a peephole2 pattern for this.
>
> I see Cristian's patch addresses this in a different way - keeping size and
> precision in the same entity, and emitting toggles as appropriate.

yes, I was only interested to optimize the SH4a case when PR=1 with a
good enough implementation. To cover all the other possibilities a new
entity would be better. But then as you say recombining them might be
difficult.  An alternate hackish way could be to have a singe entity
with 4 modes covering all PR*SZ combinations).

but I'm not sure that covering the case where PR=0 SZ=1 worth it, maybe
code size only, ? as the 64 move would be implemented as 2*32 moves anyway,

>
> The problem get's a bit more interesting if you have some instruction patterns
> that care about one setting but not the other.
> Describing this exactly allows lazy code motion to be a bit more lazy, but OTOH
> it can make it harder to combine mode switching instructions if you
> still want to
> do that.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]