[LLVMdev] Help regarding ad new functionality in Backend

[pratik dand]

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>