Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] Removing function params."
2013 Oct 22
0
[LLVMdev] LLVMdev Digest, Vol 112, Issue 59
On Oct 22, 2013, at 1:29 PM, llvmdev-request at cs.uiuc.edu wrote:
> Send LLVMdev mailing list submissions to
> llvmdev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> or, via email, send a message with subject or body 'help' to
> llvmdev-request at cs.uiuc.edu
>
> You can
2018 Apr 13
1
LLVM function parameters
Hi,
When using the LLVM IR builder, I have a situation that might have 5
parameters when building the function nodes and instructions.
Later on, I wish to remove one of the parameters so the same function
now has only 4 parameters. For example, the parameter may not actually
be used by any of the instructions in the function.
How do I remove a parameter from the function?
I am hoping that there
2013 Sep 15
2
[LLVMdev] LLVM disassembler bugs
The attached patch includes no test-case and isn't consistent with the rest
of the file:
- constants should be on the right hand side of comparisons
- the braces around your single line 'if' aren't needed.
On Sun, Sep 15, 2013 at 2:39 PM, James Courtier-Dutton <
james.dutton at gmail.com> wrote:
> I attach a patch that fixes this bug. Applies to llvm 3.4svn
>
>
2013 Sep 13
3
[LLVMdev] LLVM disassembler bugs
Hi,
I am looking at the "LLVMOpInfoCallback GetOpInfo" callback.
Example 1 GOOD:
41 c6 84 24 16 04 00 00 0c : movb $12, 1046(%r12)
Makes calls to the callback with:
Offset = 0x4, Size = 0x4 <- Octets: 16 04 00 00
Offset = 0x8, Size = 0x1 <- Octets: 0c
That was correct.
Example 2 BAD:
c7 45 98 a1 ff ff ff : movl $4294967201, -104(%rbp)
Makes calls to the callback
2013 Sep 15
0
[LLVMdev] LLVM disassembler bugs
Test case attached. It is not a test case that works within the llvm
test-suite yet, but it does demonstrate the problem.
I would like some advice on how to modify this test_case so that it can be
added to the automated llvm test cases.
On 15 September 2013 23:02, David Majnemer <david.majnemer at gmail.com> wrote:
> The attached patch includes no test-case and isn't consistent
2013 Mar 15
6
[LLVMdev] Simple question
Hi,
I think this is a very simple question, and it must just be missing something.
I am looking for find out how to assign a constant integer value to
the variable in llvm ir.
The following returns 12, and %var2 = 12.
; ModuleID = 't.c'
target datalayout =
2013 Mar 16
3
[LLVMdev] Simple question
On Mar 15, 2013 10:53 PM, "Óscar Fuentes" <ofv at wanadoo.es> wrote:
>
> James Courtier-Dutton <james.dutton at gmail.com> writes:
>
> > I think this is a very simple question, and it must just be missing
something.
> >
> > I am looking for find out how to assign a constant integer value to
> > the variable in llvm ir.
> >
> > The
2019 May 06
3
RFC: On removing magic numbers assuming 8-bit bytes
On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Although the above is mentioning bytes, looking at the "/ 8" and "& 0x7" makes it look like the author meant octets and not bytes.
> Bytes can be any size of bits.
I don't think you'll have much luck trying to make that stick for a
general audience,
2013 Sep 15
0
[LLVMdev] LLVM disassembler bugs
I attach a patch that fixes this bug. Applies to llvm 3.4svn
Please commit it please.
Kind Regards
James
On 13 September 2013 17:46, James Courtier-Dutton <james.dutton at gmail.com>wrote:
> Hi,
>
> I am looking at the "LLVMOpInfoCallback GetOpInfo" callback.
>
> Example 1 GOOD:
> 41 c6 84 24 16 04 00 00 0c : movb $12, 1046(%r12)
>
> Makes
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 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
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
2017 Apr 16
2
[LLVMdev] Moving towards a singular pointer type
On Sun, Apr 16, 2017 at 2:34 AM James Courtier-Dutton via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> Did this work ever get done? There was a long thread about it back in 2015.
>
> I wish to use IRBuilder.
> Is there any documentation?
> How do I use the singular pointer type in GEP, LOAD, STORE instructions?
>
Sorry, no, the work is not complete - for
2013 Oct 29
2
[LLVMdev] Missed optimization opportunity with piecewise load shift-or'd together?
On Mon, Oct 28, 2013 at 10:09 AM, James Courtier-Dutton
<james.dutton at gmail.com> wrote:
> My guess is that this is a missed optimization, but in real life, all
> projects i have worked fix this in the C or C++ code using macros that
> change what instructions are used based on target platform and its
> endedness.
One reason for writing code like this, i.e. explicitly spelling
2013 Mar 12
6
[LLVMdev] help decompiling x86 ASM to LLVM IR
Hi,
I am looking to decompile x86 ASM to LLVM IR.
The original C is this:
int test61 ( unsigned value ) {
int ret;
if (value < 1)
ret = 0x40;
else
ret = 0x61;
return ret;
}
It compiles with GCC -O2 to (rather cleverly removing any branches):
0000000000000000 <test61>:
0: 83 ff 01 cmp $0x1,%edi
3:
2020 Jun 30
2
How to prevent llvm's default optimization
Hi, James,
Thanks for your reply.
I do not think it is always true, that "mul then add" is faster than "add then mul".
For example,
A small immediate can be directly encoded in the instruction, but it becomes a larger one after a multiplication, which has to be loaded from the constant pool (extra memory access).
So I wonder, is it possile to prevent it, via changes
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
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
2020 May 03
2
LLVM type.h question
Hi,
I see this in the Type class:
unsigned getSubclassData() const { return SubclassData; }
void setSubclassData(unsigned val) {
SubclassData = val;
// Ensure we don't have any accidental truncation.
assert(getSubclassData() == val && "Subclass data too large for field");
}
How will the assert ever get triggered?
The type is "unsigned" so how can
2020 Apr 16
2
Various Intermediate Representations. IR
On Wed, 15 Apr 2020 at 17:28, David Blaikie <dblaikie at gmail.com> wrote:
>
> opaque pointers don't exist in the IR yet - the goal is to reduce the places that use non-opacity of pointer types already/today and then opacify the existing pointer type, rather than introducing an opaque pointer type & having it concurrently with non-opaque pointer types. (though in retrospect