This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP
- From: Alan Hayward <Alan dot Hayward at arm dot com>
- To: Richard Sandiford <richard dot sandiford at linaro dot org>
- Cc: Jeff Law <law at redhat dot com>, Steve Ellcey <sellcey at cavium dot com>, "Richard Earnshaw" <Richard dot Earnshaw at arm dot com>, Francesco Petrogalli <Francesco dot Petrogalli at arm dot com>, James Greenhalgh <James dot Greenhalgh at arm dot com>, "Sekhar, Ashwin" <Ashwin dot Sekhar at cavium dot com>, gcc <gcc at gcc dot gnu dot org>, "Marcus Shawcroft" <Marcus dot Shawcroft at arm dot com>, nd <nd at arm dot com>
- Date: Thu, 31 May 2018 10:39:19 +0000
- Subject: Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP
- Nodisclaimer: True
- References: <1518212868.14236.47.camel@cavium.com> <32617133-64DC-4F62-B7A0-A6B417C5B14E@arm.com> <1526487700.29509.6.camel@cavium.com> <a8761c95-e4fb-dd92-8988-825c8b34475f@arm.com> <1526491802.29509.19.camel@cavium.com> <87a7sznw5c.fsf@linaro.org> <1527184223.22014.13.camel@cavium.com> <87a7smbuej.fsf@linaro.org> <a94b6e17-fbf7-1dc3-b65c-cac4b476b06e@redhat.com> <871sdubwv6.fsf@linaro.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
(Missed this thread initially due to incorrect email address)
> On 29 May 2018, at 11:05, Richard Sandiford <richard.sandiford@linaro.org> wrote:
>
> Jeff Law <law@redhat.com> writes:
>> Now that we're in stage1 I do want to revisit the CLOBBER_HIGH stuff.
>> When we left things I think we were trying to decide between
>> CLOBBER_HIGH and clobbering the appropriate subreg. The problem with
>> the latter is the dataflow we compute is inaccurate (overly pessimistic)
>> so that'd have to be fixed.
Yes, I want to get back to looking at this again, however I’ve been busy
elsewhere.
>
> The clobbered part of the register in this case is a high-part subreg,
> which is ill-formed for single registers. It would also be difficult
> to represent in terms of the mode, since there are no defined modes for
> what can be stored in the high part of an SVE register. For 128-bit
> SVE that mode would have zero bits. :-)
>
> I thought the alternative suggestion was instead to have:
>
> (set (reg:M X) (reg:M X))
>
> when X is preserved in mode M but not in wider modes. But that seems
> like too much of a special case to me, both in terms of the source and
> the destination:
Agreed. When I looked at doing it that way back in Jan, my conclusion was
that if we did it that way we end up with more or less the same code but
instead of:
if (GET_CODE (setter) == CLOBBER_HIGH
&& reg_is_clobbered_by_clobber_high(REGNO(dest), GET_MODE (rsp->last_set_value))
Now becomes something like:
if (GET_CODE (setter) == SET
&& REG_P (dest) && HARD_REGISTER_P (dest) && REG_P (src) && REGNO(dst) == REGNO(src)
&& reg_is_clobbered_by_self_set(REGNO(dest), GET_MODE (rsp->last_set_value))
Ok, some of that code can go into a macro, but it feel much clearer to
explicitly check for CLOBBER_HIGH rather then applying some special semantics
to a specific SET case.
Alan.