similar to: [LLVMdev] Setting options when using libraries

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Setting options when using libraries"

2005 May 18
0
[LLVMdev] JIT + tail cals
Alexander Friedman wrote: > How do I tell the code generator to enable tail calls on the X86? > Since it is part of a library, I cannot pass a command line argument. Here is a snippet from our code which might help you ;-) const char *args[] = { "-disable-pattern-isel", "false", 0 }; cl::ParseCommandLineOptions(2, args); m.
2005 May 18
3
[LLVMdev] JIT + tail cals
How do I tell the code generator to enable tail calls on the X86? Since it is part of a library, I cannot pass a command line argument. -- -Alex
2005 Mar 16
0
[LLVMdev] Floating point compare instruction selection
On Wed, 16 Mar 2005, Morten Ofstad wrote: > Hello, > > I didn't get any reply to my previous mail about adding floating point > intrinsics to the X86 pattern instruction selector... And I could really need > some help. Sorry about that, it slipped through the cracks. :( > Anyway, I think my confusion was caused partly by an already > existing bug in the instruction
2005 Mar 17
1
[LLVMdev] FP Intrinsics
Chris Lattner wrote: > On Fri, 11 Mar 2005, Morten Ofstad wrote: >> I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added >> work with the X86ISelPattern, but I'm having some difficulties >> understanding what needs to be done. > > Cool. Here are a couple of requests: > > 1. I don't think we need an "llvm.abs" intrinsic
2005 Mar 16
2
[LLVMdev] Floating point compare instruction selection
Hello, I didn't get any reply to my previous mail about adding floating point intrinsics to the X86 pattern instruction selector... And I could really need some help. Anyway, I think my confusion was caused partly by an already existing bug in the instruction selection for floating point compares. The case which emits code for the special case of comparing against constant 0.0 does not
2006 Jan 26
4
[LLVMdev] VS2005 patch
OK, fixed the problem with the intrin.h header that doesn't exist in previous versions of VS... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JIT.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060126/7e55b0d0/attachment.ksh>
2005 Mar 17
1
[LLVMdev] Floating point compare instruction selection
Chris Lattner wrote: > On Wed, 16 Mar 2005, Morten Ofstad wrote: >> The case which emits code for the special case of comparing against >> constant 0.0 does not return after generating it's code, so the normal >> compare is also generated! As far as I can tell it should return right >> after this: >> >> BuildMI(BB, X86::SAHF, 1); >> >>
2005 Mar 16
0
[LLVMdev] FP Intrinsics
On Fri, 11 Mar 2005, Morten Ofstad wrote: > Hello, > > I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added work > with the X86ISelPattern, but I'm having some difficulties understanding what > needs to be done. Cool. Here are a couple of requests: 1. I don't think we need an "llvm.abs" intrinsic at the llvm level. This can be
2004 Oct 12
3
[LLVMdev] set_intersect and Visual C compiler
Hello, This is my first post on this mailing list, so bear with me... My name is Morten Ofstad and I work for Hue AS (www.hue.no), a company that makes 3D Visualization software. We are looking into using LLVM for JIT compiling shader programs, to replace our own (slow) VM. A requirement for this is that we can compile LLVM in VS7.1, so I contacted Paolo Invernizzi to find the status of his
2004 Nov 08
2
[LLVMdev] Small patch for visual studio project files
We could also do the "cvs admin -kb" thing on all the project files so that cvs won't do keyword expansion or line ending conversion. Thoughts? Reid. On Mon, 2004-11-08 at 07:36, Jeff Cohen wrote: > You have to use a version of CVS that's specifically built for Windows. > You can find prebuilt Windows binaries at cvshome.org. The cygwin > supplied CVS no doubt
2016 Feb 05
2
MCJit Runtine Performance
Hi Keno, Thanks for the fast ISel suggestion. Here are the results (for a small but representational run): LLVM 3.5.2 (old JIT): 4m44s LLVM 3.7.1 (MCJit) no fast ISel: 7m31s LLVM 3.7.1 (MCJit) fast ISel: 7m39s So not much of a difference unfortunately. On 05/02/16 11:05, Keno Fischer wrote: > Yes, unfortunately, this is very much known. Over in the julia > project, we've recently
2004 Nov 08
3
[LLVMdev] Small patch for visual studio project files
Jeff Cohen wrote: > Are you sure your CVS is configured correctly? On Windows, CVS > automatically converts between LF and CR/LF line endings. I sent a > patch to remove all CRs from the repository because when I checked out > the files on Windows, every line had two CRs and a single LF. When VS > saved a modified project file, the extra CR went away, causing every > line to
2007 Apr 13
4
[LLVMdev] "Name that compiler"
me22 wrote: > One of the nicer project names I've seen recently is Alexandria, for a > book database program ( http://alexandria.rubyforge.org/ ). It > unfortunately fails the searchability test, but does brilliantly at > reminding you what it is. Along these lines, is there any mythical characters or historical persons which are associated with translation (which is the primary
2004 Nov 01
4
[LLVMdev] Final Visual Studio Patches
Hello, with the patches you accepted last week, everything now works with two one-line modifications. One is a missing include in a windows specific platform file and the other is a definition of a symbol I need to trick the linker (as discussed before)... The attached file is the complete diff between my version and the CVS. If you want to put my visual studio project files into the CVS,
2004 Oct 12
0
[LLVMdev] set_intersect and Visual C compiler
On Tue, 12 Oct 2004, Morten Ofstad wrote: > This is my first post on this mailing list, so bear with me... My name > is Morten Ofstad and I work for Hue AS (www.hue.no), a company that > makes 3D Visualization software. We are looking into using LLVM for JIT > compiling shader programs, to replace our own (slow) VM. A requirement Neat! > for this is that we can compile LLVM in
2016 Feb 05
2
MCJit Runtine Performance
Hi Lang, > That suggests an optimization quality issue, rather than compile-time overhead Yes that makes sense. The long running applications (6+ hours) JIT the rules once (taking a few seconds) and then run the generated machine code for hours. With no additional JIT'ing. > if we can configure the CodeGen pipeline properly we can get the performance back to the same level as
2006 Jan 26
0
[LLVMdev] VS2005 patch
Hi Morten, If you can make the VS2005 project files availiable on the net then I can test them as I have VS2005 now, so then with Chris'es okay then they could be distributed with LLVM. Thanks, Aaron ----- Original Message ----- From: "Morten Ofstad" <morten at hue.no> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, January 26,
2004 Nov 08
3
[LLVMdev] Small patch for visual studio project files
I moved my own llvm tree out of the way and tried to get a fresh copy from cvs and build everything from scratch... and it worked! apart from one little problem, a file was moved and should be removed from the project files -- here is a patch. There is a small problem with submitting patches for the .vcproj files - VS saves them with CRLF line endings but the CVS versions appear to have only
2007 Apr 13
0
[LLVMdev] "Name that compiler"
I don't like very much mithology or fantasy names. A portmanteau is more professional (even if it sounds funny). For now IMHO the best proposal is Omnipiler and OmniC, even if the last one reminds too much of C. Maybe Omnic (with the lowercase c), or Omnip are better. Simple, elegant and somehow reminds of something technological (to me at least :P). So my idea is to list some key words and
2004 Dec 08
3
[LLVMdev] Compiling with Intel c++ 8.0
Hi, I am attempting to compile the llvm distribution with the Intel Compiler 8.0 on linux and I have some minor patches I would like to apply. In our project we compile and run the code both on win32, together with Morten Ofstad using the MS compiler, and on linux using the intel compiler. I have wrapped the extra code to make llvm compile for icc in #ifdef __INTEL_COMPILER #endif The patches