Combine two G_PTR_ADDs, but keep the register bank of the constant.
That way, the combine can be used in post-regbank-select combines.
This is the first combine in CombinerHelper that uses register banks, I
hope it is the right place.
sebastian-ne on May 28 2021, 9:19 AM.Authored by
I wonder if we should try to intelligently pick the register banks for constants before adding combine logic relying on the current scheme where all constants end up in SGPRs.
I'm not sure how we want to address this though. Theoretically RegBankSelect itself should be selecting the G_CONSTANT bank based on the users, it just doesn't try to do this now. We could also have a different post regbank combine. We do have situations where depending on the value and how many uses there are, we may just want to rematerialize the constant multiple times. I'm not sure if that's something RegBankSelect should be doing itself
+more GlobalISel reviewers.
What do you all think about this? It seems to be the first generic combine designed specifically to run post-regbankselect. Should we be going in this direction? Or modifying existing combines so they can work both pre- and post-regbankselect?
Assuming we do want this combine, is there a neater way of writing the "ugly manual regbank preservation" that Matt highlighted?
Modifying existing combines to work post-RBS, or adding RBS preserving variants, doesn't seem ideal to me but I don't have a better suggestion. It would be best if we could finish the tablegen combiner implementation one day and be able to specify this stuff declaratively if possible.
As for this solution, we use isLegalOrBeforeLegalizer() hooks in other combines, maybe we could add something similar for isBeforeRegBankSelect() and add the regbank checks guarded by that condition in the original combine.
I now added two helper function in CombinerHelper,
With these, adding post-RBS support to a combine is a bit shorter.