[gomp-nvptx,3/5] nvptx backend: set up stacks in entry code

This patch implements the NVPTX backend part of the transition to
host-allocated soft stacks.  The compiler-emitted kernel entry code now
accepts a pointer to stack storage and per-warp stack size, and initialized
__nvptx_stacks based on that (as well as trivially initializing __nvptx_uni).

The rewritten part of write_omp_entry now uses macro-expanded assembly
snippets to avoid highly repetitive dynamic code accounting for 32/64-bit
differences.

	* config/nvptx/nvptx.c (write_omp_entry): Expand entry code to
	initialize __nvptx_uni and __nvptx_stacks (based on pointer to storage
	allocated by the libgomp plugin).

On 02/15/16 13:44, Alexander Monakov wrote:
> This patch implements the NVPTX backend part of the transition to

> +  static const char template64[] = ENTRY_TEMPLATE ("64", "8", "mad.wide.u32");
> +  static const char template32[] = ENTRY_TEMPLATE ("32", "4", "mad.lo.u32  ");
> +#undef ENTRY_TEMPLATE
> +  const char *template_1 = TARGET_ABI64 ? template64 : template32;
> +  const char *template_2 = template_1 + strlen (template64) + 1;
                                          ^^^
this looks mighty suspicious -- are you presuming some specific placement of 
template64 & template32? (and even then I  think it'll only work for TARGET_ABI64)

> +  s << ".visible .entry " << name << template_1 << orig << template_2;
> +  need_softstack_decl = need_unisimt_decl = true;

On Mon, 22 Feb 2016, Nathan Sidwell wrote:
> On 02/15/16 13:44, Alexander Monakov wrote:
> > This patch implements the NVPTX backend part of the transition to
> 
> > +  static const char template64[] = ENTRY_TEMPLATE ("64", "8",
> > "mad.wide.u32");
> > +  static const char template32[] = ENTRY_TEMPLATE ("32", "4", "mad.lo.u32
> > ");
> > +#undef ENTRY_TEMPLATE
> > +  const char *template_1 = TARGET_ABI64 ? template64 : template32;
> > +  const char *template_2 = template_1 + strlen (template64) + 1;
>                                          ^^^
> this looks mighty suspicious -- are you presuming some specific placement of
> template64 & template32? (and even then I  think it'll only work for
> TARGET_ABI64)

Template strings have an embedded nul character at the position where ORIG
goes, so template_2 is set to point at the position following the embedded nul
in template_1.  Offset of the embedded nul is the same in each template
string, so it doesn't matter which goes into the argument of strlen (but
supplying template64 or template32 instead of template_1 allows easier folding).

Alexander

On 02/22/16 15:25, Alexander Monakov wrote:

> Template strings have an embedded nul character at the position where ORIG
> goes, so template_2 is set to point at the position following the embedded nul
> in template_1.  Offset of the embedded nul is the same in each template
> string, so it doesn't matter which goes into the argument of strlen (but
> supplying template64 or template32 instead of template_1 allows easier folding).

ew, that's disgusting!

nathan

On Mon, 22 Feb 2016, Nathan Sidwell wrote:
> On 02/22/16 15:25, Alexander Monakov wrote:
> 
> > Template strings have an embedded nul character at the position where ORIG
> > goes, so template_2 is set to point at the position following the embedded
> > nul
> > in template_1.  Offset of the embedded nul is the same in each template
> > string, so it doesn't matter which goes into the argument of strlen (but
> > supplying template64 or template32 instead of template_1 allows easier
> > folding).
> 
> ew, that's disgusting!

So it'll blend in perfectly well with the rest of the ptx stuff in gcc, right?
Sorry, could not resist.

Please understand that I considered other approaches, and saw none that would
appear more beautiful/less ugly.  I'd be happy to add some comments to the
code, similar to my explanatory text above, if that's the problem.  If not,
and you actually imply that the code is not good (rather than delivering a
friendly jab) please give me some specific feedback to act on.

Thanks.
Alexander