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 [2/n]


On Wed, Feb 4, 2015 at 11:55 AM, Jakub Jelinek <jakub@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


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