[PING*2][PATCH] Extend mode-switching to support toggle (1/2)
Christian Bruel
christian.bruel@st.com
Wed Jun 11 12:40:00 GMT 2014
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.
More information about the Gcc-patches
mailing list