This is an archive of the discontinued LLVM Phabricator instance.

[GISel][NFC]: Make MachineIRBuilder fully stateless
AbandonedPublic

Authored by aditya_nandakumar on Sep 14 2018, 6:16 PM.

Details

Summary

Completely separate out MachineIRBuilderState from MachineIRBuilder as it makes it possible to use different kinds of builders (ConstantFolding/CSEing) by just passing the State.
This makes it inconvenient by 1 extra line to define a builder - for eg

MachineIRBuilderState State;
MachineIRBuilder B(State);
AnyOtherBuilder AOB(State);

Also instead of passing in MachineIRBuilder everywhere - pass in the state - this allows for the target/hook to be explicit about what they expect the builder to do.

Diff Detail

Repository
rL LLVM

Event Timeline

Hi Aditya,

this allows for the target/hook to be explicit about what they expect the builder to do.

What do you mean by that?

Put differently, is there any example of that in that patch?

Cheers,
-Quentin

Looks ok, if a bit cumbersome with the additional state (do we need to hold references to it?). I'd like to see how this state is used with the CSE builder first though.

Hi Aditya,

this allows for the target/hook to be explicit about what they expect the builder to do.

What do you mean by that?

When there are many kinds of MachineIRBuilders the question always comes out to what the default should be. Instead of picking a default (which most of the time targets won't change) - now various hooks/customlegalization methods will need to decide what kind of builder they need (Say CSE vs ConstantFolding vs Basic). With this, we only pass in the State, and the method/function will explicitly pick a builder.
Additionally I ran into a bug for the following code sequence.

bool legalizeCustom(MachineIRBuilder &B) {
  ConstantFoldingBuilder CB(B.getState());
  CB.setInsertionPoint(SomeMI); // Sets the insertion point only for the CB's copy of the State/insertion point.
  if (someCondition)
     return someLegalizerHelper(B); // Pass B to a helper - but B's copy of the state has still no MBB/Insertion point set - only CB's copy was updated.
  else
     // Build using CB.
}

In the above code someLegalizerHelper had assumed that the insertion point will always be set before it was called - but in this case it was not.
Instead the following code sequence would not have the above bug.

bool legalizeCustom(MachineIRBuilderState &State) {
  ConstantFoldingBuilder CB(State);
  CB.setInsertionPoint(SomeMI);  // Changing the state that was passed in.
  if (someCondition)
    return someLegalizerHelper(State); // Insertion point is still reflected in State.
  // Build with CB.
}

Put differently, is there any example of that in that patch?

Cheers,
-Quentin

Looks ok, if a bit cumbersome with the additional state (do we need to hold references to it?). I'd like to see how this state is used with the CSE builder first though.

I'm in the process of reworking parts of the CSEBuilder - I'll try to have a patch in a few days. It would look something like this unit test

void someFoo(MachineIRBuilderState &State) {
  CSEMIRBuilder CSEB(State);
  CSEB.setInsertionPoint(SomeMI);
  auto A = CSEB.buildConstant(s32, 42);
  auto B = CSEB.buildConstant(s32, 42);
  assert(A == B);
  MachineIRBuilder B(State);
  auto C = B.buildConstant(s32, 42);
  assert(C != A);
  unsigned NewReg = MRI.createGenericVReg(s32);
  auto Copy = CSEB.buildConstant(NewReg, 42);
  assert(Copy->getOpcode() == COPY);
  assert (Source of Copy == A);
}

As of now the State has a CSEInfo object which has info about what instructions are available in the CSEMap and will use them if available instead of creating a new vreg + new inst or materialize a copy if a specific destreg is passed in.

aditya_nandakumar abandoned this revision.Jan 29 2019, 9:20 AM