pratik dand
2014-Jun-11 08:30 UTC
[LLVMdev] Help regarding ad new functionality in Backend
Dear, I am looking at the Instructions defined in the XXXXInstrInfo.td where I can see a def record defined like below def ADD8rr : I8rr<0x0, (outs GR8:$dst), (ins GR8:$src, GR8:$src2), "add.b\t{$src2, $dst}", [(set GR8:$dst, (*add *GR8:$src, GR8:$src2)), (implicit SRW)]>; Now here I would like the to replace the add(highlighted) by an arbitrary function say 'foo' (foo will use already defined functions. For eg. foo could be the gcd function evaluating the gcd of two operands and likewise). Note: gcd is just an example. How can this be achieved? -- Pratik -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140611/06825cd1/attachment.html>
Tim Northover
2014-Jun-11 09:02 UTC
[LLVMdev] Help regarding ad new functionality in Backend
Hi Pratik On 11 June 2014 09:30, pratik dand <pratikdand143 at gmail.com> wrote:> Note: gcd is just an example.gcd is very difficult, because an implementation in terms of LLVM primitive nodes involves control flow. For that one, I'd create an "@llvm.mytarget.gcd" intrinsic, and spot it earlier somehow (possibly with an IR-level pass). For simpler cases, this is just what PatFrag was created for. For example, AArch64 has an add that sign extends both its arguments before doing the addition, so we can write: def extending_add : PatFrag<(ops node:$LHS, node:$RHS), (add (sext node:$LHS), (sext node:$RHS))>; and then use this in the pattern as normal: [(set GPR64:$Rd, (extending_add GPR32:$Rn, GPR32:$Rm))] what happens is TableGen pastes the definition of the PatFrag "(add (sext ...), ...)" into the pattern where we've written extending_add. It's mostly as if we'd written the "(add (sext ...), ...)" one ourselves. This only works within a single basic block though, and has some slight edge-cases around type-inference that can be annoying. Cheers. Tim.
pratik dand
2014-Jun-11 10:32 UTC
[LLVMdev] Help regarding ad new functionality in Backend
Dear Tim, Just to make myself clear. I am looking for making a tool that can give me machine code only (not execute the program on my CPU). I am interested in converting the .c to .s (.o) where .s (.o) has the assembly language instructions (machine code). With respect to the example you mention, I will be having a CPU that can execute the sign extended addition as an instruction and its decomposition to add and sext won't be required. Since, I will be having a CPU with such capabilities, do i still need to such things? Regards. Pratik On Wed, Jun 11, 2014 at 5:02 PM, Tim Northover <t.p.northover at gmail.com> wrote:> Hi Pratik > > On 11 June 2014 09:30, pratik dand <pratikdand143 at gmail.com> wrote: > > Note: gcd is just an example. > > gcd is very difficult, because an implementation in terms of LLVM > primitive nodes involves control flow. For that one, I'd create an > "@llvm.mytarget.gcd" intrinsic, and spot it earlier somehow (possibly > with an IR-level pass). > > For simpler cases, this is just what PatFrag was created for. For > example, AArch64 has an add that sign extends both its arguments > before doing the addition, so we can write: > > def extending_add : PatFrag<(ops node:$LHS, node:$RHS), (add (sext > node:$LHS), (sext node:$RHS))>; > > and then use this in the pattern as normal: > > [(set GPR64:$Rd, (extending_add GPR32:$Rn, GPR32:$Rm))] > > what happens is TableGen pastes the definition of the PatFrag "(add > (sext ...), ...)" into the pattern where we've written extending_add. > It's mostly as if we'd written the "(add (sext ...), ...)" one > ourselves. This only works within a single basic block though, and has > some slight edge-cases around type-inference that can be annoying. > > Cheers. > > Tim. >-- Pratik -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140611/19208d64/attachment.html>