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: Jakub Jelinek <jakub at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Uros Bizjak <ubizjak at gmail 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>, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Wed, 6 Jan 2016 10:23:07 +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> <87io37lnhl dot fsf at googlemail dot com> <CAFULd4Z77otLmLKTXJdX3gh_hpfhj25xPgcyzMdwfKOc004j+w at mail dot gmail dot com>
On Wed, Jan 6, 2016 at 10:18 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Tue, Jan 5, 2016 at 10:34 PM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> Jakub Jelinek <jakub@redhat.com> writes:
>>> 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.
>>
>> Yeah. It seems like a missing feature though. Maybe
>> define_memory_constraint should have two conditions, one for
>> when the MEM is valid and one for when the address is?
>> Guess that isn't stage 3 material though. And maybe longer-term
>> we should avoid define_memory_constraint altogether and have an
>> automatic way of testing whether replacing the address with a
>> register is OK.
If we are going in this direction, is it possible to make
define_memory_constraint more general, so it would return register
class, not only default BASE_REG_CLASS? Some x86_64 instructions can
use only non-REX registers (including registers in the address) when
high registers (%ah, %dh, %ch and %bh) are involved.
Uros.