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

[Jakub Jelinek <jakub@redhat.com>]

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