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

[Jeff Law]

On 11/04/14 05:35, Bernd Schmidt wrote:
>>> Ports that want to be hosts for offloading may need to modify their
>>> modes.def. The patch below contains changes to i386-modes.def which
>>> modifies XFmode depending on a target switch. I'm not actually entirely
>>> sure what to do about this. Do we want to make this flag an error when
>>> offloading is enabled? Or maybe add float format support to the
>>> -foffload-abi option?
>>>
>>> Thoughts? Ok for the first part of the patch once the other offloading
>>> patches have gone in (bootstrapped and tested on x86_64-linux)?
>> It feels like we've got another real distinction to make.  We've had
>> host, build & target and they're all independent.  It feels like we need
>> offload target and better separate between target and offload target.
>> Then we need to figure out the places where we've got bleed-out.
>
> Is this a question of terminology? I agree that saying "offload host"
> when we'd normally be calling it the "target" is confusing, but it's
> difficult to come up with better names.
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.

Jeff