[all-commits] [llvm/llvm-project] 8e7e6a: [X86] Restore selection of MULX on BMI2 targets.
topperc via All-commits
all-commits at lists.llvm.org
Wed May 27 12:01:52 PDT 2020
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: 8e7e6a8d6bae19c5a18e0d0daa0614272b85598c
https://github.com/llvm/llvm-project/commit/8e7e6a8d6bae19c5a18e0d0daa0614272b85598c
Author: Craig Topper <craig.topper at gmail.com>
Date: 2020-05-27 (Wed, 27 May 2020)
Changed paths:
M llvm/lib/Target/X86/X86ISelDAGToDAG.cpp
M llvm/test/CodeGen/X86/atomic-unordered.ll
M llvm/test/CodeGen/X86/bmi2-x86_64.ll
M llvm/test/CodeGen/X86/bmi2.ll
M llvm/test/CodeGen/X86/hoist-invariant-load.ll
M llvm/test/CodeGen/X86/i128-mul.ll
M llvm/test/CodeGen/X86/mulx32.ll
M llvm/test/CodeGen/X86/mulx64.ll
M llvm/test/CodeGen/X86/pr35636.ll
Log Message:
-----------
[X86] Restore selection of MULX on BMI2 targets.
Looking back over gcc and icc behavior it looks like icc does
use mulx32 on 32-bit targets and mulx64 on 64-bit targets. It's
also used when dividing i32 by constant on 32-bit targets and
i64 by constant on 64-bit targets.
gcc uses it multiplies producing a 64 bit result on 32-bit targets
and 128-bit results on a 64-bit target. gcc does not appear to use
it for division by constant.
After this patch clang is closer to the icc behavior. This
basically reverts d1c61861ddc94457b08a5a653d3908b7b38ebb22, but
there were no strong feelings at the time.
Fixes PR45518.
Differential Revision: https://reviews.llvm.org/D80498
More information about the All-commits
mailing list