[PATCH] D67875: [X86] X86DAGToDAGISel::matchBEXTRFromAndImm(): if can't use BEXTR, fallback to BZHI (PR43381)

[Andrea Di Biagio via Phabricator via llvm-commits]

andreadb added inline comments.


================
Comment at: llvm/test/CodeGen/X86/bmi-x86_64.ll:28
+; BMI2-SLOW:       # %bb.0:
+; BMI2-SLOW-NEXT:    movl $16, %eax
+; BMI2-SLOW-NEXT:    bzhil %eax, %edi, %eax
----------------
craig.topper wrote:
> davezarzycki wrote:
> > craig.topper wrote:
> > > lebedev.ri wrote:
> > > > craig.topper wrote:
> > > > > This doesn't look like an obvious improvement. The movq in the original code is basically free. So it was really 2 uops. The new code is 3 uops.
> > > > That is not what mca says, i guess it's not modelled in those sched models?
> > > > Is there any particularly good intel cpu schedule model that is in LLVM i should use as reference?
> > > > 
> > > > But yes, that is true.
> > > > 
> > > I don't think move elimination is modeled in any of the scheduler models. @andreadb is that right?
> > Hi @craig.topper – I think the original bug report about a load not being folded into BZHI is being lost in the noise of this change proposal.
> I think this proposed change is too general. The original case is only using BZHI to avoid a MOVABSQ to load the AND mask. So I think it's largely an i64 specific issue and we should probably handle it as such.
Sorry for the late reply. I only saw the message now.

Move elimination is currently only modelled for BtVer2 (Jaguar allows a limited form of move elimination for cases where the source operand is known to be zero). That being said, BtVer2 does not feature BMI2.

Move elimination is only enabled for models that provide a definition of tablegen class RegisterFile and a definition of IsOptimizableRegisterMove.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67875