Re: nvptx offloading patches [1/n]

[Jeff Law <law at redhat dot com>]

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