Re: nvptx offloading patches [3/n], i386 bits RFD

[Bernd Schmidt <bernds at codesourcery dot com>]

On 11/04/2014 10:50 PM, Jeff Law wrote:
> No, I don't think it's terminology.  It's really that in effect we have
> two targets.  One is a normal CPU, the other is a GPU.
>
> ie, there's nothing that says we won't have a GPU that's being driven by
> an ARM or PPC.  What I want to avoid is GPU-isms getting sprinkled into
> the x86 (or any other) backend.
>
> The problem is we don't have any infrastructure in place for this kind
> of situation.  So we start off with a few hacks and hopefully we're able
> to see some commonality and start to see how to handle the
> multi-architecture target issues a bit better.

FWIW the three non-ptx patches I sent plus the -foffload-abi stuff are 
the only ones necessary to make offloading through the LTO path work 
(this was against the gomp-4_0-branch with earlier versions of the 
offload patches Ilya's been posting; I haven't had a chance to test 
everything together in trunk yet). That doesn't seem like a large amount 
of changes.

For other targets I don't expect the situation to be too different. ARM 
has a similar float mode issue for HFmode, and things like 
m{big,little}-endian may have to be handled. I expect these can be 
handled with -foffload-abi machinery.

So, looking ahead - I'm imagining extra switches along the lines of
 -foffload-abi-hflt={arm,ieee,...}
 -foffload-abi-ldbl={64,x86,128}
 -foffload-abi-endian={big,little}

On some targets it might make sense to disallow offloading if certain 
switches are used. Uros seems to agree that on x86 the -mlong-double-128 
switch isn't very interesting. I'm thinking about how to deal with such 
a situation - maybe an offload_abi_valid hook that gets called whenever 
we find that we want to stream out offloaded functions. That would then 
sorry out (or maybe just warn) if the hook returns false.

I can do either or both, whatever the consensus turns out to be.


Bernd