[LLVMdev] Is it possible to tie two defs together?

[Jim Grosbach]

Right. That constraint says that the register for operand “$src1” must be tied to the register used for operand “$dst”.

-Jim

> On Aug 15, 2014, at 1:06 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> 
> Jim,
>  
>   Yes, I believe this is what I'm looking for. I was looking at the x86 INC instruction as an example and this is what they used also. I'm assuming that the 'Constraints' implicitly adds the 'tied' registers?
> 
> Thanks.
> 
> 
> On Fri, Aug 15, 2014 at 4:03 PM, Jim Grosbach <grosbach at apple.com> wrote:
> This sounds like you want a tied operand constraint on the instruction definition. Indexed load/store operations which write back to the base register on ARM/AArch64 have a similar sort of thing, so you might have a look at those. It ends up looking something like,
> 
> let Constraints = “$src1 = $dst” in
> def MyInst: … <(outs GPR:$dst), (ins GPR:$src1, GPR:$src2, GPR:$src3)> …
> 
> That is, you have separate operands, one for the output and one for the input, but the constraint tells regalloc that they’re actually the same in the instruction encoding, so they’ll always be allocated to the same physical register.
> 
> -Jim
> 
> > On Aug 15, 2014, at 11:38 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> >
> > For example, if you have something like:
> >
> > ....
> > vreg3 = LD operation
> > vreg4 = vreg2 * vreg1
> > ...
> >
> > Where I would like vreg3 and vreg4 to map to the same physical register?
> >
> > Imagine that the second instruction has an implicit arithmetic operation tied to vreg 4 such that vreg4 is both an input and output and the initial value of vreg4 is loaded into vreg3, so such that vreg4 = vreg3.
> >
> > Is this possible pre-regalloc?
> >
> > Thanks.
> > _______________________________________________
> > 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/20140815/be6783e7/attachment.html>