nvptx offloading patches [3/n], RFD

This is not against current trunk; it applies to gomp-4_0-branch where 
it is one of the necessary parts to make offloading x86->nvptx work. The 
issue is that the LTO file format depends on the machine_modes enum, it 
needs to match between host and offload target. The easiest way to do 
this is to just use the host-modes.def when compiling an offload compiler.

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)?


Bernd

On 11/01/14 05:57, Bernd Schmidt wrote:
> This is not against current trunk; it applies to gomp-4_0-branch where
> it is one of the necessary parts to make offloading x86->nvptx work. The
> issue is that the LTO file format depends on the machine_modes enum, it
> needs to match between host and offload target. The easiest way to do
> this is to just use the host-modes.def when compiling an offload compiler.
>
> 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.

Not sure how to deal with this any further out than the immediate term 
than using a hack like this. Though I'd prefer to avoid the #ifdef as it 
seems to me this shouldn't be baked in at build/configure time.

jeff

On Sat, Nov 01, 2014 at 12:57:45PM +0100, Bernd Schmidt wrote:
> This is not against current trunk; it applies to gomp-4_0-branch where it is
> one of the necessary parts to make offloading x86->nvptx work. The issue is
> that the LTO file format depends on the machine_modes enum, it needs to
> match between host and offload target. The easiest way to do this is to just
> use the host-modes.def when compiling an offload compiler.
> 
> 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)?

I don't like this at all.

IMHO instead we should stream in the offloading LTO sections some kind of mode
description table (perhaps limited to the modes actually ever streamed),
and when reading back the offloading LTO sections, let the offloading
compiler remap the modes to its own modes where there is a mapping in
between the two, choose some other mapping (e.g. map various vector modes
the host has but offloading target does not to say BLKmode), or give up
otherwise with offloading (say if you attempt to stream floating point modes
the offloading target doesn't support etc.).

So perhaps stream for each used mode the mode value, corresponding mode
class, size, precision, inner mode, nunits, and for floating point modes
supposedly somehow encode the real_format (perhaps just add a name <->
struct real_format mapping for the real.c modes, and map anything else
to "unknown").

	Jakub

On Wed, Feb 4, 2015 at 12:38 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Sat, Nov 01, 2014 at 12:57:45PM +0100, Bernd Schmidt wrote:
>> This is not against current trunk; it applies to gomp-4_0-branch where it is
>> one of the necessary parts to make offloading x86->nvptx work. The issue is
>> that the LTO file format depends on the machine_modes enum, it needs to
>> match between host and offload target. The easiest way to do this is to just
>> use the host-modes.def when compiling an offload compiler.
>>
>> 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)?
>
> I don't like this at all.
>
> IMHO instead we should stream in the offloading LTO sections some kind of mode
> description table (perhaps limited to the modes actually ever streamed),
> and when reading back the offloading LTO sections, let the offloading
> compiler remap the modes to its own modes where there is a mapping in
> between the two, choose some other mapping (e.g. map various vector modes
> the host has but offloading target does not to say BLKmode), or give up
> otherwise with offloading (say if you attempt to stream floating point modes
> the offloading target doesn't support etc.).
>
> So perhaps stream for each used mode the mode value, corresponding mode
> class, size, precision, inner mode, nunits, and for floating point modes
> supposedly somehow encode the real_format (perhaps just add a name <->
> struct real_format mapping for the real.c modes, and map anything else
> to "unknown").

I think (also communicated that on IRC) we should instead try not streaming
machine-modes at all but generating them at stream-in time via layout_type
or layout_decl.

Richard.

>         Jakub