[llvm-dev] Getting differences with ldr/str instructions
I have fixed one issue in AArch64LoadStoreOptimizer.cpp file.
e.g: have two instructions like below
add x8, x9,x8, lsl #2
ldr w1, [x8]
and I have merged these two instructions into one instruction like below, and I am deleting add instruction if don’t have any uses.
ldr w1, [x9,x8, lsl #2]
But some llvm-test-sute tests are failing because getting difference in assembly code generation. I did bisecting with object files to find the issue.
In one failing test z12.c file, if I generate z12.o using z12.s of z12.c file it’s working.
but if I generate direct z12.o using z12.c file and it’s not working.
so I did disassemble the both z12.o files and I have observed below differences in one ldr instruction(above merged ldr instruction).
F38: b869eb61 ldr w1, [x9, x8,
sxtx] ( disassemble code of z12.o generated using z12.c).
F38: b8697b61 ldr w1, [x9, x8,
lsl #2] ( disassemble code of z12.o generated using z12.s).
I am getting above two differences, because of these differences test is failing.
Could any one please give your suggestions to fix this problem.
Thanks & Regards,
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
LLVM Developers mailing list
[hidden email] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Re: [llvm-dev] Getting differences with ldr/str instructions
On Thu, 16 May 2019 at 11:04, Ramakota Reddy via llvm-dev
<[hidden email]> wrote:
> Could any one please give your suggestions to fix this problem.
This can happen if the operands on the MachineInstr you create are
incorrect. The code to print instructions and to encode instructions
can treat the operands in slightly different ways so that with invalid
input you can get a MachineInstr that prints properly, but assembles
In this case it looks like what you're describing might happen if the
SignExtend operand was 0 and the DoShift operand was 14 (instead of a
boolean 0 or 1). I have no idea how that situation could arise without
seeing your code though.
So you should probably double check wherever you create these load
instructions to make sure you're encoding the value properly (being
aware that the encoding might differ between the ADD and the LDR).