PATCH: TableGen: Report an error when defining more than 32 subreg indices

Tom Stellard tom at stellard.net
Thu Jan 31 11:56:26 PST 2013


On Thu, Jan 31, 2013 at 11:35:16AM -0800, Jakob Stoklund Olesen wrote:
> 
> On Jan 31, 2013, at 11:16 AM, Tom Stellard <tom at stellard.net> wrote:
> 
> > On Thu, Jan 31, 2013 at 09:30:48AM -0800, Jakob Stoklund Olesen wrote:
> >> 
> >> On Jan 31, 2013, at 6:23 AM, Tom Stellard <tom at stellard.net> wrote:
> >> 
> >>> The maximum number of sub reg indices is limited to 32 by use of the
> >>> LaneMask.  TableGen currently assigns all sub reg indices after the
> >>> first 32 to the same LaneMask, which leads to bugs in the register
> >>> allocator.  This patch prevents the user from defining more than 32
> >>> sub reg indices.
> >> 
> >> Hi Tom,
> >> 
> >> That behavior is deliberate. It allows graceful degradation for crazy targets with more than 32 vector lanes by sharing the last available bit in the lane mask.
> >> 
> > 
> > I'm not sure I understand exactly what the lane mask is supposed to
> > represent.  Can you give a brief explanation of what it is used for?
> 
> Weird targets have weird register banks, making it necessary to have a somewhat abstract model for overlapping sub-registers. Just look at ARM and x86.
> 
> The lane masks are used to determine that two sub-registers are definitely not overlapping. If LaneMask(SubA) & LaneMask(SubB) is null, it is safe to assume that the sub-registers don't overlap.
> 
> The masks are not supposed to be used to determine if one sub-register is completely contained within another, and that could be the mistake the coalescer is making.
> 

Thanks for the explanation.  I'll have to go back and try and pin down
the exact cause of the bugs I was seeing, but the main problem was that
I had register classes like this:

IndirectRegClass with 32 SubRegs {indirect0..indirect31}
R600_128 with 4 SubRegs {sel_x, sel_y, sel_z, sel_w}
R600_64  with 2 SubRegs {hi, lo}
SI_256   with 8 SubRegs {sub0 .. sub7}

Since the subreg indices are sorted by name, subregs hi and
indirect0..indirect30 where given unique LaneMasks while all the rest
shared the same LaneMask.  This means that all of the subregs of the
R600_128 class had the same LaneMask.  Could this potentially cause bugs
in the register coalescer?

-Tom



More information about the llvm-commits mailing list