Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] IMUL x86 instruction"
2012 Sep 13
5
[LLVMdev] [OT] Control Flow Graph(CFG) into Abstract Syntax Tree(AST)
Hi,
I know most compilers go from AST to CFG.
I am writing a decompiler, so I was wondering if anyone knew of any
documents describing how best to get from CFG to AST.
The decompiler project is open source.
https://github.com/jcdutton/libbeauty
The decompiler already contains a disassembler and a virtual machine
resulting in an annotated CFG. It uses information gained from using a
virtual
2012 May 07
6
[LLVMdev] Using LLVM for decompiling.
Hi,
I am writing a decompiler. I was wondering if some of LLVM could be
used for a decompiler.
There are several stages in the decompiler process.
1) Take binary and create a higher level representation of it. Like RTL.
2) The output is then broken into blocks or nodes, each block ends in
a CALL, JMP, RET, or 2-way or multiway conditional JMP.
3) The blocks or nodes are then analyzed for
2012 May 07
6
[LLVMdev] Using LLVM for decompiling.
On 7 May 2012 16:31, John Criswell <criswell at illinois.edu> wrote:
> On 5/7/12 5:47 AM, James Courtier-Dutton wrote:
>>
>> Hi,
>>
>> I am writing a decompiler. I was wondering if some of LLVM could be
>> used for a decompiler.
>> There are several stages in the decompiler process.
>> 1) Take binary and create a higher level representation of it.
2012 May 07
0
[LLVMdev] Using LLVM for decompiling.
On 5/7/12 5:47 AM, James Courtier-Dutton wrote:
> Hi,
>
> I am writing a decompiler. I was wondering if some of LLVM could be
> used for a decompiler.
> There are several stages in the decompiler process.
> 1) Take binary and create a higher level representation of it. Like RTL.
> 2) The output is then broken into blocks or nodes, each block ends in
> a CALL, JMP, RET, or
2012 May 07
0
[LLVMdev] Using LLVM for decompiling.
> -----Original Message-----
> On Behalf Of James Courtier-Dutton
> To: John Criswell
>
> On 7 May 2012 16:31, John Criswell <criswell at illinois.edu> wrote:
> > On 5/7/12 5:47 AM, James Courtier-Dutton wrote:
> >>
> >> Hi,
> >>
> >> I am writing a decompiler. I was wondering if some of LLVM could be
> >> used for a
2013 Jun 28
3
[LLVMdev] Question regarding the x86 SBB instruction.
Hi,
I have the x86 SBB instruction. how should I represent this in LLVM
IR. (as part of a decompiler from binary to LLVM IR)
Pre-conditions:
%eax = 0xffffffff
%edx = 0xffffffff
%carry = 1
SBB %eax, %edx // %edx is the destination doing %edx = %edx -
(%eax + carry)
JC jump_destination1 // If the Carry flag is set, jump to jump_destination1
How do I represent this correctly in LLVM
2013 Apr 21
2
[LLVMdev] Testing methods
Hi,
What does llvm use for testing.
The area of testing I am interested in are how to test the accuracy of
the assembler/disassembler.
So, if you take an IR level instruction. How do you verify that the
generated CPU specific instruction is correct?
Is there an automated method for this?
I wish to implement automated testing on a decompiler I am writing,
and thought that the test methods used in
2013 Jun 28
0
[LLVMdev] Question regarding the x86 SBB instruction.
Look at the __builtin_addc* builtins in clang. I am currently working on an optimization which transforms said intrinsics into chains of ADCs/SBBs.
Michael
On Jun 28, 2013, at 5:51 AM, James Courtier-Dutton <james.dutton at gmail.com> wrote:
> Hi,
>
> I have the x86 SBB instruction. how should I represent this in LLVM
> IR. (as part of a decompiler from binary to LLVM IR)
2012 Sep 21
0
[LLVMdev] [OT] Control Flow Graph(CFG) into Abstract Syntax Tree(AST)
Hi,
Simon Moll (in CC) has written a decompiler for LLVM in his Bachelor's
Thesis here at Saarland University. The thesis is titled "Decompilation
of LLVM IR" and can be found here:
http://www.cdl.uni-saarland.de/publications/
The library he implemented is called "Axtor" (for "AST Extractor") and
has been used primarily to generate OpenCL code from LLVM. In
2012 May 07
0
[LLVMdev] Using LLVM for decompiling.
On 5/7/2012 11:45 AM, James Courtier-Dutton wrote:
> On 7 May 2012 16:31, John Criswell<criswell at illinois.edu> wrote:
>> Given that you've completed steps one and two (i.e., you've converted the
>> binary instructions to LLVM IR and then discovered basic blocks), then yes,
>> LLVM's current analysis passes should help you with this third step. LLVM
2018 Dec 01
2
Where's the optimiser gone? (part 5.c): missed tail calls, and more...
Compile the following functions with "-O3 -target i386-win32"
(see <https://godbolt.org/z/exmjWY>):
__int64 __fastcall div(__int64 foo, __int64 bar)
{
return foo / bar;
}
On the left the generated code; on the right the expected,
properly optimised code:
push dword ptr [esp + 16] |
push dword ptr [esp + 16] |
push dword ptr [esp + 16] |
2012 Sep 21
1
[LLVMdev] [OT] Control Flow Graph(CFG) into Abstract Syntax Tree(AST)
On 21 September 2012 09:51, Ralf Karrenberg <Chareos at gmx.de> wrote:
> Hi,
>
> Simon Moll (in CC) has written a decompiler for LLVM in his Bachelor's
> Thesis here at Saarland University. The thesis is titled "Decompilation of
> LLVM IR" and can be found here:
> http://www.cdl.uni-saarland.de/publications/
>
> The library he implemented is called
2018 Dec 01
2
Where's the optimiser gone? (part 5.b): missed tail calls, and more...
Compile the following functions with "-O3 -target i386"
(see <https://godbolt.org/z/VmKlXL>):
long long div(long long foo, long long bar)
{
return foo / bar;
}
On the left the generated code; on the right the expected,
properly optimised code:
div: # @div
push ebp |
mov ebp, esp |
push dword ptr [ebp + 20] |
push
2015 Dec 17
2
llvm-3.6 MCAsmParser x64 Error "invalid operand for instruction" when msb set
Hello,
I am experiencing problems, when trying to assemble these two x86-64 Opcodes
"add r64, imm32"
"imul r64, r64, imm32"
When having the most significant bit set for imm32, for example:
"add rax, 0x80000000", "add rax, 0xffffffff", ...
"imul rbx, rsi, 0x80000000", "imul rbx, rsi, 0xffffffff", ...
The Error Message I receive is the
2014 Oct 24
3
[LLVMdev] IndVar widening in IndVarSimplify causing performance regression on GPU programs
Hi,
I noticed a significant performance regression (up to 40%) on some internal
CUDA benchmarks (a reduced example presented below). The root cause of this
regression seems that IndVarSimpilfy widens induction variables assuming
arithmetics on wider integer types are as cheap as those on narrower ones.
However, this assumption is wrong at least for the NVPTX64 target.
Although the NVPTX64 target
2012 Apr 04
4
[LLVMdev] GSoC Proposal: Table-Driven Decompilation
Hi,
Here's one of my proposals for GSoC 2012. What do you think?
Chip
Project Title: Table-Driven Decompilation
Abstract:
Over the years, the LLVM family has grown to include nearly every type of build tool in existence. One of the few missing is a decompiler. LLVM's TableGen tool could potentially accelerate development of such a tool; most backends already have the information needed
2014 Apr 03
2
[LLVMdev] decompiler
On Thu, Apr 3, 2014 at 11:50 AM, Jevin Sweval <jevinsweval at gmail.com> wrote:
> On Wed, Apr 2, 2014 at 1:57 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote:
>> Hi -
>>
>> Not sure if anyone else saw this or cares about a decompiler (not personally
>> tested)
>> https://github.com/draperlaboratory/fracture
>>
>> I wonder if
2020 May 12
2
BPF tablegen+codegen question
In BPF, an ADD instruction is defined as a 2 register instruction:
0x0f. add dst, src. dst += src
In BPFInstrInfo.td this kind of ALU instruction is defined with:
def _rr : ALU_RR<BPF_ALU64, Opc,
(outs GPR:$dst),
(ins GPR:$src2, GPR:$src),
"$dst "#OpcodeStr#" $src",
[(set
2005 Feb 22
0
[LLVMdev] Area for improvement
On Mon, 21 Feb 2005, Jeff Cohen wrote:
> I noticed that fourinarow is one of the programs in which LLVM is much slower
> than GCC, so I decided to take a look and see why that is so. The program
> has many loops that look like this:
>
> #define ROWS 6
> #define COLS 7
>
> void init_board(char b[COLS][ROWS+1])
> {
> int i,j;
>
> for
2013 Mar 12
4
[LLVMdev] help decompiling x86 ASM to LLVM IR
On 12 March 2013 16:39, Óscar Fuentes <ofv at wanadoo.es> wrote:
>
> This is not possible, except for specific cases.
>
> Consider this code:
>
> long foo(long *p) {
> ++p;
> return *p;
> }
>
> The X86 machine code would do something like
>
> add %eax, 4
>
> for `++p', but for x86_64 it would be
>
> add %rax, 8
>
> But you