search for: woodyatt

...code generation, but by bundling LLVM with the GHC sources, they'll be able to remove a whole passle of Perl and GCC-related crawling horrors. They're hoping to get some performance improvements out of the migration. Let us all now give a warm welcome to our new Haskell comrades! — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...> make: *** [all-gcc] Error 2 Any tips that lead to the isolation of this issue will be graciously accepted. If I figure this out, I'll report back here what I'm doing wrong. If I don't, then I will probably bag on compiling libgcc2 for now and come back to it later. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

everyone-- Maybe I'm missing it, but I don't see how to apply parameter attributes to function return types in either the C-language or OCaml bindings. Can anybody help clue me in? Thanks. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

On Mar 1, 2010, at 09:56, james woodyatt wrote: > On Mar 1, 2010, at 04:43, Duncan Sands wrote: >> >> Where exactly? I don't see it in the online version. > > See <http://llvm.org/docs/LangRef.html#t_function> and look at the second example: > > float (i16 signext, i32 *) * > > Pointer to...

...lic-api-list=_start. I suppose I'll end up ripping off bcopy.s for ARM from the obvious place, and assembling that for use in the final link. That should solve my problem. I mention it here because it was a little surprising when my memcpy() didn't show up where I expected. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...| Inreg @@ -129,6 +134,15 @@ | Nest | Readnone | Readonly + | Noinline + | Alwaysinline + | Optforsize + | Stackprotect + | Stackprotectreq + | Nocapture + | Noredzone + | Noimplicitfloat + | Naked end (** The predicate for an integer comparison ([icmp]) instruction. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...rning float. Hence, my confusion over the issue. If parameter attributes aren't included in function types, then I'd like to know how to call a function through a pointer of the type in the example above. I must be failing still to comprehend an important concept in the language. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

On Dec 27, 2009, at 11:41 AM, james woodyatt wrote: > everyone-- > > The OCaml bindings need help again. Please attach this as a .patch file and I'd be happy to apply it for you, -Chris > > diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml > --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml...

On Dec 27, 2009, at 21:23, Chris Lattner wrote: > On Dec 27, 2009, at 11:41 AM, james woodyatt wrote: >> >> The OCaml bindings need help again. > > Please attach this as a .patch file and I'd be happy to apply it for you, I hope I composed this patch file properly. Let me know if I need to try again. -------------- next part -------------- A non-text attachment w...

everyone-- I notice that Llvm.llvm_handle_to_type is actually defined to create a type handle from a type, rather than vice versa as its name would imply. Should I send a patch to change the name of the function to reflect its type better, or should I just lump it? — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

On Mar 1, 2010, at 20:28, Eli Friedman wrote: > On Mon, Mar 1, 2010 at 8:20 PM, james woodyatt <jhw at conjury.org> wrote: >> I'm sorry to pester about this, but I was really hoping somebody could straighten me out about this. The Language Reference really does seem to be ambiguous about this, and I'm willing to compose a patch to fix it, but I need to know what the docu...

On Mar 10, 2010, at 21:33, james woodyatt wrote: > > Maybe I'm missing it, but I don't see how to apply parameter attributes to function return types in either the C-language or OCaml bindings. Can anybody help clue me in? Thanks. I hope I can assume from the lack of response to my question that the answer is No, I'm...

james woodyatt wrote: > everyone-- > > I don't know whether this is a bug or not. I assume you're using llvm-gcc? Does it still turn memcpy into llvm.memcpy if you pass llvm-gcc -ffreestanding? If so, that's certainly a bug. Either way, you should be using -ffreestanding! Nick > I...

On Apr 30, 2008, at 11:19 PM, james woodyatt wrote: >> $TMPFILE:66: Error: internal_relocation (type: OFFSET_IMM) not >> fixed up You need to run the compile with -save-temps and then look at the .s file. If you like it, it is an assembler bug. If you don't like it, it is a bug in the compiler. If you don't know...

On Mon, Mar 1, 2010 at 8:20 PM, james woodyatt <jhw at conjury.org> wrote: > On Mar 1, 2010, at 09:56, james woodyatt wrote: >> On Mar 1, 2010, at 04:43, Duncan Sands wrote: >>> >>> Where exactly?  I don't see it in the online version. >> >> See <http://llvm.org/docs/LangRef.html#t_function&gt...

..."element_types" that return a > structure's subtypes. Anyone mind if I rename it to > "struct_element_types" so that the union and struct function are > similar? Again, knock yourself out. I can live with just about any compatibility breaking improvements. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

On Mar 12, 2010, at 1:49 PM, james woodyatt wrote: > On Mar 10, 2010, at 21:33, james woodyatt wrote: >> >> Maybe I'm missing it, but I don't see how to apply parameter attributes to function return types in either the C-language or OCaml bindings. Can anybody help clue me in? Thanks. > > I hope I can assume...

to me the name implies that it creates a handle to the type given, i guess if you look at it in context of the ocaml conversion functions some people may think otherwise. On Tue, Jan 26, 2010 at 6:49 PM, james woodyatt <jhw at conjury.org> wrote: > everyone-- > > I notice that Llvm.llvm_handle_to_type is actually defined to create a type > handle from a type, rather than vice versa as its name would imply. Should > I send a patch to change the name of the function to reflect its type > b...

On Feb 19, 2010, at 11:33 AM, james woodyatt wrote: > everyone-- > > File this under Advocacy. > > See this thread <http://www.haskell.org/pipermail/glasgow-haskell-users/2010-February/018425.html> for more information, but the short summary is that they're deprecating their old "compile to GCC" backend i...

...to say that the "OCaml bindings do not support JIT too much". > > Several major projects are using OCaml's LLVM bindings to execute > > non-trivial code via JIT. > > Could you please point out what these projects are? You'll have to ask Erick Tryzelaar, James Woodyatt and Nyx what they're up to. :-) > I am very interested in looking into these projects to see if they exposed > any more LLVM interfaces, and how they did this. I doubt they exposed any more of LLVM's internals. > OCaml bindings for optimizations have not exposed the LLVM inter...