[llvm-dev] problem with non-allocatable register classes

Matt Arsenault via llvm-dev llvm-dev at lists.llvm.org
Fri May 5 10:27:39 PDT 2017


> On May 4, 2017, at 19:34, Davis, Alan via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> I am using some non-allocatable RegisterClasses to define lists of registers that are used for various non-allocation-related processing in the back end. For example, we have a post-allocation functional unit selection pass that is guided by the register assignment, which does things like ‘myRegClass.contains(Reg)’ to see if a register is in the set of registers accessible by a given unit.
>  
> These sets contain lists of both allocatable and non-allocatable registers (for example, GPRs plus PC and SP). So I defined them as non-allocatable, and defined separate classes for use in the allocator.
>  
> The problem is that tablegen does all kinds of clever analysis of the register classes, determining subsets and supersets and such, which are used to answer methods like getCommonSubClass(). In some cases it synthesizes new classes, which may or may not be allocatable depending on how the non-allocatable classes get mixed in. If a function like getCommonSubClass() returns a non-allocatable class, bad things happen (e.g. assertion failures from setRegClass()).
>  
> It seems to me that functions like getCommonSubClass() should never return non-allocatable classes. But there seems to be no provision in tablegen to keep that from happening. It seems likely that no one has encountered this because for most targets non-allocatable classes contain registers that don’t overlap much with the allocatable classes.
>  
> Does anyone have any guidance as far as fixing or working around this?
>  
> -Alan
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
I’m not sure I would agree that getCommonSubClass should never return a non-allocatable class. You still want to be able to do the same kinds of queries for non-allocatable classes. Maybe it might make sense to assert that if the input is allocatable the result register class also is?

Could you describe in more detail what your register class hierarchy looks like? It sounds to me like you need to refactor your register classes are split up into allocatable and non-allocatable components. Are you adding the non-allocatable registers directly to the allocatable classes, or adding non-allocatable subclasses to the allocatable register superclass?

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170505/99ff53e3/attachment-0001.html>


More information about the llvm-dev mailing list