Register class conversions

Is there a simple way to specify the relationship between two different
register classes of various sizes and alignments as being legal to
convert between them?

I have my backend written up using a single register class for i32, i64,
f32 and f64 types, however, because the type information is not
propagated down to the machine instruction register level, it is not
known to me how to determine which data type my current register is. In
working on moving to using 4 separate register classes I ran into the
problem where some of my setup code needs the larger type and not the
smaller type.

So is it possible to have the register class I have setup for i32 type
be automatically converted to the generic register type instead of
aborting?

Micah Villmow

Systems Engineer

Advanced Technology & Performance

Advanced Micro Devices Inc.

4555 Great America Pkwy,

Santa Clara, CA. 95054

P: 408-572-6219

F: 408-572-6596

I don’t get it. What does it mean to “convert” between two register classes? You can move between different register classes.

You mean several types all map to the same register class? Why not specify several classes instead?

Evan

Is there a simple way to specify the relationship between two different
register classes of various sizes and alignments as being legal to
convert between them?

I don't get it. What does it mean to "convert" between two register
classes? You can move between different register classes.

I am somehow hitting patterns where a 64bit load operation has as one of
its arguments the result of a 32 bit comparison. I have conversion
functions that can convert between the 64bit and 32 bit and back. So, if
this situation is detected, can I specify for llvm to insert some sort
of conversion instead of just aborting with:

Register class of operand and regclass of use don't agree!

Operand = 2

Op->Val = 01828560: f64,ch = PTRLOAD_f64 0182B7E0, 0182B4B0, 0182B868,
01828450

MI = %reg1028<def> = CMP_32 41, %reg1027

VReg = 1027

VReg RegClass size = 8, align = 8

Expected RegClass size = 4, align = 4

Fatal error, aborting.

Both of these patterns are matched via tablegen, so I'm not sure how it
is coming to this conclusion. I never ran into this problem when all of
them were the same register class, I just ran into other issues.

I have my backend written up using a single register class for i32, i64,
f32 and f64 types, however, because the type

You mean several types all map to the same register class? Why not
specify several classes instead?

I have many instructions that work irrespective of the data type. By
allowing multiple types to work in a single register class, this reduces
the number of times I have to duplicate code. For, example, I have a
128bit copy that works on i32, i64, f32, f64 data along with vector
types up to 128bits in length. Tablegen should be smart enough to figure
out that if my 128 bit register class has the 32bit and 64 bit register
classes as subclasses, then a pattern written for the 128bit register
class should also work for the sub types. This is standard object
oriented programming. Throw all the common code into a super class and
put data type specific into sub classes. If this is possible, how? If
not, what is stopping tablegen from support this?

Thanks for your time,

Micah

Evan

information is not propagated down to the machine instruction register
level, it is not known to me how to determine which data type my current
register is. In working on moving to using 4 separate register classes I
ran into the problem where some of my setup code needs the larger type
and not the smaller type.

So is it possible to have the register class I have setup for i32 type
be automatically converted to the generic register type instead of
aborting?

Micah Villmow

Systems Engineer

Advanced Technology & Performance

Advanced Micro Devices Inc.

4555 Great America Pkwy,

Santa Clara, CA. 95054

P: 408-572-6219

F: 408-572-6596

That seems like a bug.

That will just cover up the problem.

I don’t think llvm codegen can support this. I think you have to go with a different approach.

Evan