public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libgomp/97384] New: [libgomp, nvptx] Handle -msoft-stack-reserve-local=<n> overflow in plugin Date: Mon, 12 Oct 2020 14:29:30 +0000 [thread overview] Message-ID: <bug-97384-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97384 Bug ID: 97384 Summary: [libgomp, nvptx] Handle -msoft-stack-reserve-local=<n> overflow in plugin Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Using the option -msoft-stack-reserve-local=<n> results in a: ... .local .align 8 .b8 %simtstack_ar[n+8]; ... However, the CU_LIMIT_STACK_SIZE is set by default to 1kb for my card/driver combo, so if I specify say -msoft-stack-reserve-local=2048, I run into: ... libgomp: cuCtxSynchronize error: an illegal memory access was encountered ... or: ... libgomp: cuCtxSynchronize error: an illegal instruction was encountered ... [ The latter at GOMP_NVPTX_JIT=-O0. ] Which may look a lot like the behaviour we're trying to fix by adding -msoft-stack-reserve-local. There's currently no way to make this work. We could add an env var, say GOMP_NVPTX_LIMIT_STACK_SIZE which is used to set: ... r = cuCtxSetLimit(CU_LIMIT_STACK_SIZE, gomp_nvptx_limit_stack_size); ... and then do: ... $ GOMP_NVPTX_LIMIT_STACK_SIZE=3072 ./a.out ... [ Note that GOMP_NVPTX_LIMIT_STACK_SIZE id chosen to be larger than 2048 to accommodate for other .local usage. ] [ It would be nice if we could attempt to accommodate the requested stack size in the libgomp plugin automatically. In the current setup, that would mean scanning the ptx code for "simtstack_ar[<n>]", which is a bit cumbersome and probably too slow. Perhaps emitting an additional additional line before the pre-amble like this: ... // SIMTSTACK_AR_SIZE: 2048 ... would be possible to handle quick enough. ]
next reply other threads:[~2020-10-12 14:29 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-12 14:29 vries at gcc dot gnu.org [this message] 2024-06-06 11:48 ` [Bug libgomp/97384] " cvs-commit at gcc dot gnu.org
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=bug-97384-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /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: linkBe 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).