These intrinsics are not documented by Intel, but are required for MS compatibility (MSVC does document them).
(LLVM part, Clang part posted separately)
Details
Diff Detail
Event Timeline
lib/Target/X86/X86InstrSystem.td | ||
---|---|---|
394 | Why should these change to ins? lgdt goes from memory into the chip and sgdt goes from the chip out to memory, right? |
Are these intrinsics supposed to be compiler barriers? Seems like bad stuff could happen if we speculated or sunk around them.
They have no constraints, which means they are equivalent to a normal external function call. Isn't that enough of a barrier? I think most users (kernels, hypervisors) are fine with LLVM reordering identified object memory accesses across such a barrier.
I don't think we can do better than a readwrite function call, really.
A readwrite function call ought to be a barrier to just about anything that reorders memory accesses, and if it's not enough - I don't think we have a stronger one available in the IR.
A volatile asm block should probably be equivalent, right?
lib/Target/X86/X86InstrSystem.td | ||
---|---|---|
394 | I may be deeply confused, but I've always been under the impression memory operands should always go into the "ins" - regardless of whether the instruction is storing or loading through the pointer. The pointer itself is always an input to the instruction, never an output of it. In practice, having it in as an "out" breaks pattern-matching since tablegen expects the input pattern to refer to instruction inputs, not outputs. |
Why should these change to ins? lgdt goes from memory into the chip and sgdt goes from the chip out to memory, right?