This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] ISel legalization debug messages. NFCI.
ClosedPublic

Authored by SjoerdMeijer on Aug 21 2017, 8:25 AM.

Details

Summary

Debugging AArch64 instruction legalization and custom lowering is really an unpleasant experience because it shows nodes that appear out of thin air. This happens because newly created nodes in previous steps are not dumped, but are then picked up for legalization and printed.

This adds debug messages for several custom lowering functions; this is does not fix all custom lowerings, but is hopefully a good start.

Diff Detail

Repository
rL LLVM

Event Timeline

SjoerdMeijer created this revision.Aug 21 2017, 8:25 AM
samparker edited edge metadata.Aug 21 2017, 8:40 AM

Hi Sjoerd,

I completely agree that ISel can be a confusing pain with a lack of information! But wouldn't it be more helpful to make the detailed effort in SelectionDAG, in the calls to getNode, etc? Then all backends can take advantage and there isn't the burden on developers to remember to insert a call your debug function.

cheers,
sam

The disadvantage of moving it to SelectionDAG is that we lose the context where the new nodes are created. In other words, the debug message will (potentially) become less specific. But since they currently do not have an awful lot of context, I think your suggestion makes sense. I will experiment to see if it works.

I will split this patch up in a target dependent, and target independent patch. I will continue here with the AArch64 specific messages, and I have created D36984 for some of the debug messages that I moved to SelectionDAG getNode functions.

Removed the debug messages that were moved to SelectionDAG in D36984

asb added a subscriber: asb.Aug 22 2017, 7:54 AM

I think this is a really great initiative. I've added one inline comment. In addition to that, I have a general note. My natural instinct would have been to try to print a more informative message in the caller of the various is* functions (such as isLegalArithImmed). e.g. might better debug output be produced if debug printing were added to getAArch64Cmp instead?

lib/Target/AArch64/AArch64ISelLowering.cpp
4888 ↗(On Diff #112170)

If we're going to print a debug message for every call, would it be worth at least dumping the global address symbol as well?

Hi Alex, thanks for the feedback. The difficulty here is finding the right balance of adding (good) debug messages, and not cluttering the code too much. I think what you are suggesting is what I had in my first revision: that had debug messages in the different AArch64 lowering functions. Then Sam's suggestion was to move some of these messages to SelectionDAG (which we did in D36984), which has 2 advantages: all targets benefit, and it does not clutter up the code. Also, I think this is quite difficult to get completely right the first time. So I think we will have to see what works and what is good and I will be adding more stuff as I go along. There's a lot of room for improvement here, but I already find these extra debug messages quite useful...

I have addressed your comment about the global address.

asb added a comment.Aug 22 2017, 9:56 AM

Hi Alex, thanks for the feedback. The difficulty here is finding the right balance of adding (good) debug messages, and not cluttering the code too much. I think what you are suggesting is what I had in my first revision: that had debug messages in the different AArch64 lowering functions. Then Sam's suggestion was to move some of these messages to SelectionDAG (which we did in D36984), which has 2 advantages: all targets benefit, and it does not clutter up the code. Also, I think this is quite difficult to get completely right the first time. So I think we will have to see what works and what is good and I will be adding more stuff as I go along. There's a lot of room for improvement here, but I already find these extra debug messages quite useful...

I definitely agree that this is something that can develop in time. I think splitting out some of the debug printing to the target-independent SelectionDAG code was a good move too. I suppose my comment only really applied to isLegalArithImmed. As you suggest, the other is* functions are called from outside AArch64ISelLowering anyway, and in the case of isFPImmLegal there's benefit in exposing details of that decision process. Anyway, I was interested if you'd thought about hoisting some of the debug messages to the caller, and the answer is obviously yes! This patch looks good to me, and I'm looking forward to monitoring how it this approach to ISel debugging develops.

Added missing spaces.

samparker accepted this revision.Aug 23 2017, 1:04 AM

LGTM, thanks!

This revision is now accepted and ready to land.Aug 23 2017, 1:04 AM

thanks for reviewing!

This revision was automatically updated to reflect the committed changes.