llvm dev - Sep 2015 - Rewriting LLVM IR intrinsic functions

On 14 Sep 2015, at 06:58, Dipanjan Das via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> Hi David,
> 
> I think you people can help me better if I explain what I am trying to
achieve.
> 	• I have compiled gmp with LLVM 2.9
> 	• Linked the library statically with a stub program (gmp_demo.bc)
> 	• Transformed the bitcode to LLVM IR: llvm-dis gmp_demo.bc -o gmp_demo.ll
> 	• Trying to convert the IR to high-level C code: llc -march=c gmp_demo.ll 
> Though I know that llc C backend has many issues and has been removed from
LLVM >=3.1, still I am desperate to make it work. The error I receive in the
last step is the following: "LLVM ERROR: Code generator does not support
intrinsic function 'llvm.uadd.with.overflow.i64'!"
> 
> I was planning to rewrite LLVM intrinsics not supported by llc to
equivalent LLVM IR supported by llc. Is this approach feasible?
It would still help to understand exactly why you’re trying to do this.  It
sounds as if you’re using LLVM as a source-to-source translator, with C as the
input and output language.  If this is the case, then the Clang rewriter
infrastructure might be more useful to you.

The intrinsic that it is currently failing on is (as its name implies) an
overflow-checked addition.  The reason that the C backed does not understand
this builtin is simple: There is no way of (directly) expressing this in C,
without extensions.

You could potentially expand this in IR to a signed addition and a check that
the sign bit had not changed, but it would be cleaner to simply modify the C
backend to emit the Clang / GCC __builtin function that corresponds to the
intrinsic.  You’re likely to find a number of other intrinsics that are not
supported: the reason that the C backend was removed was that it never worked
very well.  For example, anything involving exceptions can’t be implemented in
C, so the C backend lowers it to setjmp / longjmp, which gives you a different
ABI.

David

Hi David,

On 14 September 2015 at 16:25, David Chisnall <David.Chisnall at
cl.cam.ac.uk>
wrote:
> On 14 Sep 2015, at 06:58, Dipanjan Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> >
> > Hi David,
> >
> > I think you people can help me better if I explain what I am trying to
> achieve.
> >       • I have compiled gmp with LLVM 2.9
> >       • Linked the library statically with a stub program
(gmp_demo.bc)
> >       • Transformed the bitcode to LLVM IR: llvm-dis gmp_demo.bc -o
> gmp_demo.ll
> >       • Trying to convert the IR to high-level C code: llc -march=c
> gmp_demo.ll
> > Though I know that llc C backend has many issues and has been removed
> from LLVM >=3.1, still I am desperate to make it work. The error I
receive
> in the last step is the following: "LLVM ERROR: Code generator does
not
> support intrinsic function 'llvm.uadd.with.overflow.i64'!"
> >
> > I was planning to rewrite LLVM intrinsics not supported by llc to
> equivalent LLVM IR supported by llc. Is this approach feasible?
>
> It would still help to understand exactly why you’re trying to do this.
> It sounds as if you’re using LLVM as a source-to-source translator, with C
> as the input and output language.  If this is the case, then the Clang
> rewriter infrastructure might be more useful to you.
>
>
I have started working on automatic program repair where I need to work
with a binary with source code unknown to us. May be using an in-house
tool, I can lift off the binary to LLVM IR. I was planning to transform
LLVM IR to equivalent high-level C code to try source code fixing
approaches on the same.


> The intrinsic that it is currently failing on is (as its name implies) an
> overflow-checked addition.  The reason that the C backed does not
> understand this builtin is simple: There is no way of (directly) expressing
> this in C, without extensions.
>
> You could potentially expand this in IR to a signed addition and a check
> that the sign bit had not changed, but it would be cleaner to simply modify
> the C backend to emit the Clang / GCC __builtin function that corresponds
> to the intrinsic.  You’re likely to find a number of other intrinsics that
> are not supported: the reason that the C backend was removed was that it
> never worked very well.  For example, anything involving exceptions can’t
> be implemented in C, so the C backend lowers it to setjmp / longjmp, which
> gives you a different ABI.
>

-- 

Thanks & Regards,
Dipanjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150914/c6aa4b98/attachment.html>

On 14 Sep 2015, at 09:36, Dipanjan Das via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I have started working on automatic program repair where I need to work
with a binary with source code unknown to us. May be using an in-house tool, I
can lift off the binary to LLVM IR. I was planning to transform LLVM IR to
equivalent high-level C code to try source code fixing approaches on the same.
If you convert from binary to LLVM IR, then from LLVM IR to source code, the
source code that you get out will look nothing like the original, so there is no
chance that your changes would be useful when applied to the original sources. 
This sort of transformation would be better done in the LLVM IR (a
representation designed for transformation), rather than in generated source
code (a representation designed for human editing).

David