[llvm-dev] New register class and patterns

[Rail Shafigulin via llvm-dev]

>
> No, this would have to be a void side effecting instruction which is a bit
> different.


 What do you mean by "void side effecting instruction"? I'm not sure I
fully understand what you mean.

The flag register is an implicit register added to the selected
> MachineInstr's operands.


Is this something that is always done by LLVM? Is it me who is telling to
LLVM to do it? I'd appreciate if you could point out where in the code this
is happening.


I've also followed your advice and added i1 as a type for my SPR

def SPR : RegisterClass<"Esencia", [i1,i32], 32, (add SR)> {
  let CopyCost = -1;  // Don't allow copying of special purpose registers.
  let isAllocatable = 0;
}

Then I changed an instruction class to return an explicit value

class SF_RR<bits<5> op2Val, string asmstr, PatLeaf Cond>  :
    InstRR<0x9, (outs), (ins GPR:$rA, GPR:$rB),
                !strconcat(asmstr, "\t$rA, $rB"),
                [(set SPR:$rC, (Esenciasetflag (i32 GPR:$rA), (i32
GPR:$rB), Cond))]> {
  bits<5> op2;
  bits<5> rA;
  bits<5> rB;

  let Inst{25-21} = op2;
  let Inst{20-16} = rA;
  let Inst{15-11} = rB;

  let op2 = op2Val;
}

Naturally LLVM didn't like it. I'm getting stack dumps when I compile it.
I'm assuming this is happening because LLVM is not expecting to see an
explicit output. As far as I understand my options are:

1. Have an instruction return an explicit value, but then I will have to do
a lot of work to change a large chunk of the backend.
2. Continue working with an implicit value being set by an instruction.

I'd like to introduce as little changes as I can. So option 2 seems to be a
reasonable one, however I can't figure out where and what I need to change.
As most people on this list, I'm also learning "on the fly"

I'd really appreciate any help on this.

-- 
Rail Shafigulin
Software Engineer
Esencia Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160205/ecfda8ba/attachment.html>