An intrinsic for an old instruction, as described in the Intel SDM.
Details
Diff Detail
Event Timeline
Why do we need a feature flag for this in the first place? The MSVC model for most "instruction" intrinsics is that the exact instruction is emitted regardless of the feature enabled. The target attribute seems like it would get in the way of that.
lib/Headers/intrin.h | ||
---|---|---|
196 ↗ | (On Diff #147784) | What problems does this redeclaration cause? |
I'm fine with getting rid of the feature flag, here, and then probably also for other instructions in similar situations (pconfig, wbnoinvd, clwb, etc...).
But as long as we keep those other feature flags, I guess we should just be consistent.
lib/Headers/intrin.h | ||
---|---|---|
196 ↗ | (On Diff #147784) | Now that I think about it, none. |
lib/Headers/intrin.h | ||
---|---|---|
196 ↗ | (On Diff #147784) | Also, I think this could be added as TARGET_HEADER_BUILTIN..."intrin.h", ALL_MS_LANGUAGES into BuiltinsX86.def |
lib/Headers/intrin.h | ||
---|---|---|
196 ↗ | (On Diff #147784) | It could be, but then you'd need to implement it as a builtin instead of having invpcidintrin.h, right? |
lib/Headers/intrin.h | ||
---|---|---|
196 ↗ | (On Diff #147784) | Meanwhile, I just realized, we add the !defined(_MSC_VER) condition around the inclusion of all such header files, as I did with invpcidintrin.h. |
Relocated header inclusion from x86intrin.h -> immintrin.h
I gave up on the MSVC intrinsic idea, it wouldn't work in a way compatible with MSVC as long as LLVM requires the feature to be enabled anyways. If once we decide to remove such feature flags for such system programming instructions, we can get back this.
this should be below ENH_MOVSB to keep the bits in order