On 06/10/2014 04:03 PM, Joern Rennecke wrote: > On 13 May 2014 22:41, Oleg Endo <oleg.e...@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.
