================ @@ -0,0 +1,68 @@ +; RUN: llvm-as %s -o %t1.bc +; RUN: llvm-as %p/Inputs/global-inline-asm-flags.ll -o %t2.bc +; RUN: llvm-lto -save-merged-module -filetype=asm -mattr=+pauth %t1.bc %t2.bc -o %t3 ---------------- ilovepi wrote:
> > I think the for LTO we need some cases where there's more than one module. > > `LTO/AArch64/global-inline-asm-flags.ll` is supposed to be such a test. I > don't fully know about all the different LTO modes that we have, so maybe I'm > missing something. > There's really just Full LTO (e.g. monolitic LTO) and Thin LTO. we have FatLTO (e.g. `-ffat-lto-objects`, but that's just a fat object format and is compatible w/ Thin and Full LTO). My concern here is with 1) how the merging happens, and 2) what is intended to happen when one module has target features or other flags that conflict. I beleive RISC-V has at least a few. @mshockwave may be able to point you to some. > > Additionally we should also have a test w/ llvm-lto2, as well as at least > > one case where the flags conflict somehow. > > Yes, I think we need a test for "duplicated" symbols (declarations?). I'm > going to add it tomorrow. IDK if there's much point in testing duplicated symbols, unless you're worried about interactions w/ linker GC. In those cases, though it would just follow the linker's existing rules/logic, which is why I'm surprised you want to test it, unless I'm overlooking something. https://github.com/llvm/llvm-project/pull/174995 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
