search for: nojb

Hello, I am running a i7 MacBook Pro 2011. If I write: @g = global double 0.000000e+00 define i32 @main() { entry: %0 = load double* @g %1 = fmul double 1.000000e+06, %0 store double %1, double* @g ret i32 0 } in test.ll and I run > llc test.ll > gcc test.s I get: test.s:12:no such instruction: `vmovsd _g(%rip), %xmm0' test.s:13:no such instruction: `vmulsd LCPI0_0(%rip),

On Fri, Mar 18, 2011 at 4:23 PM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi Eli, > > I'm using 2.8. Ouch; too late to fix 2.8 :(. If you can, use trunk or the 2.9 branch instead. Otherwise, passing -mattr=-avx to llc should do the trick. -Eli > On Mar 18, 2011, at 6:50 PM, Eli Friedman wrote: > >> On Fri, Ma...

On Wed, Apr 6, 2011 at 10:48 PM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi, > > Is this correct behaviour? > > test.ll: > > declare {} @__ex__print_int(i64) > > define i32 @main() { > entry: >  %0 = call i64 @f.1() >  %1 = call {} @__ex__print_int(i64 %0) >  ret i32 0 > } > > define intern...

On Mon, Aug 15, 2011 at 9:01 AM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi, > > When calling a function, does the llvm code generator support passing structured types (arrays, structs, etc.) by _value_? I wrote some small examples, and it seemed > to work, but I was wondering if anything can go wrong if the structured types...

Hi, Is this correct behaviour? test.ll: declare {} @__ex__print_int(i64) define i32 @main() { entry: %0 = call i64 @f.1() %1 = call {} @__ex__print_int(i64 %0) ret i32 0 } define internal fastcc i64 @f.1() { entry: ret i64 7 } > opt -std-compile-opts test.ll -S ; ModuleID = 'test.ll' define i32 @main() noreturn nounwind { entry: tail call void @llvm.trap()

Hi, When calling a function, does the llvm code generator support passing structured types (arrays, structs, etc.) by _value_? I wrote some small examples, and it seemed to work, but I was wondering if anything can go wrong if the structured types are very large... Thanks, N

Hi, Is it necessary to emit all the calls to @llvm.gcroot in the entry block of each function, or can I emit them anywhere on the function? Thanks, N

Hello, This is a little off-topic. But I am writing a compiler to llvm ir for a language that admits recursive nested functions and am stuck as to how to translate them. Concretely, I'm trying to lift them all to the topmost level and pass all their free variables explicitly as arguments. To do this, I have to determine all their free variables in their bodies. In particular when I come

Hello, I'm trying to use Llvm_bitwriter + ocamlbuild, but it doesn't recognize its dependency on Unix, so it doesn't compile. Minimal case: (* FILE: minimal.ml *) let main () = let m = Llvm.create_module (Llvm.global_context ()) "test" in ignore (Llvm_bitwriter.output_bitcode stdout m) ;; main () (* FILE: _tags *) <*.{byte,native}>: g++, use_unix, use_llvm,

Hi, I'm trying to start using gc with llvm, and was trying to get started with the shadow-stack plugin. I'm having trouble putting everything together, even in this simple case. My compiler generates the necessary gcroot instructions and for now I would be glad just being able to walk through the roots and print out some numbers. For example, I have the following my.ll file: my.ll:

Hi, Some time ago, I reported a bug (PR# 9686) involving gcroot, and the shadow-stack. I don't understand enough of the low-level details to understand what's going on, but I'm still interested in using the shadow-stack. Is there a way to circumvent the problem reported in PR# 9686? Thanks! N

Hi, I have been trying all day long to get the following 5 line file to compile: test.ll: declare void @llvm.gcroot (i8**, i8*) define i32 @main() gc "shadow-stack" { entry: %0 = alloca i8* %1 = call i8* @malloc(i64 10) store i8* %1, i8** %0 call void @llvm.gcroot(i8** %0, i8* null) ret i32 0 } declare i8* @malloc (i64) If I do > llc test.ll I get ld: in

Hi, Compiling a simple function with the 3.0 SVN branch llc produces .s output containing cfi_startproc, cfi_endproc, cfi_def_cfa_offset that gcc refuses to compile (OS X 10.7 on X86-64) with the following error: test.s:6:Unknown pseudo-op: .cfi_startproc test.s:10:Unknown pseudo-op: .cfi_def_cfa_offset test.s:10:Rest of line ignored. 1st junk character valued 51 (3). test.s:38:Unknown

Hello, Is tail call optimization performed if the ret instruction does not actually follow the tail call? Not according to the documentation, but in examples it seems to work. For example, consider the following definition of Ackerman's function in ML (it has two tail calls): let rec ack x y = if x <= 0 then y + 1 else if y <= 0 then ack (x - 1) 1 else ack (x - 1) (ack x (y -

Hi, Question 1: Will the new type system allow to incrementally build structs (instead of filling all the fields in one go, as in the example given in <http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt>? Question 2: Will the ocaml bindings to be updated to work with the new type system once the merging of the rewrite to the main branch is done? Thanks very much, N

Hi, If I type define i32 @main() gc "shadow-stack" { entry: %0 = alloca i8* %1 = call i8* @malloc(i64 1) store i8* %1, i8** %0 call void @llvm.gcroot(i8** %0, i8* null) ret i32 0 } declare i8* @malloc(i64) declare void @llvm.gcroot(i8**, i8*) nounwind in test.ll and then do > llc test.ll > gcc test.s I get the error ld: in