Original data type after DAG legalization


Is there a way to determine before register allocation if a virtual reg is mapped to the lo or hi part of a piece of a value? Basically i need to tell the register allocator to use a certain set of registers for the lo part and others for the hi part, so in order to do this i would have to know if the data value was expanded into smaller pieces and which piece is each one. Additionally, knowing if the virtual reg assigned to a certain value is not expanded because the value had a legal type would be great.


Hello everybody,

During the past week I’ve kept looking for a solution to this but i couldn’t find one, is there really a way to get this type of information or some workaround?


2010/12/22 Borja Ferrer <borja.ferav@gmail.com>

Hi Borja, you can tell if a type is legal using isTypeLegal. That said, I think
you should explain why you think you need this kind of information. I suspect
that you are taking the wrong approach to solve your underlying problem.

Ciao, Duncan.

Hello Duncan, first thanks for the reply, as requesterd i’ll explain the situation for why i need this sort of information:

The backend im currently writing targets an 8bit MCU (which i hope it gets included in LLVM in the future) that requires some special register constraints. Basically the only legal type is 8bit, so the rest of wider operations get expanded by the legalizer.
When we reach to the register allocator stage things get a bit more complex because we need to meet some constraints. The basic rules are:

(here when i say data type i mean the data type before legalization, since after legalization everything will be 8bits)

  1. if the data type is 8bit (it wasn’t expanded) it can be allocated in any phys reg, so there are no contraints.
  2. if the data type is 16bit (expanded into two 8 bit regs) it has to be allocated in a phys register pair, mapping the lo part into an even phys reg and the hi part into an odd phys reg. In other words, the two allocated registers must be adjacent and the ordering of the pair must be odd:even. So for example:
    R11:R7 is illegal because regs arent adjacent
    R10:R11 is illegal because, although regs are adjacent, the lo part is mapped into an odd reg which is the opposite of what we want.
    R11:R10 is legal, we have adjacent regs and the pair has the order we want, odd mapping the hi part and even mapping the lo part.
  3. wider types follow the same constraints as point 2.

I’ve accomplished storing 16bit or wider data in register pairs using the PBQP register allocator, however, to get the right ordering of the pair (odd:even), if i have two 8bit vitual regs x and y that map a 16 bit value, i need to know which one is mapped into the lo part and which is one is mapped to the hi part so the allocator allocates an even reg to the lo part and an odd to the hi part. Since i dont know a way of getting this sort of information i’m getting unordered pairs because the allocator thinks that the cost of an unordered pair is the same as the cost for an ordered pair.
If i knew that for example reg x is the lo part and reg y is the hi part, i could build the cost matrix for the regalloc according to my constraints, but because i dont know how to get this info currently i’m only getting adjacent regs allocated which is only 50% of my constraints.

In gcc you would use HARD_REGNO_MODE_OK(REGNO, MODE),
in this description you can see it does exactly what im commenting here.

This is basically why i need to get this information, if i’m taking the wrong way please let me know so i can make this work :slight_smile:

Thanks for reading this.