[LLVMdev] Register class conversions

[Evan Cheng]

On Oct 23, 2008, at 4:57 PM, Villmow, Micah wrote:

>
>
> On Oct 22, 2008, at 1:28 PM, Villmow, Micah wrote:
>
>
> 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

That seems like a bug.

> 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:

That will just cover up the problem.

> 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

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

Evan

>
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081025/3ea28a16/attachment.html>