================ @@ -16,7 +16,7 @@ // RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s -flto=thin -c -o %t.call_thin.bc -DCALL_LIB // RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s -flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB -// RUN: llvm-lto2 run -o %t.lto_thin -save-temps %t.call_thin.bc %t.define_thin.bc \ +// RUN: llvm-lto2 run --mcpu=cortex-m33 --float-abi=hard -o %t.lto_thin -save-temps %t.call_thin.bc %t.define_thin.bc \ ---------------- smithp35 wrote:
Thanks for the investigation. I think that this use case of LTO needs to work without an error as while we can provide the target for this specific test case, it may cause other uses of LTO without a target on the linker driver to fail. This may mean that we have to fix this in LTO. >From git annotate the test case was added in https://reviews.llvm.org/D89573 >ostensibly to make sure that if LTO calls a C function it uses the correct ABI. Looking at llvm.lifetime.start this is a lifetime marker intrinsic https://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic . IIUC lifetime markers are for communicating lifetimes of objects to optimisers, so while they influence code-generation they don't get code generated for them. It may be an area where the subtarget for the function isn't being passed through correctly, although in the case of lifetime markers it is benign. This is an area that needs a lot more in depth expertise of LLVM and LTO than I posess. I can ask around internally to see if anyone is willing to take a look. https://github.com/llvm/llvm-project/pull/111334 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
