[llvm-bugs] [Bug 51494] New: [SchedModel] Missing ReadAdvance for MULX and ADCX/ADOX instructions

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Aug 16 09:02:24 PDT 2021


            Bug ID: 51494
           Summary: [SchedModel] Missing ReadAdvance for MULX and
                    ADCX/ADOX instructions
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: andrea.dibiagio at gmail.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, pengfei.wang at intel.com,
                    spatel+llvm at rotateright.com


mulxl (%rdi), %eax, %edx

> llvm-mca -mcpu=haswell -timeline -iterations=2

Timeline view:
Index     0123456789          0

[0,0]     DeeeeeeeeeER   .    .   mulxl (%rdi), %eax, %edx
[1,0]     . D=======eeeeeeeeeER   mulxl (%rdi), %eax, %edx

There is a dependency on EDX (which is both implicitly read and written).
However, the load uOP can start in advance.

If I add a read-advance for the implicit read of EDX, I get this:

Timeline view:
Index     0123456789

[0,0]     DeeeeeeeeeER   .   mulxl      (%rdi), %eax, %edx
[1,0]     . D==eeeeeeeeeER   mulxl      (%rdi), %eax, %edx

Zen models override the (list of) Sched Reads/Writes for MULX32/MULX64 using an
InstRW. For those models, fixing this issue in X86InstrArithmetic.td would not
be enough.
When possible, models should try not to use InstRW. In this case, it is
probably better to just introduce a new Write definition specifically for MULX
(i.e. instead of reusing WriteIMul32/WriteIMul64). But this would be the goal
of a separate patch.


The problem with ADCX/ADOX is similar to the issue reported as bug 51322 for
the ADC/SBB.

adcx (%rdi), %rcx

> llvm-mca adcx.s -mcpu=znver2 -timeline -iterations=2

Timeline view:
Index     0123456789

[0,0]     DeeeeeER  . .   adcxq (%rdi), %rcx
[1,0]     D=====eeeeeER   adcxq (%rdi), %rcx

The second load could start a few cycles earlier. For what I can see, we are
just missing a read-advance for the implicit read of EFLAGS.

NOTE: the same issue is reproducible on various other cpus (i.e. not just

In theory, this is how the timeline should look like:

Timeline view:
Index     012345678

[0,0]     DeeeeeER.   adcxq      (%rdi), %rcx
[1,0]     D=eeeeeER   adcxq      (%rdi), %rcx

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210816/7e0d8c8e/attachment-0001.html>

More information about the llvm-bugs mailing list