public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Steve Ellcey <sellcey@cavium.com>,
	Alan.Haward@arm.com,
	"Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>,
	Francesco Petrogalli <Francesco.Petrogalli@arm.com>,
	James Greenhalgh <James.Greenhalgh@arm.com>,
	"Sekhar, Ashwin" <Ashwin.Sekhar@cavium.com>,
	gcc <gcc@gcc.gnu.org>,
	Marcus Shawcroft <Marcus.Shawcroft@arm.com>, nd <nd@arm.com>,
	richard.sandiford@linaro.org
Subject: Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP
Date: Sun, 27 May 2018 15:59:00 -0000	[thread overview]
Message-ID: <a94b6e17-fbf7-1dc3-b65c-cac4b476b06e@redhat.com> (raw)
In-Reply-To: <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

  parent reply	other threads:[~2018-05-27 15:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-09 21:47 Steve Ellcey
2018-05-15 18:29 ` Francesco Petrogalli
2018-05-16 16:21   ` Steve Ellcey
2018-05-16 16:30     ` Richard Earnshaw (lists)
2018-05-16 17:30       ` Steve Ellcey
2018-05-16 21:11         ` Richard Sandiford
2018-05-24 17:50           ` Steve Ellcey
2018-05-26 10:09             ` Richard Sandiford
2018-05-26 22:13               ` Segher Boessenkool
2018-05-27 15:59               ` Jeff Law [this message]
2018-05-29 10:06                 ` Richard Sandiford
2018-05-31 10:39                   ` Alan Hayward
2018-06-12  3:11                     ` Jeff Law
2018-06-11 23:06                   ` Jeff Law
2018-07-02 18:16     ` Francesco Petrogalli
  -- strict thread matches above, loose matches on Subject: below --
2017-03-15  9:50 Sekhar, Ashwin
2017-03-17 14:02 ` James Greenhalgh
2017-03-20  4:30   ` Sekhar, Ashwin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a94b6e17-fbf7-1dc3-b65c-cac4b476b06e@redhat.com \
    --to=law@redhat.com \
    --cc=Alan.Haward@arm.com \
    --cc=Ashwin.Sekhar@cavium.com \
    --cc=Francesco.Petrogalli@arm.com \
    --cc=James.Greenhalgh@arm.com \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=nd@arm.com \
    --cc=richard.sandiford@linaro.org \
    --cc=sellcey@cavium.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).