[LLVMdev] 64 bit special purpose registers

[Ivan Llopard]

Hi Akira, Micah,

On 05/09/2012 21:44, Akira Hatanaka wrote:
> Micah,
>
> Do you mean we should make GPR64 available to register allocator by 
> calling addRegisterClass?
>
> addRegisterClass(MVT::i64, &GPR64RegClass)

I have a related question to this thread. Does the RA use target 
lowering information?
Because if it doesn't, you don't need to register your i64 reg class.

Ivan

>
> If we add register class GPR64, type legalization will stop expanding 
> i64 operations because i64 is now a legal type.
> Then we will probably have to write lots of code to custom-lower 
> unsupported 64-bit operations during legalization. Note that mips32/16 
> lacks support for most of the basic 64-bit instructions (add, sub, etc.).
>
> I don't think setting operation action by calling 
> setOperationAction(... ,MVT::i64, Expand) would work either. Judging 
> from the code I see in Legalize.cpp, operation legalization doesn't 
> seem to do much to expand unsupported i64 operations.
>
> On Tue, Aug 7, 2012 at 9:24 AM, Villmow, Micah <Micah.Villmow at amd.com 
> <mailto:Micah.Villmow at amd.com>> wrote:
>
>     This can be done by declaring a register class with these
>     registers and only using that register class as an operand in the
>     instructions where it is legal.
>     You then set as sub registers what you want to represent as the hi
>     and lo registers for those 64bit registers.
>
>     So something like this:
>     def lo_comp : SubRegIndex;
>     def hi_comp : SubRegIndex;
>     def R1 : Register<1>;
>     def R2 : Register<2>;
>     def R3 : Register<1>;
>     def R4 : Register<2>;
>     def D1 : RegisterWithSubRegs<1, [R1, R2], [lo_comp, hi_comp]>;
>
>     This says that D1 is a register with two components, lo and hi.
>     When you allocate D1, you also use R1/R2.
>     def GPR32 : RegisterClass<..., [i32], [32], (add (sequence "R%u",
>     1, 4))> ...
>     def GPR64 : RegisterClass<..., [i64], [64], (add D1)> ...;
>
>     So in your instruction it would be something like:
>     def mul : Inst<(dst GPR64:$dst), (src GPR32:$src0, GPR32:$src1), ...>;
>
>     This would mean you take in two inputs and you have 64bit output.
>     When D1 is not being used, R1/R2 will get allocated to
>     instructions that use GPR32 register class, otherwise they will be
>     seen as used and not get allocated.
>
>     Hope this helps,
>     Micah
>
>     > -----Original Message-----
>     > From: llvmdev-bounces at cs.uiuc.edu
>     <mailto:llvmdev-bounces at cs.uiuc.edu>
>     [mailto:llvmdev-bounces at cs.uiuc.edu
>     <mailto:llvmdev-bounces at cs.uiuc.edu>]
>     > On Behalf Of reed kotler
>     > Sent: Monday, August 06, 2012 4:52 PM
>     > To: llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>
>     > Subject: [LLVMdev] 64 bit special purpose registers
>     >
>     > On Mips 32 there is traditionally a 64 bit HI/LO register for
>     the result
>     > of multiplying two 64 bit numbers.
>     >
>     > There are corresponding instructions to load the LO and HI parts
>     into
>     > individual 32 registers.
>     >
>     > On Mips with the DSP ASE (an application specific extension),
>     there are
>     > actual 4 such pairs of registers.
>     >
>     > Is there a way to have special purpose 64 bit registers without
>     actually
>     > having to tell LLVM that you have a 64 bit processor?
>     >
>     > But it's still possible to use the individual parts of the 64
>     register
>     > as temporaries.
>     >
>     > The only true 64 bit operation is multiplying two 32 bit numbers.
>     >
>     >
>     > _______________________________________________
>     > LLVM Developers mailing list
>     > LLVMdev at cs.uiuc.edu <mailto: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 <mailto: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/20120906/ff2c2770/attachment.html>