[PATCH] D4351: bug fix for PR20020: anti-dependency-breaker causes miscompilation

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 10 03:53:02 PDT 2021


spatel added inline comments.


================
Comment at: llvm/trunk/lib/CodeGen/CriticalAntiDepBreaker.cpp:203
 
+    // If this reg is tied and live (Classes[Reg] is set to -1), we can't change
+    // it or any of its sub or super regs. We need to use KeepRegs to mark the
----------------
danilaml wrote:
> @spatel Hi, I was debugging some miscompile issue and came across what I think is very similar bug.
> Do you remember why you check against `-1` here? In my test-case (which I'm trying to reduce), the Classes[Reg] is some regclass non -1 value. According to the comments for Classes:
> ```
> /// For live regs that are only used in one register class in a
>     /// live range, the register class. If the register is not live, the
>     /// corresponding value is null. If the register is live but used in
>     /// multiple register classes, the corresponding value is -1 casted to a
>     /// pointer.
> ```
> My question is: why is this code is checking for `-1` specifically, instead of `!= nullptr`? If it's not live, would it still be OK? I have trouble following the logic in this pass.
> The comments for scan indicate that
> ```
> // Note: AntiDepReg may be referenced by a two-address instruction such that
> // it's use operand is tied to a def operand ...
> // In this case, both the use and def operands are in
> // RegRefs because the def is inserted by PrescanInstruction and not erased
> // during ScanInstruction.
> ```
> which is evidently not true in my test case (e.g. XOR has 3 same-reg operands, one pair tied, so the ScanInstruction would remove all RegRefs added by Prescan due to the 3rd non-tied reg, and skip the first tied def when adding refs back).
Wow - I barely remember creating this patch. I haven't looked at anything near here in so long, that I can't offer much help. I see that you posted D107582 - let's see if we can find someone more knowledgeable to review.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D4351/new/

https://reviews.llvm.org/D4351



More information about the llvm-commits mailing list