In terms of LTO, the idea is for the link time: If there is -flto → we know that we should do LTO and, hence, need to check whether there is some. Without -flto, it might be that there is LTO and with slim LTO, we may have to handle it. For that reason, we have the following code in collect2.cc: #ifdef ENABLE_LTO static enum lto_mode_d lto_mode = LTO_MODE_WHOPR; #else static enum lto_mode_d lto_mode = LTO_MODE_NONE; #endif ... else if (startswith (argv[i], "-fno-lto")) lto_mode = LTO_MODE_NONE; ... if (use_plugin) lto_mode = LTO_MODE_NONE; if (no_partition && lto_mode == LTO_MODE_WHOPR) lto_mode = LTO_MODE_LTO; However, this has the unintended side effect that "-fno-lto" also disables handling the device side of offloading. * * * The question is how to handle this. Maybe something along the lines of the following: if (ENABLE_OFFLOADING && lto_mode == LTO_MODE_NONE && (-fopenmp || -fopenacc) && !-foffload=disable) lto_mode = LTO_MODE_WHOPR;
Well, we have to ensure that with -fno-lto linking, even if some or all compilation units were compiled with -flto we don't actually use the (non-offloading) LTO sections for the linking. All we want is if there are any offloading LTO sections to use them regardless of whether -flto was used or not (and let mkoffload decide whether to actually compile it and for which offloading targets).
The not-doing LTO sounds as if we want to handle this by passing some arg that gets processed in lto-plugin/lto-plugin.c's process_option possibly besides other places that need to be updated.