This is an archive of the discontinued LLVM Phabricator instance.

[X86] Add intrinsic support for clac, stac, lgdt and sgdt
AbandonedPublic

Authored by mkuper on Aug 24 2015, 4:54 AM.

Details

Reviewers
majnemer
rnk
Summary

These intrinsics are not documented by Intel, but are required for MS compatibility (MSVC does document them).
(LLVM part, Clang part posted separately)

Diff Detail

Event Timeline

mkuper updated this revision to Diff 32945.Aug 24 2015, 4:54 AM
mkuper retitled this revision from to [X86] Add intrinsic support for clac, stac, lgdt and sgdt.
mkuper updated this object.
mkuper added reviewers: rnk, majnemer.
mkuper added a subscriber: llvm-commits.
rnk added inline comments.Aug 24 2015, 8:58 AM
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?

majnemer edited edge metadata.Aug 24 2015, 9:01 AM

Are these intrinsics supposed to be compiler barriers? Seems like bad stuff could happen if we speculated or sunk around them.

rnk edited edge metadata.Aug 24 2015, 9:30 AM

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.

mkuper added a subscriber: mkuper.Aug 24 2015, 11:45 PM

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.

mkuper abandoned this revision.Jun 10 2016, 4:56 PM