[PATCH] D119578: [X86] selectLEAAddr - add X86ISD::SMUL/UMULO handling

[Phoebe Wang via Phabricator via llvm-commits]

pengfei added inline comments.


================
Comment at: llvm/test/CodeGen/X86/xmulo.ll:489-492
 ; WIN32-NEXT:    movl %ecx, %edx
-; WIN32-NEXT:    movl %eax, %esi
 ; WIN32-NEXT:    seto %ch
 ; WIN32-NEXT:    orb %bh, %ch
+; WIN32-NEXT:    leal (%edi,%eax), %esi
----------------
lebedev.ri wrote:
> pengfei wrote:
> > RKSimon wrote:
> > > pengfei wrote:
> > > > No sure if it's always beneficial. IIRC, we have some disadvantages on decoding complex lea.
> > > Does Intel arch count simple add lea with a different dst reg as complex?
> > The AOM F.3.2.2 says
> > ```
> > LEA: The LEA instruction uses the AGU instead of the ALU. If one of the source register of LEA must
> > come from an execution unit. This dependency will also cause a 3 cycle delay. Thus, LEA should not
> > be used in the technique of adding two values and produce the result in a third register. LEA should
> > be used for address computation.
> > ```
> Won't `TuningSlowLEA` take care of that by undoing the transform if we end up with bad code?
Not sure. It seems they are different. We only set `TuningSlowLEA` for Atom, but AOM says:
```
Assembly/Compiler Coding Rule 5. (MH impact, H generality) For Intel Atom processors, LEA
should be used for address manipulation; but software should avoid the following situations which
creates dependencies from ALU to AGU: an ALU instruction (instead of LEA) for address manipulation or
ESP updates; a LEA for ternary addition or non-destructive writes which do not feed address
generation. Alternatively, hoist producer instruction more than 3 cycles above the consumer instruction
that uses the AGU.
```
Here the case looks like "non-destructive write".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119578