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

Krzysztof Parzyszek via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 17 08:20:04 PDT 2016

*** Problem

The documentation for function "getSize" in both MCRegisterClass and 
TargetRegisterClass states:
   /// getSize - Return the size of the register in bytes, which is also 
the size
   /// of a stack slot allocated to hold a spilled copy of this register.

The problem is that these two values are not always the same. For 
example, Hexagon has predicate registers that are 8 bits long and vector 
predicate registers that are 64 or 128 bits long, but their spill slots 
are of different sizes. None of these registers can be spilled directly, 
and they have to be transferred into a spillable register first. These 
spillable registers are larger: 32 bits and 512/1024 bits respectively, 
and so getSize must return the larger value in order to handle spills 

Different users of getSize may be interested in different aspects of the 
returned value: register allocator may care about the spill size while 
optimizations tracking the predicate values will be interested in the 
actual size of the register.

Moreover, if a register for which these two values differ had 
subregisters, the SubRegCoveredBits information could not be assumed to 
match the return value of getSize.

*** Proposal

Replace the getSize function in MCRegisterClass and TargetRegisterClass 
with two functions: getRegSize and getSpillSize.

TableGen would need to be modified to generate both of them, and unless 
the user specifies otherwise in a .td file, these values would be equal.

All users of getSize would need to be updated to call one of the new 
replacement functions. This can be done one step at the time: at first 
the old getSize would be present together with the new functions, it 
would be removed once all calls to it have been updated.

What does everyone think about it?

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

More information about the llvm-dev mailing list