Re: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-06-09 Thread Alexander Monakov
On Thu, 9 Jun 2016, Nathan Sidwell wrote: > > (define_expand "restore_stack_block" > >[(match_operand 0 "register_operand" "") > > (match_operand 1 "register_operand" "")] > > you've not addressed my previous comments about this. To be clear -- do you mean that "restore_stack_block"

Re: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-06-09 Thread Nathan Sidwell
On 06/02/16 17:22, Alexander Monakov wrote: On Wed, 25 May 2016, Nathan Sidwell wrote: It seems like we should reject the combination of -msoft-stack -fopenacc? Possibly; the doc text makes it explicit that the option is exposed only for the purpose of testing the compiler, anyway. It is

Re: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-06-02 Thread Alexander Monakov
On Wed, 25 May 2016, Nathan Sidwell wrote: > > > It seems like we should reject the combination of -msoft-stack -fopenacc? > > > > Possibly; the doc text makes it explicit that the option is exposed only for > > the purpose of testing the compiler, anyway. > > It is always best to prevent the

Re: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-05-25 Thread Nathan Sidwell
On 05/24/16 17:29, Alexander Monakov wrote: On Fri, 20 May 2016, Nathan Sidwell wrote: ah, that's much more understandable, thanks. Presumably this doesn't support worker-single mode (in OpenACC parlance, I don't know what the OpenMP version of that is?) I don't see why you have concerns.

Re: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-05-24 Thread Alexander Monakov
On Fri, 20 May 2016, Nathan Sidwell wrote: > ah, that's much more understandable, thanks. Presumably this doesn't > support worker-single mode (in OpenACC parlance, I don't know what the OpenMP > version of that is?) I don't see why you have concerns. In OpenMP, what OpenACC calls

Re: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-05-20 Thread Nathan Sidwell
On 05/20/16 11:09, Alexander Monakov wrote: This patch implements '-msoft-stack' code generation variant for NVPTX. The goal is to avoid relying on '.local' memory space for placement of automatic data, and instead have an explicitely-maintained stack pointer (which can be set up to point to

Re: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-05-20 Thread Sandra Loosemore
On 05/20/2016 09:09 AM, Alexander Monakov wrote: diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index d281975..f0331e2 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -19341,6 +19341,18 @@ offloading execution. Apply partitioned execution optimizations. This is the

Re: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-05-20 Thread Alexander Monakov
On Thu, 21 Apr 2016, Nathan Sidwell wrote: > On 04/20/16 12:59, Alexander Monakov wrote: > > This patch implements per-warp compiler-defined stacks under -msoft-stack > > option, and implements alloca on top of that. In a few obvious places, > > changes from -muniform-simt patch are present in

Re: [PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-04-21 Thread Nathan Sidwell
On 04/20/16 12:59, Alexander Monakov wrote: This patch implements per-warp compiler-defined stacks under -msoft-stack option, and implements alloca on top of that. In a few obvious places, changes from -muniform-simt patch are present in the hunks. It'd be better to not mix fragments of

[PATCH] nvptx per-warp compiler-defined stacks (-msoft-stack)

2016-04-20 Thread Alexander Monakov
This patch implements per-warp compiler-defined stacks under -msoft-stack option, and implements alloca on top of that. In a few obvious places, changes from -muniform-simt patch are present in the hunks. Previously posted here: [PATCH] nvptx: implement automatic storage in custom stacks