On Thu, Dec 03, 2020 at 02:32:13PM -0800, Nick Desaulniers wrote: > On Thu, Dec 3, 2020 at 10:23 AM Will Deacon <will@xxxxxxxxxx> wrote: > > On Thu, Dec 03, 2020 at 09:07:30AM -0800, Sami Tolvanen wrote: > > > Without LLVM_IAS=1, Clang uses two different assemblers when LTO is > > > enabled: the external GNU assembler for stand-alone assembly, and > > > LLVM's integrated assembler for inline assembly. as-instr tests the > > > external assembler and makes an admittedly reasonable assumption that > > > the test is also valid for inline assembly. > > > > > > I agree that it would reduce confusion in future if we just always > > > enabled IAS with LTO. Nick, Nathan, any thoughts about this? > > > > That works for me, although I'm happy with anything which means that the > > assembler checks via as-instr apply to the assembler which will ultimately > > be used. > > I agree with Will. [...] > So I'd recommend to Sami to simply make the Kconfig also depend on > clang's integrated assembler (not just llvm-nm and llvm-ar). If > someone cares about LTO with Clang as the compiler but GAS as the > assembler, then we can revisit supporting that combination (and the > changes to KCONFIG), but it shouldn't be something we consider Tier 1 > supported or a combination that need be supported in a minimum viable > product. And at that point we should make it avoid clang's integrated > assembler entirely (I suspect LTO won't work at all in that case, so > maybe even considering it is a waste of time). > > One question I have to Will; if for aarch64 LTO will depend on RCpc, > but RCpc is an ARMv8.3 extension, what are the implications for LTO on > pre-ARMv8.3 aarch64 processors? It doesn't depend on RCpc -- we just emit a more expensive instruction (an RCsc acquire) if the RCpc one is not supported by both the toolchain and the CPU. So the implication for those processors is that READ_ONCE() may be more expensive. Will
