On 11 Jun 2014, at 14:40, Christian Bruel <christian.br...@st.com> wrote:
> > 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, I was thinking of using PR=0,SZ=1 mode (i.e. fmov.d) for float vector loads/stores. But at the moment that's a pie in the sky. Cheers, Oleg
