On Tue, Dec 10, 2013 at 10:26 AM, Richard Sandiford
<rdsandif...@googlemail.com> wrote:
> "H.J. Lu" <hjl.to...@gmail.com> writes:
>> On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
>> <rdsandif...@googlemail.com> wrote:
>>> "H.J. Lu" <hjl.to...@gmail.com> writes:
>>>> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
>>>> <kirill.yuk...@gmail.com> wrote:
>>>>> On 09 Dec 14:08, H.J. Lu wrote:
>>>>>>
>>>>>> There are no regressions on Linux/x86-64 with -m32 and -m64.
>>>>>> Can you check if it improves code quality on x886?
>>>>>
>>>>> As second thought. If Tejas and Richard are right and it is simply
>>>>> incorrect
>>>>> to check any offsets in this hook, may be we can end up with patch in the
>>>>> bottom?
>>>>
>>>> What is wrong to pass the correct offset to
>>>> CANNOT_CHANGE_MODE_CLASS? Backends are free to
>>>> ignore it.
>>>
>>> The point is that:
>>>
>>>>> - /* Vector registers do not support subreg with nonzero offsets,
>>>>> which
>>>>> - are otherwise valid for integer registers. Since we can't see
>>>>> - whether we have a nonzero offset from here, prohibit all
>>>>> - nonparadoxical subregs changing size. */
>>>>> - if (GET_MODE_SIZE (to) < GET_MODE_SIZE (from))
>>>>> - return true;
>>>
>>> seems to be trying to reject things like (subreg:SF (reg:V4SF X) 1),
>>> which is always invalid for a single-register V4SF. See:
>>
>> That is correct.
>
> Sorry, what I mean is: that subreg is always invalid for single-
> register V4SFs regardless of the target. This isn't something that
> CANNOT_CHANGE_MODE_CLASS should be expected to check.
>
Why is
(define_insn "*movv4sfdi_subreg"
[(set (match_operand:DI 0 "nonimmediate_operand" "=rxm")
(subreg:DI (match_operand:V4SF 1 "register_operand" "x") 0))]
invalid? It can be used in libffi.call/struct8.c. hjl/subreg branch
generates
movq %xmm0, %xmm0 # 39 *movv4sfdi_subreg [length = 4]
instead of
movq -56(%rsp), %xmm0 # 44 *movdi_internal/15 [length = 7]
both clears upper 64 bits in %xmm0.
--
H.J.
