This patch returns the same label if the CP entry with the same value has been created.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Hi,
Please post with full context.
Please add tests that ensure the behaviour is correct when there are multiple references to a constant and one of them is out of range (the constant should be duplicated in this case).
James
Forgot to include the full context in previous diff.
Regarding the out-of-range test, give a test like:
foo1:
PUSH {r4-r6,lr}
LDR r7, =0x80808080
.space 0x1000
LDR r7, =0x80808080
Existing llvm-mc gives "error: out of range pc-relative fixup value". Similarly, gnu-as gives "Error: invalid literal constant: pool needs to be closer"
Is our case, if the first LDR is valid (within the range), then following LDR to the same constant should be valid as well since we always put CP at the end.
I think this makes sense.
The side effects of the caching are of *removing* constants, not adding them, so if anything, the range of the original load should be shorter, not longer. The number of instructions are also the same, so overall, this should never increase the code/data in any way.
Also, whatever relocation didn't work before (negative, wrong range, wrong relocation), will keep not working, but that's nothing to do with the patch itself.
cheers,
--renato
lib/MC/ConstantPools.cpp | ||
---|---|---|
40–41 ↗ | (On Diff #75318) | You could save a lookup by using find/end instead of count/operator[] |
This commit causes https://bugs.llvm.org//show_bug.cgi?id=32825
The above example is invalid, you must use .ltorg to ensure literal pool accessibility.
The corrected(valid) code can be compiled by gnu-as, but not by llvm-mc
foo1: PUSH {r4-r6,lr} LDR r7, =0x80808080 .ltorg .space 0x1000 LDR r7, =0x80808080 .ltorg
Can you, please, fix or revert it? It's a clear regression as the example can be compiled using llvm 3.9 but not by llvm 4.0+..
Thanks.
PR32825 seems valid and has been open for some time. Weiming, I have reverted this in r303535.
Cheers,
James
Re-writing here because phab didn't pick up my email reply.
I have double checked the PR, and yes, it is fixed on ToT. From my perspective what I saw is a commit that I'd LGTM'd with an open PR and no response from the author, which is why I backed it out.
I've recommitted the two backed out diffs and updated PR32825 as resolved.
James
Can you, please, fix or revert it? It's a clear regression as the example can be compiled using llvm 3.9 but not by llvm 4.0+..
WRT to this being a regression in llvm 4.0 - it might be a little late to try to get the fix merged into 4.0.1. Although, the window for opening such a merge request closes today, so if you feel it's urgent, perhaps such a merge request should be opened?
I opened a merge request for this fix in https://bugs.llvm.org/show_bug.cgi?id=33122 in any case.