Offloading vs va_list (was: nvptx offloading patches [2/n])

[Thomas Schwinge <thomas_schwinge at mentor dot com>]

Hi!

On Thu, 19 Feb 2015 14:09:29 +0100, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Feb 17, 2015 at 09:55:32PM +0100, Bernd Schmidt wrote:
> > On 02/17/2015 06:10 PM, Jakub Jelinek wrote:
> > >
> > >What exact testcase are you trying to fix with this patch, and how do you
> > >think offloading of code using va_list can work?
> > 
> > The exact testcase is any offloaded program - streaming in lto will crash if
> > there is a mismatch in these preloaded nodes.

> could following untested patch be used as a temporary hack?

Thanks!  I'll leave the approval to Bernd, but can already report that
this works fine in my testing, for intelmic and nvptx offloading.

> It might pessimize for GCC5 slightly the intelmic offloading, but I hope
> the way forward is the stdarg late lowering for GCC 6.

> Richard on IRC said it might be better for the lto_stream_offload_p
> path to whitelist nodes it has to preload rather than blacklist the ones
> that it doesn't, otherwise e.g. if you try to offload from say x86_64-mingw
> with 32-bit long, but 64-bit pointers to 64-bit intelmic

That's a good consideration (for the future), but we're not currently
supporting the case of offloading with non-matching ABIs (data types).

> preloading
> the long_type_node will certainly break lots of things, while not preloading
> them would only be problematic for builtins, we'll need some pass over the
> builtins in the IL in any case, to find out if they are compatible or not,
> adjust if needed and give up otherwise.  But I'd hope it can be worked on
> incrementally, if this patch (plus the approved nvptx offloading patches,
> plus mode_table streaming) makes the nvptx offloading work.


GrÃÃe,
 Thomas

Attachment: pgpEUvgs9N4f3.pgp
Description: PGP signature