similar to: [LLVMdev] Bug in FoldingSetNodeID::AddInteger(unsigned long long I)?

Rubin, Norman wrote: > I'm trying to install llvm on my windows development box and hit a > problem > I'm using cygwin > cygwin% gcc --version > gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > I downloaded both the top of tree via svn > I ran ./configure > make > > make[1]: Entering directory `/cygdrive/c/llvm/lib/Support' >

I'm trying to install llvm on my windows development box and hit a problem I'm using cygwin cygwin% gcc --version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) I downloaded both the top of tree via svn I ran ./configure make make[1]: Entering directory `/cygdrive/c/llvm/lib/Support' llvm[1]: Compiling APFloat.cpp for Debug build llvm[1]: Compiling APInt.cpp

I used to be able to build LLVM (from source) under Cygwin for llvm-2.2 and previous releases, but can't continue the trend since the release of LLVM 2.3. I have tried a wide variety of gcc compilers (gcc 3.4.4, 4.1.2, 4.2.4 and 4.3.2) on cygwin, they all fail at the same location: C:\cygwin\home\czhao\ResearchTools\LLVM\2.3\obj2.3>make make[1]: Entering directory

On Mon, Oct 06, 2008 at 08:12:05PM -0400, Chuck Zhao wrote: > I used to be able to build LLVM (from source) under Cygwin for llvm-2.2 > and previous releases, but can't continue the trend since the release of > LLVM 2.3. > I have tried a wide variety of gcc compilers (gcc 3.4.4, 4.1.2, 4.2.4 > and 4.3.2) on cygwin, they all fail at the same location: > >

Hello, I'm starting to play with LLVM today and I've trouble compiling it. I'm working under Windows Vista, with the gcc from Cygwin: gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Is LLVM supposed to work with this version of GCC (probably using the -mno-cygwin option to get a Mingw-like behavior)? The LLVM source tree is from the current SVN trunk. Compilation

Julien Lerouge wrote: > On Mon, Oct 06, 2008 at 08:12:05PM -0400, Chuck Zhao wrote: > >> I used to be able to build LLVM (from source) under Cygwin for llvm-2.2 >> and previous releases, but can't continue the trend since the release of >> LLVM 2.3. >> I have tried a wide variety of gcc compilers (gcc 3.4.4, 4.1.2, 4.2.4 >> and 4.3.2) on cygwin, they

In any case, it seems that GCC 3.4.4 may be in hot water even if you did get it to compile: http://llvm.org/docs/GettingStarted.html#brokengcc -- Christopher Lamb On Aug 6, 2007, at 9:48 AM, Alain Frisch wrote: > Hello, > > I'm starting to play with LLVM today and I've trouble compiling it. > I'm > working under Windows Vista, with the gcc from Cygwin: > >

Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the >

Hi, While profiling LLVM using my test-cases with huge MBBs, I noticed that FoldingSetNodeID operations (ComputeHash,insertion,etc) may become really inefficient for the nodes, which have very many operands. I can give you an example of what is meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB

Hi Dan, Thanks for commenting on this topic. See my comments in-line. ----- Ursprüngliche Mail ---- > Von: Dan Gohman <gohman at apple.com> > An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Gesendet: Mittwoch, den 30. April 2008, 21:38:26 Uhr > Betreff: Re: [LLVMdev] FoldingSetNodeID operations inefficiency > > > On Apr 28, 2008, at 6:21 AM, Roman

Hi Chris, Your were totally right with your suggestion. I have implemented the code that : a) does not merge multiple TokenFactor nodes in the DAGCombiner::visitTokenFactor(), if the resulting TF node would contain more than 64 operands. b) produces a bunch of TokenFactor nodes with at most 64 operands, instead of one huge TokenFactor in the SelectionDAGLowering::getRoot(). If we have n

On Sat, Feb 06, 2010 at 04:51:15PM -0800, Chandler Carruth wrote: > While I've not reviewed the patch in too much detail, it looks > promising. Can you run some end-to-end benchmarks to make sure that > cache pressure in the full program or other variables not accounted > for in a micro-benchmark don't dominate performance? Specifically the > nightly tester includes a number

Some additional info can be found at: http://murmurhash.googlepages.com/ http://en.wikipedia.org/wiki/MurmurHash http://www.codeproject.com/KB/recipes/hash_functions.aspx as well as in the patch description itself. Patch and benchmark attached. Gregory -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi, Could you share how you compile IR and which version of JIT you use (Orc, MCJIT)? Could it be that you are using interpreter instead of actual JIT? Cheers, Alex. > On 5. May 2018, at 08:04, edA-qa mort-ora-y via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm having issues of my compiler, and JIT execution, of LLVM IR being > rather slow. It's accounting for

I'm having issues of my compiler, and JIT execution, of LLVM IR being rather slow. It's accounting for the vast majority of my full compilation time.  I'm trying to figure out why this is happening, since it's becoming an impediment.  (Note: by slow I mean about 3s of time for only about 2K of my front-end code, 65K lines of LLVM-IR) Using valgrind I see some functions which seem

Hi everyone, TL;DR: With current pending patches applied in compiler-rt and llvm, and trunk clang, you can build your application with XRay tracing enabled on Linux with tracing enabled before main starts, and logging stops when the main thread exits. Just a quick update, I have some patches under review that when applied cleanly to LLVM and compiler-rt allows for building applications with XRay

Function.cpp:167: error: call of overloaded `AddInteger(uint32_t&)' is ambiguous /home/Seb/llvm/include/llvm/ADT/FoldingSet.h:151: note: candidates are: void llv m::FoldingSetImpl::NodeID::AddInteger(int) /home/Seb/llvm/include/llvm/ADT/FoldingSet.h:152: note: void llvm::FoldingSetIm pl::NodeID::AddInteger(unsigned int) /home/Seb/llvm/include/llvm/ADT/FoldingSet.h:153: note: void

While I've not reviewed the patch in too much detail, it looks promising. Can you run some end-to-end benchmarks to make sure that cache pressure in the full program or other variables not accounted for in a micro-benchmark don't dominate performance? Specifically the nightly tester includes a number of real programs and machinery to measure total compile time. On Sat, Feb 6, 2010 at 7:09

On 2010-02-06 17:09, Gregory Petrosyan wrote: > Some additional info can be found at: > > http://murmurhash.googlepages.com/ > http://en.wikipedia.org/wiki/MurmurHash > http://www.codeproject.com/KB/recipes/hash_functions.aspx > > as well as in the patch description itself. Patch and benchmark attached. > > +/// This version additionally assumes that 'len %

On Feb 7, 2010, at 1:03 PM, Gregory Petrosyan wrote: > On Sat, Feb 06, 2010 at 04:51:15PM -0800, Chandler Carruth wrote: >> While I've not reviewed the patch in too much detail, it looks >> promising. Can you run some end-to-end benchmarks to make sure that >> cache pressure in the full program or other variables not accounted >> for in a micro-benchmark don't