[PATCH] D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize

Zixuan Wu (Zeson) via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 10 20:00:12 PDT 2019


wuzish added a comment.

In D67148#1665594 <https://reviews.llvm.org/D67148#1665594>, @hfinkel wrote:

> Thanks for looking at this (it's been a problem for a long time). Let me suggest a different interface, which I believe will improve generality and reduce code duplication in the register-pressure estimator, and let me know what you think...
>
>   // Return the number of registers in the target-provided register class.
>   unsigned getNumberOfRegisters(unsigned ClassID = 0) const;
>   
>   // Return the target-provided register class for the provided type.
>   unsigned getRegisterClassForType(Type *Ty) const;
>   
>
> The idea, then, is that we just calculate register usage for each register class separately (i.e., keep a hash table), and then when computing the interleaving factor, etc. we just iterate over all of the register classes returned by the target, and pick the smallest interleaving factor calculated over all of the register classes. There's probably even a nice way to construct a default implementation of this in the backend (although that we'd save for follow-up work).


Yes. Using ClassID is more general and fine-grained. But I think there is no need to iterate all kinds of register class because target register class is flexible and many register classes target provided are only different width with same position(such as gprc and g8rc), which makes too many kinds of register classes to maintain and some are just the same thing. It's not just use smallest interleaving factor calculated over all of the register classes and we also need to care about the overlapping relationship between different register class.

In all, it would be too fine-grained and little over-design, many register classes are just same behavior as separate with scalar and vector, int and float. What's your opinion?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67148





More information about the llvm-commits mailing list