Displaying 19 results from an estimated 19 matches for "argc_addr".
Did you mean:
agg_addr
2007 Mar 06
6
[LLVMdev] alloca & store generation
...has not
allocated space on the stack for argc and argv. So, I developed my
transformation to change main() from:
-----
int main(int %argc, sbyte** %argv){
entry:
...
// some use of %argc and %argv
...
}
-----
to the following code:
-----
int main(int %argc, sbyte** %argv){
entry:
%argc_addr = alloca int
%argv_addr = alloca sbyte**
store int %argc, int* %argc_addr
store sbyte** %argv, sbyte*** %argv_addr
call void %F ( int %argc_addr, sbyte*** %argv_addr )
%tmp = load int* %argc_addr
%tmp1 = load int* %tmp
...
// the use of %argc and %argv is transformed to use...
2007 Mar 06
0
[LLVMdev] alloca & store generation
...ansformation to change main() from:
>
> -----
> int main(int %argc, sbyte** %argv){
> entry:
> ...
> // some use of %argc and %argv
> ...
> }
> -----
>
> to the following code:
>
> -----
> int main(int %argc, sbyte** %argv){
> entry:
> %argc_addr = alloca int
> %argv_addr = alloca sbyte**
> store int %argc, int* %argc_addr
> store sbyte** %argv, sbyte*** %argv_addr
> call void %F ( int %argc_addr, sbyte*** %argv_addr )
> %tmp = load int* %argc_addr
> %tmp1 = load int* %tmp
> ...
> // the use o...
2010 Mar 09
3
[LLVMdev] Alignment for Alloca Inst in llvm 2.6
...locaInst depend on the
instructions before it in the basic block? The 1st snippet below aligns 'a'
correctly, while the 2nd one doesnt. (the method handle_args, only prints
out the values of arguments, and returns argv unchanged).
define i32 @main(i32 %argc, i8** %argv) nounwind {
entry:
%argc_addr = alloca i32 ; <i32*> [#uses=1]
%argv_addr = alloca i8** ; <i8***> [#uses=2]
%retval = alloca i32 ; <i32*> [#uses=1]
%a = alloca [100 x i32], align 512 ; <[100 x i32]*> [#uses=2]
%0 =...
2009 Nov 16
2
[LLVMdev] lli -force-interpreter complains about external function
...-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"
@.str = private constant [12 x i8] c"hello world\00", align 1 ; <[12 x i8]*>
[#uses=1]
define i32 @main(i32 %argc, i8** %argv) nounwind {
entry:
%argc_addr = alloca i32 ; <i32*> [#uses=1]
%argv_addr = alloca i8** ; <i8***> [#uses=1]
%retval = alloca i32 ; <i32*> [#uses=2]
%0 = alloca i32 ; <i32*> [#uses=2]
%"al...
2007 Dec 25
3
[LLVMdev] Optimization feasibility
...ry:
ret i32 %a3
}
define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
entry:
%tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %
in2, i32 %in1,
i32 %in2 ) ; <i32> [#uses=1]
ret i32 %tmp11
}
define i32 @main(i32 %argc, i8** %argv) {
entry:
%argc_addr = alloca i32 ; <i32*> [#uses=1]
%argv_addr = alloca i8** ; <i8***> [#uses=1]
%retval = alloca i32, align 4 ; <i32*> [#uses=2]
%tmp = alloca i32, align 4 ; <i32*> [#uses=2]
%res = alloca i32, align 4 ; <i32*> [#uses=2]
"alloca point" = bitcast i32 0...
2017 Aug 21
3
DragonEgg for GCC v8.x and LLVM v6.x is just able to work
...st.1, i32 4,
[4 x i8]* @__func__.2210) #1
br label %return
return: ; preds = %"<bb 2>"
ret void
}
declare i32 @printf(i8*, ...)
; Function Attrs: nounwind uwtable
define i32 @main(i32 %argc, i8** %argv) unnamed_addr #0 {
entry:
%argc_addr = alloca i32, align 4
%argv_addr = alloca i8**, align 8
%n = alloca i32
%s = alloca i8*
%"<retval>" = alloca i32
%"alloca point" = bitcast i32 0 to i32
store i32 %argc, i32* %argc_addr, align 1
store i8** %argv, i8*** %argv_addr, align 1
%"ssa...
2007 Mar 06
0
[LLVMdev] alloca & store generation
> Why isn't llvm giving a name to the value returned by the allocas and
> using it in the store instructions?
Because you pass in an empty string for the name in the new AllocaInst
calls below. Replace the empty strings with "argc_addr" or whatever
you want.
> AllocaInst* argc_alloca = new AllocaInst(argc->getType(), "",
> insertNewInstsBefore);
> AllocaInst* argv_alloca = new AllocaInst(argv->getType(), "",
>...
2007 Oct 20
2
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
...2:32-f32:32:32-f64:32:32-v64:64:64-v128:12
8:128-a0:0:64-s0:0:64"
target triple = "arm-softfloat-linux-gnu"
@.str = internal constant [22 x i8] c"hello world: %f / %f\0A\00"
; <[22 x i8]*> [#uses=1]
define i32 @main(i32 %argc, i8** %argv) {
entry:
%argc_addr = alloca i32 ; <i32*> [#uses=1]
%argv_addr = alloca i8** ; <i8***> [#uses=1]
%retval = alloca i32, align 4 ; <i32*> [#uses=1]
%f = alloca float, align 4 ; <float*> [#uses=2]
%"alloca point...
2009 Nov 16
0
[LLVMdev] lli -force-interpreter complains about external function
...4-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
> target triple = "i386-pc-linux-gnu"
>
> @.str = private constant [12 x i8] c"hello world\00", align 1 ; <[12 x
> i8]*> [#uses=1]
>
> define i32 @main(i32 %argc, i8** %argv) nounwind {
> entry:
> %argc_addr = alloca i32 ; <i32*> [#uses=1]
> %argv_addr = alloca i8** ; <i8***> [#uses=1]
> %retval = alloca i32 ; <i32*> [#uses=2]
> %0 = alloca i32 ; <i32*> [#u...
2008 Jan 02
0
[LLVMdev] Optimization feasibility
...ller(i32 %in1, i32 %in2) {
> entry:
> %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %
> in2, i32 %in1,
> i32 %in2 ) ; <i32> [#uses=1]
> ret i32 %tmp11
> }
>
>
>
> define i32 @main(i32 %argc, i8** %argv) {
> entry:
> %argc_addr = alloca i32 ; <i32*> [#uses=1]
> %argv_addr = alloca i8** ; <i8***> [#uses=1]
> %retval = alloca i32, align 4 ; <i32*> [#uses=2]
> %tmp = alloca i32, align 4 ; <i32*> [#uses=2]
> %res = alloca i32, align 4 ; <i32*> [#uses=2]
> "alloca poi...
2007 Oct 19
0
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote:
> hi,
>
> i'm trying to make some experiments with the ARM backend (llvm 2.1)
> and
> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux.
>
> however, the llvm-gcc frontend seems to cause troubles with single
> precision floating point values, i.e., they are not converted
> correctly
> to the
2007 Dec 25
0
[LLVMdev] Optimization feasibility
Hi Jo,
On 2007-12-24, at 14:43, Joachim Durchholz wrote:
> I'm in a very preliminary phase of a language project which requires
> some specific optimizations to be reasonably efficient.
>
> LLVM already looks very good; I'd just like to know whether I can
> push these optimizations through LLVM to the JIT phase (which, as
> far as I understand the docs, is a
2007 Oct 22
0
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
...12
> 8:128-a0:0:64-s0:0:64"
> target triple = "arm-softfloat-linux-gnu"
> @.str = internal constant [22 x i8] c"hello world: %f / %f\0A\00"
> ; <[22 x i8]*> [#uses=1]
>
> define i32 @main(i32 %argc, i8** %argv) {
> entry:
> %argc_addr = alloca i32 ; <i32*> [#uses=1]
> %argv_addr = alloca i8** ; <i8***> [#uses=1]
> %retval = alloca i32, align 4 ; <i32*> [#uses=1]
> %f = alloca float, align 4 ; <float*> [#uses=2]
>...
2007 Oct 19
3
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
hi,
i'm trying to make some experiments with the ARM backend (llvm 2.1) and
therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux.
however, the llvm-gcc frontend seems to cause troubles with single
precision floating point values, i.e., they are not converted correctly
to the particular target format (double precision works as expected).
it seems the problem is related to
2007 Dec 24
3
[LLVMdev] Optimization feasibility
Hi all,
I'm in a very preliminary phase of a language project which requires
some specific optimizations to be reasonably efficient.
LLVM already looks very good; I'd just like to know whether I can push
these optimizations through LLVM to the JIT phase (which, as far as I
understand the docs, is a pretty powerful part of LLVM).
The optimizations that I need to get to work are:
*
2012 Dec 25
2
[LLVMdev] [DragonEgg] Strange call to @"\01__isoc99_fscanf"
...= linker_private constant [2 x i8] c"r\00", align 8
@.cst7 = linker_private constant [27 x i8] c"Cannot open input file
%s\0A\00", align 8
@.cst8 = linker_private constant [3 x i8] c"%d\00", align 8
define i32 @main(i32 %argc, i8** %argv) nounwind uwtable {
entry:
%argc_addr = alloca i32, align 4
%argv_addr = alloca i8**, align 8
%szarray = alloca i64
%wfile = alloca %struct._IO_FILE*
%rfile = alloca %struct._IO_FILE*
%i = alloca i32
%i1 = alloca i32
%val = alloca i32
%"<retval>" = alloca i32
%"alloca point" = bitcast i32 0 t...
2009 Jun 13
4
[LLVMdev] ML types in LLVM
Good afternoon!
I'm trying to write an LLVM codegen for a Standard ML compiler
(MLton). So far things seem to match up quite nicely, but I have hit
two sticking points. I'm hoping LLVM experts might know how to handle
these two cases better.
1: In ML we have some types that are actually one of several possible
types. Expressed in C this might be thought of as a union. The codegen
only
2009 Jan 28
3
[LLVMdev] uses of unwind lead to crashes
...reds = %bb11, %bb10, %bb8, %bb6, %bb4, %bb2, %bb
%27 = call i32 @putchar(i32 10) nounwind ; <i32> [#uses=0]
br label %return
return: ; preds = %bb12
ret void
}
declare i32 @printf(i8*, ...) nounwind
declare i32 @putchar(i32)
define i32 @main(i32 %argc, i8** %argv) nounwind {
entry:
%argc_addr = alloca i32 ; <i32*> [#uses=1]
%argv_addr = alloca i8** ; <i8***> [#uses=1]
%retval = alloca i32 ; <i32*> [#uses=2]
%result = alloca i32 ; <i32*> [#uses=2]
%0 = alloca i32 ; <i32*> [#uses=2]
%"alloca point" = bitcast i32 0 to i32 ; <i32> [#u...
2007 Jul 12
1
[LLVMdev] backend problem with LiveInterval::removeRange
...= load i32* %NUM ; <i32> [#uses=1]
%tmp59 = icmp ne i32 %tmp58, -1 ; <i1> [#uses=1]
%tmp5960 = zext i1 %tmp59 to i8 ; <i8> [#uses=1]
%toBool61 = icmp ne i8 %tmp5960, 0 ; <i1> [#uses=1]
br i1 %toBool61, label %bb, label %bb62
CGP: Found local addrmode: [Base:%argc_addr]
CGP: Found local addrmode: [Base:%argv_addr]
CGP: Found local addrmode: [Base:%argc_addr]
CGP: Found local addrmode: [Base:%argv_addr]
CGP: Found local addrmode: [4 + Base:%tmp4]
CGP: Found local addrmode: [Base:%iftmp.0]
CGP: Found local addrmode: [Base:%iftmp.0]
CGP...