Re: [Patch, RTL] Eliminate redundant vec_select moves.

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Dec 9, 2013 at 5:48 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Dec 9, 2013 at 5:00 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Dec 9, 2013 at 1:56 AM, Tejas Belagod <tbelagod@arm.com> wrote:
>>> Kirill Yukhin wrote:
>>>>
>>>> Hello,
>>>>
>>>> On 05 Dec 16:40, Kirill Yukhin wrote:
>>>>>
>>>>> On 05 Dec 05:30, H.J. Lu wrote:
>>>>>>
>>>>>> Kirill, can you take a look why it doesn't work for x86?
>>>>>
>>>>> Okay, I'll look at this.
>>>>
>>>>
>>>> I've looked at this. It seems that `CANNOT_CHANGE_MODE_CLASS'
>>>> is too conservative for x86.
>>>>
>>>> In rtlanal.c we have `simplify_subreg_regno' which call target
>>>> hook `REG_CANNOT_CHANGE_MODE_P'. It takes only 3 arguments:
>>>> from mode, to mode and regclass.
>>>>
>>>> Hook in x86 called `ix86_cannot_change_mode_class' and comment
>>>> says that we cannot change mode for nonzero offsets, which sounds
>>>> quite reasonable. That is why this hook returns `true' for this
>>>> tuple <V4SF, SF, FIRST_SSE_REG> and `simplify_subreg_regno'
>>>> prohibits simplification of that:
>>>>   (set (reg:SF 21 xmm0 [orig:86 D.1816 ] [86])
>>>>        (vec_select:SF (reg:V4SF 21 xmm0 [87])
>>>>           (parallel [(const_int 0 [0])])))
>>>>
>>>> I think we can extend the hook and add `offset in frommode' to it.
>>>> We may set it to -1 for the cases where it is unknown and work
>>>> conservatively in the target hook.
>>>> For most cases offset is known and we could pass it to the hook.
>>>> This will require changes throughout all targets though.
>>>>
>>>> Alternatively, we may introduce another target hook, say
>>>> `CANNOT_CHANGE_MODE_CLASS_OFFSET' with same args as
>>>> `CANNOT_CHANGE_MODE_CLASS' + offset and which will be defaulted to it.
>>>> For x86 (and possibly other targets) we'll implement this hook, which
>>>> will checko ffset.
>>>>
>>>> What do you think?
>>>>
>>>
>>> I don't think CANNOT_CHANGE_MODE_CLASS has been designed with an intention
>>> to consider offsets. I thought all that magic about BYTE_OFFSET resolution
>>> into representable hardregs was done by subreg_get_info() where the
>>> info.representable is set to false if the BYTE_OFFSET of the subreg didn't
>>> map to a full hardreg. So if your (subreg:ymode (reg:xmode) off) maps to a
>>> full hardreg, simplify_subreg_regno should be returning the yregno
>>> automatically.
>>>
>>> That's my understanding, please feel free to correct me if I'm incorrect.
>>
>> Kirill, ARM doesn't define HARD_REGNO_NREGS_HAS_PADDING
>> and i386 does.  Could that be the cause?
>>
>
> Nevermind. I don't think it does.
>
>

Hi Kirll,

Here is a patch to add offset to CANNOT_CHANGE_MODE_CLASS.
I used MAX_BITSIZE_MODE_ANY_MODE / BITS_PER_UNIT offset
to indicate any offsets.

There are no regressions on Linux/x86-64 with -m32 and -m64.
Can you check if it improves code quality on x886?

Thanks.


-- 
H.J.

Attachment: 0001-Add-offset-to-CANNOT_CHANGE_MODE_CLASS.patch
Description: Text document