[LLVMdev] Instruction Selection sanity check

[Johnny Val]

On Tue, Sep 2, 2014 at 3:38 PM, Tom Stellard <tom at stellard.net> wrote:
>
> On Tue, Sep 02, 2014 at 11:12:23AM +0100, Johnny Val wrote:
> > Hi,
> >
> > I am working on a new back-end for LLVM. This architecture has two
register
> > types, data(A) and accumulator(B).
> >
> > A registers are i32 where as B registers are i64. This is causing me
some
> > headaches, as far as I can tell, it's not really possible to mix the two
> > using tablegen?
> >
> > In the hardware, every instruction can either take an A register or a B
> > register, in tablegen (as far as I can understand) this is not possible.
> >
> > I ended up creating instructions like
> >
> > MOV32ri (register immediate)
> > MOV32rr (register register)
> > MOV64rr, MOV64ri etc.
> >
> > I've done this for essentially every instruction. This kind of works,
but
> > there are issues.
> >
> > It results in unneeded copies between A registers and B registers. If a
> > value is in an A register and the other is in a B, LLVM will do a copy
> > between registers to make sure both registers are the same "type"(same
> > bank) before doing the operation.
> >
>
> Is it legal to have to mix register classes in an instruction?  For
example,
> ADD AReg, BReg?
>
> If so you will need add more instruction variants e.g.
> ADD3264rr, ADD6432rr.

This is what I attempted to do. I get errors such as:

"Type inference contradiction found, merging 'i32' into 'i64' "

Which is where I got the idea that mixing types in the tablegen
instructions was not allowed.

> > Is there any way around this? Also is it really necessary to define a
> > different instruction for each register type (even though it's the same
> > instruction in hardware, with the same encoding etc).
> >
>
> There is not really a good way around this, but it is not so bad if
> you use multiclasses.
>
> > Another issue is that when multiplying, the result must always be
stored in
> > a B (accumulator register). So I did some custom lowering for the MUL
node,
> > and got the instruction to always write the result to a B register.
> >
>
> How are you defining your MUL instruction?  If you define the MUL
> instruction in tablegen with a B register as destination register,
> then it should always output to a B register.
>

I did do that, and that is indeed what happens. My C++ lowering code, quite
literally, just replaces ISD::MUL nodes with my target specific MUL node. I
leave the pattern empty in the tablegen description of the instruction to
avoid the previously described error. Is this the correct way of solving
this problem?

> -Tom
>
> > The problem is that later on LLVM will move it from a B register to an A
> > register which means the result getting truncated (64 bit -> 32 bit). I
am
> > also unsure how to deal with this.
> >
> > I just want to confirm that I'm doing this somewhat correctly and there
> > isn't a much more obvious and better way of doing this.
> >
> > Kind Regards,
> >
> > Jonathan
>
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Thanks for the help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140902/96d12860/attachment.html>