nvptx offloading patches [1/n]

nvptx offloading patches [1/n]

[Bernd Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

This is one of the patches required to make offloading via the LTO path 
work when the machines involved differ.

x86 requires bigger alignments for some types than nvptx does, which 
becomes an issue when reading LTO produced by the host compiler. The 
problem with having a variable with DECL_ALIGN larger than the stack 
alignment is that gcc will try to align the variable dynamically with an 
alloca/rounding operation, and there isn't a working alloca on nvptx. 
Besides, the overhead would be pointless.

The patch below restricts the alignments to the maximum possible when 
reading in LTO data in an offload compiler. Unfortunately 
BIGGEST_ALIGNMENT isn't suitable for this, as it can vary at runtime 
with attribute((target)), and because vector modes can exceed it, so a 
limit based on BIGGEST_ALIGNMENT would be unsuitable for some ports. 
Instead I've added a hook called limit_offload_alignment which is called 
when reading LTO on an offload compiler. It does nothing anywhere except 
on ptx where it limits alignments to 64 bit.

Bootstrapped and tested on x86_64-linux. Ok?


Bernd


[-- Attachment #2: align.diff --]
[-- Type: text/x-patch, Size: 4545 bytes --]

	* tree-streamer-in.c (unpack_ts_decl_common_value_fields,
	unpack_ts_type_common_value_fields): If ACCEL_COMPILER,
	restrict alignments to absolute_biggest_alignment.
	* config/i386/i386.c (TARGET_ABSOLUTE_BIGGEST_ALIGNMENT):
	Define.
	* doc/tm.texi.in (TARGET_ABSOLUTE_BIGGEST_ALIGNMENT): Add.
	* doc/tm.texi: Regenerate.
	* target.def (absolute_biggest_alignment): New DEFHOOKPOD.

Index: gcc/tree-streamer-in.c
===================================================================
--- gcc/tree-streamer-in.c.orig
+++ gcc/tree-streamer-in.c
@@ -217,7 +217,10 @@ unpack_ts_decl_common_value_fields (stru
   DECL_EXTERNAL (expr) = (unsigned) bp_unpack_value (bp, 1);
   DECL_GIMPLE_REG_P (expr) = (unsigned) bp_unpack_value (bp, 1);
   DECL_ALIGN (expr) = (unsigned) bp_unpack_var_len_unsigned (bp);
-
+#ifdef ACCEL_COMPILER
+  if (DECL_ALIGN (expr) > targetm.absolute_biggest_alignment)
+    DECL_ALIGN (expr) = targetm.absolute_biggest_alignment;
+#endif
   if (TREE_CODE (expr) == LABEL_DECL)
     {
       EH_LANDING_PAD_NR (expr) = (int) bp_unpack_var_len_unsigned (bp);
@@ -359,6 +362,10 @@ unpack_ts_type_common_value_fields (stru
   TYPE_READONLY (expr) = (unsigned) bp_unpack_value (bp, 1);
   TYPE_PRECISION (expr) = bp_unpack_var_len_unsigned (bp);
   TYPE_ALIGN (expr) = bp_unpack_var_len_unsigned (bp);
+#ifdef ACCEL_COMPILER
+  if (TYPE_ALIGN (expr) > targetm.absolute_biggest_alignment)
+    TYPE_ALIGN (expr) = targetm.absolute_biggest_alignment;
+#endif
   TYPE_ALIAS_SET (expr) = bp_unpack_var_len_int (bp);
 }
 
Index: gcc/config/i386/i386.c
===================================================================
--- gcc/config/i386/i386.c.orig
+++ gcc/config/i386/i386.c
@@ -47623,6 +47623,9 @@ ix86_atomic_assign_expand_fenv (tree *ho
 #undef TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
 #define TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS true
 
+#undef TARGET_ABSOLUTE_BIGGEST_ALIGNMENT
+#define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 512
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 \f
 #include "gt-i386.h"
Index: gcc/config/i386/i386.h
===================================================================
--- gcc/config/i386/i386.h.orig
+++ gcc/config/i386/i386.h
@@ -784,7 +784,10 @@ extern const char *host_detect_local_cpu
    rounder than this.
 
    Pentium+ prefers DFmode values to be aligned to 64 bit boundary
-   and Pentium Pro XFmode values at 128 bit boundaries.  */
+   and Pentium Pro XFmode values at 128 bit boundaries.
+
+   When increasing the maximum, also update
+   TARGET_ABSOLUTE_BIGGEST_ALIGNMENT.  */
 
 #define BIGGEST_ALIGNMENT \
   (TARGET_AVX512F ? 512 : (TARGET_AVX ? 256 : 128))
Index: gcc/doc/tm.texi
===================================================================
--- gcc/doc/tm.texi.orig
+++ gcc/doc/tm.texi
@@ -1003,6 +1003,12 @@ bits.  Note that this is not the biggest
 just the biggest alignment that, when violated, may cause a fault.
 @end defmac
 
+@deftypevr {Target Hook} HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT
+If defined, this target hook specifies the absolute biggest alignment
+that a type or variable can have on this machine, otherwise,
+@code{BIGGEST_ALIGNMENT} is used.
+@end deftypevr
+
 @defmac MALLOC_ABI_ALIGNMENT
 Alignment, in bits, a C conformant malloc implementation has to
 provide.  If not defined, the default value is @code{BITS_PER_WORD}.
Index: gcc/doc/tm.texi.in
===================================================================
--- gcc/doc/tm.texi.in.orig
+++ gcc/doc/tm.texi.in
@@ -957,6 +957,8 @@ bits.  Note that this is not the biggest
 just the biggest alignment that, when violated, may cause a fault.
 @end defmac
 
+@hook TARGET_ABSOLUTE_BIGGEST_ALIGNMENT
+
 @defmac MALLOC_ABI_ALIGNMENT
 Alignment, in bits, a C conformant malloc implementation has to
 provide.  If not defined, the default value is @code{BITS_PER_WORD}.
Index: gcc/target.def
===================================================================
--- gcc/target.def.orig
+++ gcc/target.def
@@ -1760,6 +1760,13 @@ HOOK_VECTOR_END (vectorize)
 #undef HOOK_PREFIX
 #define HOOK_PREFIX "TARGET_"
 
+DEFHOOKPOD
+(absolute_biggest_alignment,
+ "If defined, this target hook specifies the absolute biggest alignment\n\
+that a type or variable can have on this machine, otherwise,\n\
+@code{BIGGEST_ALIGNMENT} is used.",
+ HOST_WIDE_INT, BIGGEST_ALIGNMENT)
+
 /* Allow target specific overriding of option settings after options have
   been changed by an attribute or pragma or when it is reset at the
   end of the code affected by an attribute or pragma.  */

Re: nvptx offloading patches [1/n]

[Jeff Law]

On 11/01/14 05:47, Bernd Schmidt wrote:
> This is one of the patches required to make offloading via the LTO path
> work when the machines involved differ.
>
> x86 requires bigger alignments for some types than nvptx does, which
> becomes an issue when reading LTO produced by the host compiler. The
> problem with having a variable with DECL_ALIGN larger than the stack
> alignment is that gcc will try to align the variable dynamically with an
> alloca/rounding operation, and there isn't a working alloca on nvptx.
> Besides, the overhead would be pointless.
>
> The patch below restricts the alignments to the maximum possible when
> reading in LTO data in an offload compiler. Unfortunately
> BIGGEST_ALIGNMENT isn't suitable for this, as it can vary at runtime
> with attribute((target)), and because vector modes can exceed it, so a
> limit based on BIGGEST_ALIGNMENT would be unsuitable for some ports.
> Instead I've added a hook called limit_offload_alignment which is called
> when reading LTO on an offload compiler. It does nothing anywhere except
> on ptx where it limits alignments to 64 bit.
>
> Bootstrapped and tested on x86_64-linux. Ok?
Not ideal.

Doesn't this affect our ability to pass data back and forth between the 
host and GPU?  Or is this strictly a problem with stack objects and thus 
lives entirely on the GPU?

jeff

Re: nvptx offloading patches [1/n]

[Bernd Schmidt]

On 11/03/2014 11:22 PM, Jeff Law wrote:
> On 11/01/14 05:47, Bernd Schmidt wrote:
>> This is one of the patches required to make offloading via the LTO path
>> work when the machines involved differ.
>>
>> x86 requires bigger alignments for some types than nvptx does, which
>> becomes an issue when reading LTO produced by the host compiler. The
>> problem with having a variable with DECL_ALIGN larger than the stack
>> alignment is that gcc will try to align the variable dynamically with an
>> alloca/rounding operation, and there isn't a working alloca on nvptx.
>> Besides, the overhead would be pointless.
>>
>> The patch below restricts the alignments to the maximum possible when
>> reading in LTO data in an offload compiler. Unfortunately
>> BIGGEST_ALIGNMENT isn't suitable for this, as it can vary at runtime
>> with attribute((target)), and because vector modes can exceed it, so a
>> limit based on BIGGEST_ALIGNMENT would be unsuitable for some ports.
>> Instead I've added a hook called limit_offload_alignment which is called
>> when reading LTO on an offload compiler. It does nothing anywhere except
>> on ptx where it limits alignments to 64 bit.
>>
>> Bootstrapped and tested on x86_64-linux. Ok?
> Not ideal.
>
> Doesn't this affect our ability to pass data back and forth between the
> host and GPU?  Or is this strictly a problem with stack objects and thus
> lives entirely on the GPU?

Communication between host and GPU is all done via some form of memcpy, 
so I wouldn't expect this to be a problem. Structure layouts and such 
are decided by the host compiler and since that uses higher alignments, 
they should work fine on the GPU. I believe the only thing this really 
does is relax the requirements when allocating storage on the GPU side.


Bernd

Re: nvptx offloading patches [1/n]

[Jeff Law]

On 11/03/14 16:07, Bernd Schmidt wrote:
> On 11/03/2014 11:22 PM, Jeff Law wrote:
>> On 11/01/14 05:47, Bernd Schmidt wrote:
>>> This is one of the patches required to make offloading via the LTO path
>>> work when the machines involved differ.
>>>
>>> x86 requires bigger alignments for some types than nvptx does, which
>>> becomes an issue when reading LTO produced by the host compiler. The
>>> problem with having a variable with DECL_ALIGN larger than the stack
>>> alignment is that gcc will try to align the variable dynamically with an
>>> alloca/rounding operation, and there isn't a working alloca on nvptx.
>>> Besides, the overhead would be pointless.
>>>
>>> The patch below restricts the alignments to the maximum possible when
>>> reading in LTO data in an offload compiler. Unfortunately
>>> BIGGEST_ALIGNMENT isn't suitable for this, as it can vary at runtime
>>> with attribute((target)), and because vector modes can exceed it, so a
>>> limit based on BIGGEST_ALIGNMENT would be unsuitable for some ports.
>>> Instead I've added a hook called limit_offload_alignment which is called
>>> when reading LTO on an offload compiler. It does nothing anywhere except
>>> on ptx where it limits alignments to 64 bit.
>>>
>>> Bootstrapped and tested on x86_64-linux. Ok?
>> Not ideal.
>>
>> Doesn't this affect our ability to pass data back and forth between the
>> host and GPU?  Or is this strictly a problem with stack objects and thus
>> lives entirely on the GPU?
>
> Communication between host and GPU is all done via some form of memcpy,
> so I wouldn't expect this to be a problem.
They still need to agree on the layout of the structure.  And assuming 
it'll always be memcpy perhaps isn't wise.  Consider the possibility 
that one day (perhaps soon) the host and GPU may share address space & 
memory.

> Structure layouts and such
> are decided by the host compiler and since that uses higher alignments,
> they should work fine on the GPU. I believe the only thing this really
> does is relax the requirements when allocating storage on the GPU side.
But if the structure has a higher alignment on the host and that 
structure is embedded in another structure or array, then that higher 
alignment affects the composite object's layout.

But again, if this just affects stack objects, then it shouldn't be a 
problem.

Jeff

Re: nvptx offloading patches [1/n]

[Bernd Schmidt]

On 11/04/2014 10:01 PM, Jeff Law wrote:
>> Communication between host and GPU is all done via some form of memcpy,
>> so I wouldn't expect this to be a problem.
> They still need to agree on the layout of the structure.

That is guaranteed by the fact that structure layouts are fixed before 
we write out LTO.

>  And assuming
> it'll always be memcpy perhaps isn't wise.  Consider the possibility
> that one day (perhaps soon) the host and GPU may share address space &
> memory.

Well, in that case such a target presumably wouldn't use this hook, or 
the hook would be extended so that DECLs that live in the host address 
space retain their alignment. But that's not the problem we're solving 
today.

> But again, if this just affects stack objects, then it shouldn't be a
> problem.

It also affects global variables in GPU memory, but for nvptx this isn't 
a problem either.


Bernd

Re: nvptx offloading patches [1/n]

[Jeff Law]

On 11/04/14 14:08, Bernd Schmidt wrote:
> On 11/04/2014 10:01 PM, Jeff Law wrote:
>>> Communication between host and GPU is all done via some form of memcpy,
>>> so I wouldn't expect this to be a problem.
>> They still need to agree on the layout of the structure.
>
> That is guaranteed by the fact that structure layouts are fixed before
> we write out LTO.
Ok.  This is the key item.  Thanks for walking me through it.

>
>>  And assuming
>> it'll always be memcpy perhaps isn't wise.  Consider the possibility
>> that one day (perhaps soon) the host and GPU may share address space &
>> memory.
>
> Well, in that case such a target presumably wouldn't use this hook, or
> the hook would be extended so that DECLs that live in the host address
> space retain their alignment. But that's not the problem we're solving
> today.
We're pretty close to this capability right now, so we may have to 
change this fairly soon ;-)

Jeff

Re: nvptx offloading patches [1/n]

[Michael Matz]

Hi,

On Tue, 4 Nov 2014, Jeff Law wrote:

> They still need to agree on the layout of the structure.  And assuming 
> it'll always be memcpy perhaps isn't wise.  Consider the possibility 
> that one day (perhaps soon) the host and GPU may share address space & 
> memory.

Not only soon, there is already hardware out that does exactly that.  
HSA.


Ciao,
Michael.

Re: nvptx offloading patches [1/n]

[Bernd Schmidt]

On 11/05/2014 12:17 AM, Jeff Law wrote:
> On 11/04/14 14:08, Bernd Schmidt wrote:
>> On 11/04/2014 10:01 PM, Jeff Law wrote:
>>>> Communication between host and GPU is all done via some form of memcpy,
>>>> so I wouldn't expect this to be a problem.
>>> They still need to agree on the layout of the structure.
>>
>> That is guaranteed by the fact that structure layouts are fixed before
>> we write out LTO.
> Ok.  This is the key item.  Thanks for walking me through it.

Is this patch ok?


Bernd

Re: nvptx offloading patches [1/n]

[Jeff Law]

On 11/14/14 11:25, Bernd Schmidt wrote:
> On 11/05/2014 12:17 AM, Jeff Law wrote:
>> On 11/04/14 14:08, Bernd Schmidt wrote:
>>> On 11/04/2014 10:01 PM, Jeff Law wrote:
>>>>> Communication between host and GPU is all done via some form of
>>>>> memcpy,
>>>>> so I wouldn't expect this to be a problem.
>>>> They still need to agree on the layout of the structure.
>>>
>>> That is guaranteed by the fact that structure layouts are fixed before
>>> we write out LTO.
>> Ok.  This is the key item.  Thanks for walking me through it.
>
> Is this patch ok?
Yes.  Sorry I wasn't clear about that.
jeff