llvm dev - Jun 2014 - [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>

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.

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>