[llvm-bugs] [Bug 41055] New: [X86] FastSHLD optimization doesn't work well with TwoAddressInstruction pass

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Mar 13 10:54:49 PDT 2019


https://bugs.llvm.org/show_bug.cgi?id=41055

            Bug ID: 41055
           Summary: [X86] FastSHLD optimization doesn't work well with
                    TwoAddressInstruction pass
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: craig.topper at gmail.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

We have a special case to use a SHLD for rotate by immediate on Sandybridge and
Ivybridge. This avoids a dependecy on previous flag writers due to the strange
behavior of the flags for rotate.  The hardware on these CPUs has special
support for this idiom, but it requires that the 2 registers used by the SHLD
are the same physical register.

Unfortunately, the TwoAddressInstruction pass has to insert a COPY in front of
the SHLD to leave SSA form. This COPY will then become the input to the tied
src/dest pair. it will not be used for the other source. If the coalescer
doesn't remove this copy and the register allocator chooses a different
register for the input and output of the copy, then we will not have the same
physical registers for the SHLD instruction. So the hardware optimization won't
trigger.

The easiest way I can see to overcome this is to create a pseudo instruction in
X86 that will make the TwoAddressInstruction only see a single source. We can
expand it after register allocation to SHLD with the same source used twice.

-- 
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/20190313/32a70125/attachment.html>


More information about the llvm-bugs mailing list