This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Christian Bruel <christian dot bruel at st dot com>
- Cc: Joern Rennecke <joern dot rennecke at embecosm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- Date: Wed, 11 Jun 2014 23:16:19 +0200
- Subject: Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
- Authentication-results: sourceware.org; auth=none
- References: <535E0C86 dot 400 at st dot com> <537089D8 dot 8040106 at st dot com> <53708F1D dot 1080308 at st dot com> <CAMqJFCpxG2RyOZ0NsYiBV5PUU4A+8kWaq22am+GR=e22i-uf0g at mail dot gmail dot com> <5370BB9D dot 1090803 at st dot com> <CAMqJFCovAjbuJK6puakdUZu-mDdUdWS92exwLdz3fKGO+goMZA at mail dot gmail dot com> <1399934352 dot 2344 dot 26 dot camel at yam-132-YW-E178-FTW> <CAMqJFCrBAmXuBe6JVifM-wEvN05Ny8AEsbBT0TfmHistSWfr-Q at mail dot gmail dot com> <1400017263 dot 2344 dot 34 dot camel at yam-132-YW-E178-FTW> <CAMqJFCrRL0YLA9D0Oe56HU8_6f3JjVX+PwONPQfryVoc6NsUkw at mail dot gmail dot com> <53984E3A dot 5070702 at st dot com>
On 11 Jun 2014, at 14:40, Christian Bruel <christian.bruel@st.com> wrote:
>
> 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,
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