[PATCH] D74165: [x86] [DAGCombine] Prefer shifts of constant widths.

Fri Feb 7 10:45:12 PST 2020

jlebar marked an inline comment as done.
jlebar added inline comments.

================
Comment at: llvm/test/CodeGen/X86/select.ll:1123
+; MCU-NEXT:  .LBB20_1:
+; MCU-NEXT:    shll $3, %eax
 ; MCU-NEXT:    retl
----------------
RKSimon wrote:
> craig.topper wrote:
> > jlebar wrote:
> > > RKSimon wrote:
> > > > Regression
> > > Wow.  What...is...this...architecture.
> > > 
> > > I guess the answer is, we don't do this optimization if the target doesn't have cmov?
> > > 
> > > I mean, I'll do it, but are we sure the complexity is worth it for this target?  I can't even find an Agner optimization table for Intel MCU (Quark?).
> > MCU is basically a 486 on a much more modern silicon process.
> Its not just the MCU case - all of these targets' codegen look worse tbh
It does look worse.  I wanted to dig in more...

I somewhat arbitrarily tried Core2, Westmere, and Haswell with the x86-32 and x86-64 code.

 * *x86-32* `llc < testcases/shift-regression.ll -mtriple=i386-apple-darwin10 --x86-asm-syntax=intel -mcpu=athlon | llvm-mca -mcpu=<arch>`
 * *x86-64* `llc < testcases/shift-regression.ll -mtriple=amd64-apple-darwin10 --x86-asm-syntax=intel | llvm-mca -mcpu=<arch>`

I'm reporting "total cycles".

 * Core2 x86-32: HEAD 211 / patched 304
 * Core2 x86-64: HEAD 207 / patched 204
 * Westmere x86-32: HEAD 211 / patched 304
 * Westmere x86-64: HEAD 207 / patched 204
 * Haswell x86-32: HEAD 310 / patched 309
 * Haswell x86-64: HEAD 210 / patched 210

IOW for these CPUs it's a regression only in the x86-32 code and only in the older CPUs.

One thing we could do is limit this transformation to x86-64?  Or we could do more investigation, in which case I'm curious to know what kind of evidence you'd need to be comfortable with it.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74165