This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] nvptx: implement automatic storage in custom stacks
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Bernd Schmidt <bschmidt at redhat dot com>, Dmitry Melnik <dm at ispras dot ru>
- Date: Mon, 30 Nov 2015 14:14:41 +0300 (MSK)
- Subject: Re: [PATCH] nvptx: implement automatic storage in custom stacks
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LNX dot 2 dot 20 dot 1511121609140 dot 3050 at monopod dot intra dot ispras dot ru> <20151130103237 dot GY5675 at tucnak dot redhat dot com>
On Mon, 30 Nov 2015, Jakub Jelinek wrote:
> Does your patch affect all the stack allocations within certain function
> (i.e. no way to select on a per-variable bases what stack to allocate it
> to)? Without any detailed analysis at least e.g. spilled (non-addressable)
> vars could at least go to the local stack. But PTX doesn't have any spills,
> right? Not sure about HSA. If it is a per-function thing only, then it
> isn't worth to do more detailed analysis at the ompexp time.
Yes, there's no register allocation and thus no spills on PTX.
> BTW, surely it will be an advantage if PTX can support alloca through this,
> it could e.g. turn on -msoft-stack for all functions that use alloca/VLAs
> automatically.
Yes, I'm going to support alloca on soft stacks, but, -msoft-stack has a
prerequisite of soft stacks being initially set up. Therefore I'm treating it
as an ABI variant (together with another option to handle atomics and
"syscalls" outside of simd regions), and building a separate multilib for
that. So I see it the other way around: it's not safe for the compiler to
always use soft-stacks for alloca (because OpenACC wouldn't set up soft
stacks), but if soft stacks are enabled, alloca can use them.
In the multilib variant that I'm introducing, all addressable vars go to soft
stacks, and classic .local stacks are used rarely, e.g. for stdarg passing,
and implicitely for calls/returns (and after JIT, they'll service register
spills too).
Alexander