[PATCH] D59926: Constant folding sometimes creates large constants even though a smaller constant is used multiple times

[Ramakota Reddy via Phabricator via llvm-commits]

ramred01 added a comment.

In D59926#1445823 <https://reviews.llvm.org/D59926#1445823>, @lebedev.ri wrote:

> In D59926#1445822 <https://reviews.llvm.org/D59926#1445822>, @ramred01 wrote:
>
> > In D59926#1445820 <https://reviews.llvm.org/D59926#1445820>, @lebedev.ri wrote:
> >
> > > This sounds like a back-end problem.
> > >  Have you considered/tried solving it there, instead of limiting the middle-end?
> >
> >
> > This folding is happening in the middle-end itself.  The LLVM IR already has the folded value.
>
>
> That is precisely my point. Is that folding not optimal for the IR?


That folding would have been optimal for the IR if the constant were not to be reused.  If the constant is reused, then most architectures will do better with materializing one constant in a register and reusing it rather than materializing two constants.  Most architectures require two instructions to materialize 32-bit constants.  If, we add the additional operation of shift also, that now needs to be done, even with one reuse, it will generate 1 instruction fewer.  With more reuses and each reuse folded, that number could increase.

> 
> 
>> Hence we thought it best to handle it there as this should be affecting multiple architectures where materializing constants can take two or more instructions.
> 
> Have you considered the case where you *already* had that IR?
>  Even thought the middle end did not 'degrade' it, it will still not be handled by back-ends 'properly', right?

Yes, you are right.  What if I had that IR itself to deal with in the backend.  There are two possibilities.  One is when one constant is obviously related to another by some simple single operation arithmetic.  Those cases might be easier to decipher.  But what if a compare canonicalization pass in the interim has changed the constant.  Then such a situation will not be obvious and we stand to miss it or employ some more complex mechanism to undo the folding.

Instead isn't it better if we prevent the folding in the first place when we know that for most architectures it will cause more instructions to be generated?  There could be possible benefits for a few architectures in the situation hitherto but I'm not aware of them.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59926/new/

https://reviews.llvm.org/D59926