This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp4 11/14] libgomp: avoid variable-length stack allocation in team.c
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Bernd Schmidt <bschmidt at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>, Dmitry Melnik <dm at ispras dot ru>
- Date: Wed, 21 Oct 2015 00:36:45 +0300 (MSK)
- Subject: Re: [gomp4 11/14] libgomp: avoid variable-length stack allocation in team.c
- Authentication-results: sourceware.org; auth=none
- References: <1445366076-16082-1-git-send-email-amonakov at ispras dot ru> <1445366076-16082-12-git-send-email-amonakov at ispras dot ru> <5626A801 dot 3040101 at redhat dot com>
On Tue, 20 Oct 2015, Bernd Schmidt wrote:
> On 10/20/2015 08:34 PM, Alexander Monakov wrote:
> > NVPTX does not support alloca or variable-length stack allocations, thus
> > heap allocation needs to be used instead. I've opted to make this a generic
> > change instead of guarding it with an #ifdef: libgomp usually leaves thread
> > stack size up to libc, so avoiding unbounded stack allocation makes sense.
> >
> > * task.c (GOMP_task): Use a fixed-size on-stack buffer or a heap
> > allocation instead of a variable-size on-stack allocation.
>
> > + char buf_fixed[2048], *buf = buf_fixed;
>
> This might also not be the best of ideas on a GPU - the stack size isn't all
> that unlimited, what with there being lots of threads. If I do
>
> size_t stack, heap;
> cuCtxGetLimit (&stack, CU_LIMIT_STACK_SIZE);
>
> in the nvptx-run program we've used for testing, it shows a default stack size
> of just 1kB.
Thanks, NVPTX will need a low buf_fixed size, perhaps 64 bytes or so.
What about the generic case, should it use a more generous threshold,
or revert to existing unbounded alloca?
Any ideas how big is the required allocation size is in practice?
Thanks.
Alexander