Closed martin-fink closed 2 years ago
I've just noticed that branch instructions are not yet raised when promotePhysregToStackSlot
is called, which means DominatorTree.dominates
only works as expected when the two instructions passed to it are in the same basic block.
I've changed the to use MachineDominatorTree
, which is not as elegant as using DominatorTree
would be. I have to look up the MBB for each instruction I'm checking, which results in some overhead while raising. Do you have any ideas on how this could be done more elegantly?
I've also updated the test so it now also checks the behaviour I've mentioned in this comment.
This PR consists of two commits:
I had to include commit 1., as without it, commit 2. would expose a bug that previously existed, but did not fail mctoll's unit tests.
xor eax, eax
instructions that just zero out a register. I've encountered issues wheregetRegOperandValue
would generate aload
instruction from a promoted stack slot. The loaded value was not used, but no issues would arise during tests..neq: mov esi, eax cmp eax, 0 jne .print
.eq: mov esi, 0 jmp .print
.print: movabs rdi, offset .L.str mov al, 0 xor esi, esi call printf
After commit 1, (B) won't be generated in the code anymore.
In the above code, you can also see the issue that commit 2 fixes. Since we are doing
mov esi, eax
inbb.1
, mctoll replaces all uses of%EAX
with a load from the stack slot. This is seen at (A) in the above code.ESI-SKT-LOC
has not been written yet, but we're loading from the stack slot. This commit now just replaces uses if they dominate the store to the stack slot.test/asm_test/X86/mov-reaching-def.s
is raised to the following after commit 2.: