Previously an empty CPU string was passed to the LTO engine which
resulted in a generic CPU for which certain features like NOPL
were disabled. This fixes that.
Details
- Reviewers
ruiu davide • espindola
Diff Detail
Event Timeline
You should add a testcase as Rafael pointed out. Overall it looks fine.
We used mllvm in lld to pass this kind of options to the backend but this seems justifiable.
BTW, if you're using lld or the gold plugin you might consider implementing the linker counterpart as well (if you have your proprietary linker, just ignore this last bit).
I added a test case. Since znver1 supports NOPW, it should be generated when we specify it as the CPU.
Thanks for the prompt review Davide and Rafael!
I don't think the mllvm option works as intended. The specified CPU(through mllvm) is definitely being used in the middle end for optimizations during LTO. However, it is not picked up when we initialize the target machine for the backend. This patch tries to fix that.
Also, I'm a bit confused by your last statement. What do you mean by implementing the linker counterpart as well? I think I'm missing the larger picture.
Addressed comments: clang-formatted the patch and removed the -m option from the test case.
I do not have commit access, could you please do it instead?
As of r322227 I would have though the target-cpu attribute would control the NOPL creation and override the CPU string.
test/ELF/lto/cpu-string.ll | ||
---|---|---|
10 | This CHECK line doesn't prove anything. nop would nopw. This should be a CHECK-NOT nopw. |
This CHECK line doesn't prove anything. nop would nopw. This should be a CHECK-NOT nopw.