[llvm-dev] RFC: Disambiguate RegClass->getSize()

Matthias Braun via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 17 13:23:23 PDT 2016


> On Aug 17, 2016, at 11:48 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 8/17/2016 1:32 PM, Matthias Braun wrote:
>> I had the impression that MCRegisterClass::getSize() is only ever used to determine the size of the spillslots and it would indeed be a good idea to rename it to something like getSpillSlotSize() (additionally this cannot be confused with the number of register in a class as well).
>> 
>> Are you aware of any user that actually wants the number of bits in a register? I am not sure we actually need that information at the generic codegen level. I must admit I hear about SubRegCoveredBits for the first time now, its main use at the moment is to output dwarf information and stack maps information. It also seems aarch64 and an internal target get away with not setting this information correctly. So far I assumed the lanemasks are the only tool to determine what parts of a register is covered. What uses do you have in mind?
> 
> Hexagon has a bit-tracker utility, whose core mechanism is target-independent. It keeps track of the values of each bit in all virtual registers. We then use it to simplify various instructions, like testbit, bitwise-and/or/xor, eliminate redundant instructions (like zero- or sign-extension of already extended values), etc.
I would have expected these things to happen at the DAGCombiner level where we still have types...

> 
> Predicate registers on Hexagon can be used as a simple "true/false" value (where only the LSB is checked), or as a mask in vector operations, where each bit is significant. Right now, in the Hexagon-specific code we simply override the register size (calculated from RC::getSize) with what we know the real size is.
> We don't yet handle vector predicate registers, but in the end it would be useful to do it, and to have a target-independent facility to check the register size instead of using getSize with hacks for known special cases.
> 
> If the bit-tracker was to be utilized by other targets, this would be something needed for it to work.
> 
> 
> Do you think there are any downsides to making the register size known?

I don't see any real issues. I was just making sure we actually need it, because the easiest code to maintain is the one that isn't there ;-) and it didn't seem to be used in the generic codegen parts today.

- Matthias


More information about the llvm-dev mailing list