On Tue, Oct 14, 2014 at 1:49 PM, Bernd Schmidt <ber...@codesourcery.com> wrote: > On 10/14/2014 09:25 AM, Richard Biener wrote: >> >> On Mon, 13 Oct 2014, Bernd Schmidt wrote: >> >>> On 10/13/2014 12:33 PM, Ilya Verbin wrote: >>>> >>>> On 13 Oct 12:19, Jakub Jelinek wrote: >>>>> >>>>> But I'd like to understand why is this one needed. >>>>> Why should the compilers care? Aggregates layout and alignment of >>>>> integral/floating types must match between host and offload compilers, >>>>> sure, >>>>> but isn't that something streamed already in the LTO bytecode? >>>>> Or is LTO streamer not streaming some types like long_type_node? >>> >>> >>> It isn't, see the preload_common_nodes code. >> >> >> Something I'd like to get rid of at some point (but it's not 100% >> easy as backends for example compare va_list_type_node by pointer). > > > Hmm, this is unfortunate - I was about to submit a patch not to stream that > one since it can differ between host and offload target. > > I see one such comparison in i386.c - any others you are aware of?
No, x86 is the only target I ever tested. > Should it > be sufficient to just compare the TYPE_MAIN_VARIANT instead? Well, they will not even be variants of each other. ISTR complications especially on x86 because of the alternate ms_abi va_list. I'd say that we eventually should have a type flag that says "this is a va-list type". If we really need to know that - because I don't understand why we need to do this - the context should tell us exactly whether we deal with a va_list object or not ... Richard. >>> Also, the backend needs to choose >>> the right Pmode (and in the case of ptx, emit a directive about address >>> sizes). >> >> >> Surely that will only be one problem with going the LTO way to handle >> the offloading ;) > > > Another problem I mentioned above, beyond that I have a patch to use the > $host-modes.def file to define machine modes - and that's essentially it. > > I'll be submitting these additional offloading patches for the case of > different host and target once Ilya has committed the others. > > > Bernd >
