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: Jeff Law <law at redhat dot com>
- To: Steve Ellcey <sellcey at cavium dot com>, Alan dot Haward at arm dot com, "Richard Earnshaw (lists)" <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>, richard dot sandiford at linaro dot org
- Date: Sun, 27 May 2018 09:59:31 -0600
- Subject: Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP
- 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>
On 05/26/2018 04:09 AM, Richard Sandiford wrote:
> Steve Ellcey <sellcey@cavium.com> writes:
>> On Wed, 2018-05-16 at 22:11 +0100, Richard Sandiford wrote:
>>>
>>> TARGET_HARD_REGNO_CALL_PART_CLOBBERED is the only current way
>>> of saying that an rtl instruction preserves the low part of a
>>> register but clobbers the high part. We would need something like
>>> Alan H's CLOBBER_HIGH patches to do it using explicit clobbers.
>>>
>>> Another approach would be to piggy-back on the -fipa-ra
>>> infrastructure
>>> and record that vector PCS functions only clobber Q0-Q7. If -fipa-ra
>>> knows that a function doesn't clobber Q8-Q15 then that should
>>> override
>>> TARGET_HARD_REGNO_CALL_PART_CLOBBERED. (I'm not sure whether it does
>>> in practice, but it should :-) And if it doesn't that's a bug that's
>>> worth fixing for its own sake.)
>>>
>>> Thanks,
>>> Richard
>>
>> Alan,
>>
>> I have been looking at your CLOBBER_HIGH patches to see if they
>> might be helpful in implementing the ARM SIMD Vector ABI in GCC.
>> I have also been looking at the -fipa-ra flag and how it works.
>>
>> I was wondering if you considered using the ipa-ra infrastructure
>> for the SVE work that you are currently trying to support with
>> the CLOBBER_HIGH macro?
>>
>> My current thought for the ABI work is to mark all the floating
>> point / vector registers as caller saved (the lower half of V8-V15
>> are currently callee saved) and remove
>> TARGET_HARD_REGNO_CALL_PART_CLOBBERED.
>> This should work but would be inefficient.
>>
>> The next step would be to split get_call_reg_set_usage up into
>> two functions so that I don't have to pass in a default set of
>> registers. One function would return call_used_reg_set by
>> default (but could return a smaller set if it had actual used
>> register information) and the other would return regs_invalidated
>> by_call by default (but could also return a smaller set).
>>
>> Next I would add a 'largest mode used' array to call_cgraph_rtl_info
>> structure in addition to the current function_used_regs register
>> set.
>>
>> Then I could turn the get_call_reg_set_usage replacement functions
>> into target specific functions and with the information in the
>> call_cgraph_rtl_info structure and any simd attribute information on
>> a function I could modify what registers are really being used/invalidated
>> without being saved.
>>
>> If the called function only uses the bottom half of a register it would not
>> be marked as used/invalidated. If it uses the entire register and the
>> function is not marked as simd, then the register would marked as
>> used/invalidated. If the function was marked as simd the register would not
>> be marked because a simd function would save both the upper and lower halves
>> of a callee saved register (whereas a non simd function would only save the
>> lower half).
>>
>> Does this sound like something that could be used in place of your
>> CLOBBER_HIGH patch?
>
> One of the advantages of CLOBBER_HIGH is that it can be attached to
> arbitrary instructions, not just calls. The motivating example was
> tlsdesc_small_<mode>, which isn't treated as a call but as a normal
> instruction. (And I don't think we want to change that, since it's much
> easier for rtl optimisers to deal with normal instructions compared to
> calls. In general a call is part of a longer sequence of instructions
> that includes setting up arguments, etc.)
Yea. I don't think we want to change tlsdesc*. Representing them as
normal insns rather than calls seems reasonable to me.
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.
Jeff