This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] nvptx: implement automatic storage in custom stacks


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]