This is the mail archive of the
mailing list for the GCC project.
Re: nvptx offloading patches [2/n]
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>, Richard Biener <rguenther at suse dot de>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 4 Feb 2015 11:58:57 +0100
- Subject: Re: nvptx offloading patches [2/n]
- Authentication-results: sourceware.org; auth=none
- References: <5454C944 dot 4090107 at codesourcery dot com> <20150204105554 dot GL1746 at tucnak dot redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Feb 04, 2015 at 11:55:54AM +0100, Jakub Jelinek wrote:
> On Sat, Nov 01, 2014 at 12:51:32PM +0100, Bernd Schmidt wrote:
> > LTO has a mechanism not to stream out common nodes that are expected to be
> > identical on each run. When using LTO to communicate between compilers for
> > different targets, the va_list_type_node and related ones must be excluded
> > from this.
> > Richard B mentioned in a recent mail that the i386 backend uses direct
> > comparisons to va_list_type_node. After investigating a bit it seems to me
> > that this is not actually a problem: what's being compared is the return
> > value of ix86_canonical_va_list_type, which always chooses one of
> > va_list_type_node or its ABI variants, so the comparison should hold even
> > with this patch.
> > Bootstrapped and tested on x86_64-linux, ok?
> How can the offloading of functions using va_start/va_end/va_arg work,
> until we apply (in GCC 6?) Michael's patches and extend them - make
> all those 3 internal functions lowered only after IPA?
> I mean, nvptx supposedly contains different va_list type (from quick glance
> it uses void *, while e.g. x86_64 uses a struct ), and we gimplify it
> early, so for GCC 5 the only option is IMHO to refuse to compile (sorry?)
> when streaming functions that use the host va_list type.
> For GCC 6, presumably if it is lowered late, if the host va_list would be
> at least as big as target va_list, we could stick stuff in there, or rewrite
> to the target va_list. Still, if e.g. va_list is embedded in structures, or
> used in global vars, we'd need to pad the structures or something.
That said, if your patch doesn't break normal LTO, I agree it doesn't make
much sense to