This is an archive of the discontinued LLVM Phabricator instance.

[X86] Remove X86 specific dag nodes for RDTSC/RDTSCP/RDPMC. NFCI
ClosedPublic

Authored by andreadb on Mar 19 2019, 8:30 AM.

Details

Summary

This patch removes the following dag node opcodes from namespace X86ISD:

RDTSC_DAG,
RDTSCP_DAG,
RDPMC_DAG

The logic that expands RDTSC/RDPMC/XGETBV intrinsics is basically the same. The only differences are:

  • RDTSC/RDTSCP don't implicitly read ECX.
  • RDTSCP also implicitly writes ECX.

I moved the common expansion logic into a helper function with the goal to get rid of code repetition.
That helper is now used for the expansion of RDTSC/RDTSCP/RDPMC/XGETBV intrinsics.

No functional change intended.

Diff Detail

Repository
rL LLVM

Event Timeline

andreadb created this revision.Mar 19 2019, 8:30 AM
craig.topper added inline comments.Mar 19 2019, 10:36 AM
lib/Target/X86/X86ISelLowering.cpp
22867 ↗(On Diff #191308)

This is no longer glued to Hi. Is that ok?

craig.topper added inline comments.Mar 19 2019, 10:39 AM
lib/Target/X86/X86ISelLowering.cpp
22813 ↗(On Diff #191308)

I wonder if this should be glued to the MachineNode?

andreadb marked 2 inline comments as done.Mar 19 2019, 11:05 AM
andreadb added inline comments.
lib/Target/X86/X86ISelLowering.cpp
22813 ↗(On Diff #191308)

I think you are right. It is safer to glue it to N1. In practice, I didn't notice any regressions (even when I run some small experiments). I will chage it.

22867 ↗(On Diff #191308)

Right. I think that it is safer to glue it to HI. In practice, I noticed that the rdtscp codegen works fine even without that glue operand. However, conceptually it makes sense to schedule that node together with HI.
I'll see if I can change the signature to expandIntrinsicWChainHelper() so that it returns a glue value.

andreadb updated this revision to Diff 191367.Mar 19 2019, 12:13 PM

Addressed review comments.

Added missing Glue operands to nodes.

andreadb marked an inline comment as done.Mar 19 2019, 12:28 PM
andreadb added inline comments.
lib/Target/X86/X86ISelLowering.cpp
22821–22825 ↗(On Diff #191367)

Alternatively, this could be rewritten as:

SDVTList Tys = DAG.getVTList(MVT::Other, MVT::Glue);
SDValue N1Ops[] = {Chain, Glue};
SDNode *N1 = DAG.getMachineNode(
    TargetOpcode, DL, Tys, ArrayRef<SDValue>(N1Ops, Glue.getNode() ? 2 : 1));

Basically, Glue cannot be null when it is explicitly passed in input to getMachineNode().

craig.topper added inline comments.Mar 19 2019, 12:44 PM
lib/Target/X86/X86ISelLowering.cpp
23090 ↗(On Diff #191367)

I can't decide if these should really be in the X86IntrinsicsInfo.h table. We're not using the Opc0 field. So we're treating them as one offs. Which makes me wonder if they shouldn't just be in the switch that is used when the table lookup fails.

Or maybe we should merge RDPMC and XGETBV using the Opc0 field?

andreadb marked an inline comment as done.Mar 19 2019, 12:52 PM
andreadb added inline comments.
lib/Target/X86/X86ISelLowering.cpp
23090 ↗(On Diff #191367)

I think it is a good idea to just merge these two cases and simply write:

expandIntrinsicWChainHelper(Op.getNode(), dl, DAG, IntrData->Opc0, X86::ECX,
                                Subtarget, Results);
andreadb marked an inline comment as done.Mar 19 2019, 1:26 PM
andreadb added inline comments.
lib/Target/X86/X86ISelLowering.cpp
23090 ↗(On Diff #191367)

Actually, we could also merge case RDTSC along RDPMC and XGETBV .
In the case of RDTSC, function getReadTimeStampCounter() simply delegates to expandIntrinsicWChainHelper().

Would it be okay if for now I merge these three cases togheter?

craig.topper added inline comments.Mar 19 2019, 1:59 PM
lib/Target/X86/X86ISelLowering.cpp
23090 ↗(On Diff #191367)

Sounds good.

andreadb marked an inline comment as done.Mar 19 2019, 2:28 PM
andreadb added inline comments.
lib/Target/X86/X86ISelLowering.cpp
23090 ↗(On Diff #191367)

Ah... nevermind.
I didn't realize that RDTSC is used as IntrData->Type for both intrinsic rdtsc and rdtscp.
That means, It is not safe to also merge case RDTSC with RDPMC and XGETBV, because rdtscp requires a special treatment.

For now, I am going to just merge RDPMC and XGETBV together.

andreadb updated this revision to Diff 191396.Mar 19 2019, 2:39 PM

Patch updated.

Merged case RDPMC with case XGETBV.

This revision is now accepted and ready to land.Mar 19 2019, 2:44 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 20 2019, 4:20 AM