public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Florian Weimer <fweimer@redhat.com>, Dave Martin <Dave.Martin@arm.com>
Cc: <nd@arm.com>, <libc-alpha@sourceware.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Marc Zyngier <Marc.Zyngier@arm.com>, <gdb@sourceware.org>,
	Yao Qi <qiyaoltc@gmail.com>,
	<linux-arm-kernel@lists.infradead.org>,
	Alan Hayward <alan.hayward@arm.com>,
	Torvald Riegel <triegel@redhat.com>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
Date: Mon, 05 Dec 2016 11:07:00 -0000	[thread overview]
Message-ID: <58454A60.7000206@arm.com> (raw)
In-Reply-To: <0293f7d3-b3d3-1a68-5b99-75db195eb796@redhat.com>

On 05/12/16 10:44, Florian Weimer wrote:
>>> By the way, how is this implemented?  Some of them overlap existing
>>> callee-saved registers.
>>
>> Basically, all the *new* state is caller-save.
>>
>> The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view
>> Zn[bits 127:0] is callee-save for all n = 8..15.
> 
> Are the extension parts of registers v8 to v15 used for argument passing?
> 
> If not, we should be able to use the existing dynamic linker trampoline.
> 

if sve arguments are passed to a function then it
has special call abi (which is probably not yet
documented), this call abi requires that such a
call does not go through plt to avoid requiring
sve aware libc.

same for tls access: the top part of sve regs have
to be saved by the caller before accessing tls so
the tlsdesc entry does not have to save them.

so current trampolines should be fine.

  reply	other threads:[~2016-12-05 11:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-25 19:39 Dave Martin
2016-11-25 19:39 ` [RFC PATCH 01/29] arm64: signal: Refactor sigcontext parsing in rt_sigreturn Dave Martin
2016-11-25 19:39 ` [RFC PATCH 03/29] arm64: signal: factor out signal frame record allocation Dave Martin
2016-11-25 19:39 ` [RFC PATCH 02/29] arm64: signal: factor frame layout and population into separate passes Dave Martin
2016-11-25 19:40 ` [RFC PATCH 05/29] arm64: signal: Parse extra_context during sigreturn Dave Martin
2016-11-25 19:40 ` [RFC PATCH 04/29] arm64: signal: Allocate extra sigcontext space as needed Dave Martin
2016-11-25 19:41 ` [RFC PATCH 17/29] arm64/sve: signal: Dump Scalable Vector Extension registers to user stack Dave Martin
2016-11-25 19:41 ` [RFC PATCH 18/29] arm64/sve: signal: Restore FPSIMD/SVE state in rt_sigreturn Dave Martin
2016-11-25 19:41 ` [RFC PATCH 24/29] arm64/sve: Discard SVE state on system call Dave Martin
2016-11-25 19:41 ` [RFC PATCH 16/29] arm64/sve: signal: Add SVE state record to sigcontext Dave Martin
2016-11-30  9:56 ` [RFC PATCH 00/29] arm64: Scalable Vector Extension core support Yao Qi
2016-11-30 12:07   ` Dave Martin
2016-11-30 12:22     ` Szabolcs Nagy
2016-11-30 14:10       ` Dave Martin
2016-11-30 12:38     ` Florian Weimer
2016-11-30 13:56       ` Dave Martin
2016-12-01  9:21         ` Florian Weimer
2016-12-01 10:30           ` Dave Martin
2016-12-01 12:19             ` Dave Martin
2016-12-05 10:44             ` Florian Weimer
2016-12-05 11:07               ` Szabolcs Nagy [this message]
2016-12-05 15:05               ` Dave Martin
2016-12-02 11:49       ` Dave Martin
2016-12-02 16:34         ` Florian Weimer
2016-12-02 16:59           ` Joseph Myers
2016-12-02 18:21             ` Dave Martin
2016-12-02 21:57               ` Joseph Myers
2016-12-02 21:56     ` Yao Qi
2016-12-05 15:12       ` Dave Martin
2016-12-05 22:42     ` Torvald Riegel
2016-12-06 14:46       ` Dave Martin
2016-11-30 10:08 ` Florian Weimer
2016-11-30 11:06   ` Szabolcs Nagy
2016-11-30 14:06     ` Dave Martin

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=58454A60.7000206@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=alan.hayward@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=christoffer.dall@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nd@arm.com \
    --cc=qiyaoltc@gmail.com \
    --cc=triegel@redhat.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).