This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Use helpers for adding pred / CC operands. NFC
ClosedPublic

Authored by rovka on Dec 20 2016, 5:16 AM.

Details

Summary

Hunt down some of the places where we use bare addReg(0) or addImm(AL).addReg(0)
and replace with add(condCodeOp()) and add(predOps()). This should make it
easier to understand what those operands represent (without having to look at
the definition of the instruction that we're adding to).

Diff Detail

Repository
rL LLVM

Event Timeline

rovka updated this revision to Diff 82097.Dec 20 2016, 5:16 AM
rovka retitled this revision from to [ARM] [RFC] Use AddDefaultCC/Pred where possible. NFC.
rovka updated this object.
rovka added subscribers: llvm-commits, rengolin.

Hi Diana,

I have to say I never really liked the AddDefaultPred wrappers, so adding a new one for CC strikes me as going in the wrong direction.

I very much like the builder pattern as in RFC2. I think we can focus in the lowering layer for now and worry about MC later.

cheers,
--renato

rovka added a comment.Dec 20 2016, 6:45 AM

Thanks!

I'll have a shot at RFC 2.

FWIW, the RFCs are mostly orthogonal, so if we implement RFC 2 we can still do RFC 1 and / or RFC 3 on top of it:

  • RFC 1: our ARM builder will just have an addPred method instead of addDefaultPred
  • RFC 3: we can still have a template <typename WrappedBuilder> class ARMBuilder : public <WrappedBuilder>

Naturally, I would split all of that up into several patches.

kristof.beyls edited edge metadata.Dec 23 2016, 5:35 AM

I do think that using addDefaultPred/CC makes the code more readable compared to using .addreg(0) or .addImm((int64_t)ARMCC::AL).addReg(0), especially for newcomers to the ARM backend: it makes the BuildMI lines look that little bit more in line with ARM assembly syntax. In other words, it is easier to guess what "AddDefaultPred" or "AddDefaultCC" mean than ".addreg(0)", when the ARM assembly syntax for the corresponding instruction doesn't have that extra operand...

I don't have a strong preference over using addDefaultPred/CC or the other alternative discussed syntaxes like MIB.addSomeOperand().addSomeOtherOperand().addDefaultPred(), but I do think that the existing addDefaultPred/CC syntax may keep the BuildMI lines a little bit more similar to the ARM assembly syntax for the instruction that is being constructed: i.e. the Pred and CC parts are not written as normal operands to instructions.
I guess we'd have to compare a substantial sample of all the lines of code where this pattern can be applied to see if this similarity between the assembly syntax of the instruction and the BuildMI syntax actually holds; or if it's just hand-wavy wishful thinking on my part.

Trying to do that exercise on one of the lines changed in this patch:

AddDefaultCC(
    AddDefaultPred(BuildMI(MBB, MBBI, dl, TII.get(ARM::MOVr), ARM::SP)
                       .addReg(FramePtr)));

corresponds, I think, with the following instruction:

MOV SP, FramePtr.

There is a clearer mapping between the BuildMI statement and the corresponding assembly instruction, I think, than with the alternative syntaxes discussed earlier on this review.

TBH, if we'd decide to stick to using addDefaultPred/CC, these functions could use some doxygen documentation.

Thinking a bit more about this, if we'd end up deciding to go for option 2, I think the following function names and arguments would make code more easily readable compared to .addDefaultPred() or .addDefaultCC():

MIB.addSomeOperand().addSomeOtherOperand().addCondCode(ARMCC::AL).isFlagSetting(false)

i.e. drop the defaults (adding the explicit value ARMCC::AL or false is about as many characters as the word "Default", and it's more obvious what the meaning is of the code. Furthermore, for non-default values of these operands, also the more meaningful function names can be used, e.g. addCondCode(ARMCC:EQ) or isFlagSetting(true).

MatzeB edited edge metadata.Jan 2 2017, 5:21 AM

First: Factoring out the common code for adding those operands and thereby giving it a more obvious name than addReg(0) is a good thing!

I guess we'd have to compare a substantial sample of all the lines of code where this pattern can be applied to see if this similarity between the assembly syntax of the instruction and the BuildMI syntax actually holds; or if it's just hand-wavy wishful thinking on my part.

We should really compare the BuildMI order with how the MachineInstrs will look later! Of course it is a good idea to have the operand order of the MachineInstrs correspond to assembly syntax, but having BuildMI correspond to assembly doesn't help if the MachineInstrs themselfes have a different order.

I'm not necessarily against the custom MachineInstrBuilder, but all the templating machinery
feels a bit heavy for the problem at hand so I proposed a variant on how to integrate this with BuildMI in https://reviews.llvm.org/D28057.

rovka added a comment.Jan 10 2017, 3:17 AM

Hi,

Thanks to everyone for the suggestions.
Would something like this [1] do the trick? I haven't used a pair because from the MachineInstrBuilder's POV there's nothing special about pairs of MachineOperands. I also replaced all uses here [2] - I did this automatically with a custom tool, so I can easily change all uses again if people think it's still ugly.

[1] https://reviews.llvm.org/differential/diff/83787/
[2] https://reviews.llvm.org/differential/diff/83788/

rovka updated this revision to Diff 84283.Jan 13 2017, 4:58 AM
rovka retitled this revision from [ARM] [RFC] Use AddDefaultCC/Pred where possible. NFC to [ARM] Use helpers for adding pred / CC operands. NFC.
rovka updated this object.
rovka edited edge metadata.

Update patch to use the new helpers from r291890 and r291893.
With this, RFC 1 and RFC 2 are fully implemented (modulo any uses that I may have missed).
I'll leave RFC 3 (MCInstBuilder) for another time.

Much better!

rengolin accepted this revision.Jan 19 2017, 4:31 AM

Ok, this is just finishing off the pattern that was agreed and implemented beforehand, so I'll approve. LGTM. Thanks!

This revision is now accepted and ready to land.Jan 19 2017, 4:31 AM
This revision was automatically updated to reflect the committed changes.