On Wed, Feb 4, 2015 at 11:55 AM, Jakub Jelinek <ja...@redhat.com> 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 [1]), 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.
In principle I am always happy these days to preload less nodes. Thus, if your patch survives LTO bootstrap and you can still LTO a TU with ms_abi valist functions successfully (not sure if that's exercised in the testsuite) then it is fine. Note that I _did_ run into issues with excempting nodes from preloading because of pointer comparisons. The issue is that types created by the backends and the middle-end do not participate in the type merging done by LTO. Thus the actual issue may be not on x86 (because it implements the canonical_va_list_type hook) but on other targets that end up using std_canonical_va_list_type. Thanks, Richard. > Jakub
