asb wrote:
I agree that finding a generic cross-target solution to this problem is
attractive...but I worry it will be hard and slow to proceed. It's possible the
previous discussions just lacked someone following up with concrete patches,
but I do worry we'd end up stuck in limbo vs starting
jrtc27 wrote:
My thoughts on this in the past have been:
1. target-abi should really be a target-independent thing we record; its
meaning depends on the target, but the ABI exists throughout LLVM as a concept
regardless of the target
2. module-level target features in general likely should be
topperc wrote:
> I'm surprised only 1 test file needed the metadata updated as a result of
> this change.
Maybe other tests are better about using regexes to hide the numbers?
https://github.com/llvm/llvm-project/pull/80760
___
cfe-commits mailing li
https://github.com/ilovepi approved this pull request.
Thank you for this. I expect this to be a big help w/ the various target
features bugs we've seen in LTO builds.
I'm surprised only 1 test file needed the metadata updated as a result of this
change.
https://github.com/llvm/llvm-project/p
llvmbot wrote:
@llvm/pr-subscribers-backend-risc-v
Author: Craig Topper (topperc)
Changes
In an LTO build, we don't set the ELF attributes to indicate what extensions
were compiled with. The target CPU/Attrs in RISCVTargetMachine do not get set
for an LTO build. Each function gets a targ
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-clang-codegen
Author: Craig Topper (topperc)
Changes
In an LTO build, we don't set the ELF attributes to indicate what extensions
were compiled with. The target CPU/Attrs in RISCVTargetMachine do not get set
for an LTO build.
https://github.com/topperc created
https://github.com/llvm/llvm-project/pull/80760
In an LTO build, we don't set the ELF attributes to indicate what extensions
were compiled with. The target CPU/Attrs in RISCVTargetMachine do not get set
for an LTO build. Each function gets a target-cpu/featur
