[LLVMdev] FW: Register classes, reg unit weights calculation in tablegen

Jonas Paulsson jonas.paulsson at ericsson.com
Tue Dec 11 00:33:40 PST 2012


To: Andrew Trick

Hi,

I write you directly as you are the commiter of the code I am having problems with for my target - see below. I wonder what you think about this?

Thanks,

Jonas

________________________________
From: Jonas Paulsson
Sent: Thursday, December 06, 2012 4:14 PM
To: llvmdev at cs.uiuc.edu
Subject: Register classes, reg unit weights calculation in tablegen

Hi,

I have a problem with the assert in Tablegen:

llvm-tblgen: /dev/shm/uabpath/dev-master/utils/TableGen/RegisterInfoEmitter.cpp:204: void <anonymous namespace>::RegisterInfoEmitter::EmitRegUnitPressure(llvm::raw_ostream &, const llvm::CodeGenRegBank &, const std::string &): Assertion `RU.Weight < 256 && "RegUnit too heavy"' failed.

The reason for this is that I have constructed pred-operands to be of the register class type FlagRegs, which holds a big union of classes, so that I can generate code like

Cmp %1:RC1, 0
Brr   #bb, if  EQ:%1

Cmp %2:RC2, 0
Brr   #bb, if  EQ:%2

, where RC1 and RC2 (and others as well not shown here) both share common sub-registers, but are of different widths. This construct makes it easy to predicate instructions, no matter what register is used and of which width, and so on. (The architecture has several flag registers tied to various registers).

The problem is that extremely huge values for reg unit weights result in tablegen. I suspect a circular propagation of weights, due to these common sub/super reg-classes.

static const RegClassWeight RCWeightTable[] = {
{4294967295, 4294967288}, // FlagRegs
...

Does anyone have a suggestion of how to get around this problem? It would be a big task to rewrite the instructions to have different types of pred-operands depending of used CCReg, etc. Could perhaps the unit weight calculation be fixed to handle more intricate cases like this? Who could I work with on this in this case?

Thanks,

Jonas Paulsson


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121211/262df18f/attachment.html>


More information about the llvm-dev mailing list