Re-add the feature flag for invpcid, which was removed in r294561.
Add an intrinsic, which always uses a 32 bit integer as first argument,
while the instruction actually uses a 64 bit register in 64 bit mode
for the INVPCID_TYPE argument.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 18411 Build 18411: arc lint + arc unit
Event Timeline
lib/Target/X86/X86.td | ||
---|---|---|
248 | HasINVPCID. It's the name of an instruction so we should keep the caps. | |
lib/Target/X86/X86InstrInfo.td | ||
907 | hasINVPCID | |
lib/Target/X86/X86InstrSystem.td | ||
653 | SUBREG_TO_REG should only be used if you know absolutely the instruction that produced $src1 zeroed the upper bits. You would need to analyze the DAG to prove it. See the "def32" PatLeaf in X86InstrCompiler.td. If it can't be proven, you need a fall back pattern to use a MOV32rr instruction to force zeroes into the upper bits. | |
test/CodeGen/X86/invpcid-intrinsic.ll | ||
38 | Why are you testing with a load for type, but not testing without a load? |
test/CodeGen/X86/invpcid-intrinsic.ll | ||
---|---|---|
38 | There is a test without a load above this one. |
LGTM.
It looks like neither icc or MSVC doe a perfect job of ensuring zero extension here. For example: https://godbolt.org/g/UqnXh8
HasINVPCID. It's the name of an instruction so we should keep the caps.