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

[Krzysztof Parzyszek via llvm-dev]

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.

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?


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation