This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Vladimir Makarov <vmakarov at redhat dot com>
- Date: Tue, 5 Jan 2016 20:30:41 +0100
- Subject: Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint
- Authentication-results: sourceware.org; auth=none
- References: <20151230205333 dot GA1877 at gmail dot com> <CAFULd4bAa2+Jn10-wnLzTVkUWVh1KOgpCA8LM1DMUDAyNb2baA at mail dot gmail dot com> <CAMe9rOrYmTPPFE3mre7kcWEGoHJx32ogQ60J1gPryo2d593nKg at mail dot gmail dot com> <CAFULd4Y5HmdwT_N9n_ZDcj6W54tuT37Z-D+k_VYM2qentfVDyw at mail dot gmail dot com> <9193C1A5-1430-49CF-9F47-CB673218BA30 at gmail dot com> <CAMe9rOoKtKo_xV0Nn7ufNowXjfkS4XsLnifHPVTCUCCobFM8ew at mail dot gmail dot com> <CAMe9rOreR+8cxrTvw-f-WtMUVq6F_XhDJ6yYFwxjLd5orWiExw at mail dot gmail dot com> <CAFULd4YKifWmi0hMuTZALd1xzEKQAZ_G=q4vRJBQU_iEvYm5kA at mail dot gmail dot com> <CAMe9rOqJY-uOd5sQBqphv9NakPTE5oog0FwoQf3-oyRPeZzOHg at mail dot gmail dot com> <CAMe9rOpOhuBk46DHFkdJymGcD89yDH+GGeongQSkK4txN_e-Uw at mail dot gmail dot com> <20160105081120 dot GQ18720 at tucnak dot redhat dot com> <CAMe9rOq5FT9HafS6Eq9_4qSoEtZVKrwmiX=0SDPPxBf7wPvUcw at mail dot gmail dot com> <CAMe9rOpy6AZYMVoM=S2Y4boYfQkTyOcwWP8=e93W6AExTR0dww at mail dot gmail dot com> <CAFULd4bvW-FkqoP2kQ=ksHrK7kQW5sJrKG1-42ggmF2+-z2i1A at mail dot gmail dot com> <CAMe9rOrfu85kuLne7cVuK6En-wp6ErxiN+AixXM6dUQ6D56aFg at mail dot gmail dot com>
On Tue, Jan 5, 2016 at 8:20 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Jan 5, 2016 at 11:14 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> On Tue, Jan 5, 2016 at 7:58 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Tue, Jan 5, 2016 at 4:32 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Tue, Jan 5, 2016 at 12:11 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>>>> On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote:
>>>>>> LRA is fine. I should use
>>>>>>
>>>>>> (define_memory_constraint "Bm"
>>>>>> "@internal Vector memory operand."
>>>>>> (match_operand 0 "vector_memory_operand"))
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>> (define_constraint "Bm"
>>>>>> "@internal Vector memory operand."
>>>>>> (match_operand 0 "vector_memory_operand"))
>>>>>
>>>>> I don't think so. At least the documentation says that
>>>>> define_memory_constraint is for MEM constraints where if they are not
>>>>> satisfied they can be made to satisfy by forcing the address into a
>>>>> register. But that is not the case here, if a MEM is misaligned, no
>>>>> equivalent changes to the XEXP (mem, 0) will make it aligned.
>>>>>
>>>>
>>>> You are right and *mov<mode>_internal must use the 'm' constraint
>>>> so that LRA won't keep generating the same reload for
>>>>
>>>> (insn 353 322 323 8 (set (reg:V4SF 192)
>>>> (reg:V4SF 201 [192])) 1226 {*movv4sf_internal}
>>>> (nil))
>>>>
>>>> until
>>>>
>>>> x.i: In function \u2018foo\u2019:
>>>> x.i:29:1: internal compiler error: Max. number of generated reload
>>>> insns per insn is achieved (90)
>>>>
>>>> }
>>>> ^
>>>>
>>>> 0xc0d635 lra_constraints(bool)
>>>> /export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:4336
>>>> 0xbf9854 lra(_IO_FILE*)
>>>> /export/gnu/import/git/sources/gcc/gcc/lra.c:2277
>>>> 0xba6489 do_reload
>>>> /export/gnu/import/git/sources/gcc/gcc/ira.c:5385
>>>> 0xba683c execute
>>>> /export/gnu/import/git/sources/gcc/gcc/ira.c:5556
>>>>
>>>>
>>>
>>> Here are the updated patches. I didn't change SSE
>>> *mov<mode>_internal. Tested on x86-64. OK for
>>> trunk?
>>
>> It is hard to determine the changed patterns - can you confirm that
>> only patterns where ssememalign=0 are changed?
>>
>> Uros.
>
> My patches only change SSE patterns without ssememalign
> attribute, which defaults to
>
> (define_attr "ssememalign" "" (const_int 0))
The patch is OK for mainline.
(subst.md changes can IMO be considered obvious.)
Thanks,
Uros.