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
