This is an archive of the discontinued LLVM Phabricator instance.

[SystemZ] Handle 3-address instructions in foldMemoryOperandImpl()
AbandonedPublic

Authored by jonpa on Jun 3 2019, 1:33 AM.

Details

Reviewers
uweigand
Summary

This patch is to be applied on top of the recent 3-address patch (https://reviews.llvm.org/D60888). Without this, there were a dozen of tests that failed with D60888, but with this patch they do not.

TargetPassConfig::addPostRewrite() method and VirtRegMap argument to foldMemoryOperand() approved already on a separate patch by Quentin Colombet (https://reviews.llvm.org/D58923).

Statistics:

"regalloc - Number of folded stack accesses":

master: 17762
3-address patch without handling in foldMemoryOperand(): 14081
3-address patch + this patch without commutation: 15285
with commutation: 17395

"systemz-postrewrite - Number of copies inserted before folded mem ops."
with commuation: 9

Diff Detail

Event Timeline

jonpa created this revision.Jun 3 2019, 1:33 AM

I'm a bit confused about the mapping logic. For the case of e.g. ADD, we today have

AR ---> gets mapped to A by getMemOpcode

and

ARK --> no mapping via getMemOpcode

I would have expected the first mapping to stay as is, and a new second mapping of ARK to some pseudo A_MemFoldPseudo.
Instead, it seems you're redirecting the mapping of AR to A_MemFoldPseudo, if I'm reading the patch correctly. Why is this? If you already have an AR, you already have a two-operand form, so it can just be modified to A. The problem is as long as you have an ARK ...

I may have forgot, but could you explain again why we need (yet another) new pass for this, instead of just expanding the pseudo in one of the existing pseudo-expansion passes?