This is an archive of the discontinued LLVM Phabricator instance.

[PPC][AIX] Fix toc-data peephole bug and some related cleanup.
ClosedPublic

Authored by sfertile on Jul 21 2023, 7:54 AM.

Details

Summary

Set the ReplaceFlags variable to false, since there is code meant only for the ADDItocHi/ADDItocL nodes guarded by this. This has the side effect of disabling the peephole on AIX when the load/store instruction has a non-zero offset fixing the bug reported in https://github.com/llvm/llvm-project/issues/63927. This patch also fixes retrieving the ImmOpnd node from the AIX small code model pseudos and does the same for the register operand node. This allows cleaning up the later calls to replaceOperands. Finally move calculating the MaxOffset into the code guarded by ReplaceFlags as it is only used there and the comment is specific to the ELF ABI.

Diff Detail

Event Timeline

sfertile created this revision.Jul 21 2023, 7:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2023, 7:54 AM
sfertile requested review of this revision.Jul 21 2023, 7:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2023, 7:54 AM

@amyk, fyi, since it appears you have plans to change code in the same vicinity for https://reviews.llvm.org/D155600 and its follow-up (for non-zero load/store offsets).

hubert.reinterpretcast edited the summary of this revision. (Show Details)Jul 23 2023, 8:24 PM
llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
7669–7670

This is moved a bit too far from where UpdateHBase is being set (thus making the initialization of HBase here confusing).

Suggestion:

  • Use the default value for HBase.
  • Move these declarations down to immediately before the if (ReplaceFlags) block.
  • Move the RegOperand declaration to immediately before that of ImmOpnd.
  • Use RegOperand in place of HBase until after the ADDIStocHA8 check.
  • Assign to HBase the value of RegOperand.
7670

ImmOpnd and RegOperand should never be associated with the same Base operand index. The conditions should be harmonized. It seems to me that the OpcodeIsAIXTocData condition is the more conservative one.

7728–7729

This comment is incorrect. Substitution does not always occur with the operands reversed now.

llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
7752

Can we add a FIXME to verify and better document the reason why Offset needs to be a multiple of 4 when the alignment is less than 4? It is not about the encoding of the instruction: the value of Offset comes directly from the original load/store instruction on the path that reaches this check.

sfertile updated this revision to Diff 546485.Aug 2 2023, 8:21 AM

Address first round of review comments.

LGTM with minor comments. Thanks for the patch!

llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
7656

Suggest rename to OpcodeIsAIXSmallTocData.

7663–7664

Minor nit: Be consistent on whether to call getOperand through the SDValue or on the SDNode directly.

7670–7674

Move variables meant to be set by the block to immediately before the block.

This revision is now accepted and ready to land.Aug 4 2023, 5:32 PM
This revision was landed with ongoing or failed builds.Aug 10 2023, 7:23 AM
This revision was automatically updated to reflect the committed changes.

It seems to me that this section of this function has built up a significant amount of technical debt and we should really try to get it refactored so it is clearer what is happening and why. Please note that this is a statement about the existing implementation, not just about the updates in this patch.

Just some examples:

  • There is a statement that these pseudo instructions are used exclusively for AIX small code model for globals defined in the TOC. Is this enforced somehow? Will it become a problem if it is used in a different context?
  • The operands for these instructions are reversed. Why? If we have defined something specifically for this particular optimization and decided to define it in a way that is deliberately different from other similar artifacts, that seems misguided to me.
  • It seems that the ReplaceFlags variable controls more than whether or not we're replacing the flags
  • It should probably be clarified what this code does in different contexts (ELFv1, ELFv2, AIX, different code models - particularly pointing out the differences)

Also, we committed this as well as backported it to the release branch. This is a non-trivial patch that didn't really have time in trunk to really bake in. I think a more appropriate course of action would probably have been to turn off the optimization due to the bug, get that ported back and then work on fixing and re-enabling it in trunk in the early part of the release.