This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]