similar to: [LLVMdev] Slow SVN Checkouts

On Wed, Jan 2, 2013 at 7:01 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Is anyone else experiencing very slow SVN checkouts/updates? I've tried > from two separate networks now, and checkouts are 15+ minutes on both. > > -- > It could've been a temporary hiccup. Just updated and it was reasonably fast (given the large changes from Chandler's

I just tried again and it's still fairly slow. This time I did a full checkout in about 10 minutes. Server-side git commands are also significantly slower than usual (e.g. "counting objects" phase of a clone takes several minutes, as opposed to the usual ~15 seconds). Though the actual transfer of objects is just as fast (~20 MiB/sec). If I'm the only one experiencing this,

Is anyone else having issues with the GIT/SVN repositories for LLVM? Git fetches are taking forever (> 15 minutes to compress 800 objects), and SVN checkouts are going at about a file per minute. I've tried this on two different, geographically-dissimilar networks so I don't think the problem is on my end. The web-site seems fine. -- Thanks, Justin Holewinski -------------- next

On 4/3/12 9:36 AM, Justin Holewinski wrote: > Is anyone else having issues with the GIT/SVN repositories for LLVM? > Git fetches are taking forever (> 15 minutes to compress 800 > objects), and SVN checkouts are going at about a file per minute. > I've tried this on two different, geographically-dissimilar networks > so I don't think the problem is on my end. >

OK, fine -- an example of MCJIT that sets up for PTX JIT would also be helpful. On Dec 6, 2013, at 12:32 PM, Eli Bendersky <eliben at google.com> wrote: > > You'll have to switch to MCJIT for this purpose. Legacy JIT doesn't emit PTX. > > Eli -- Larry Gritz lg at larrygritz.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello Anton and Takumi. Anton Korobeynikov <anton at korobeynikov.info> writes: >> 14 KB/s now. Yesterday 40 KB/s. >> Is that transitory or there is no enough bandwidth on llvm.org? > Something is wrong on your side: > > $ git clone http://llvm.org/git/llvm.git > Cloning into llvm... > remote: Counting objects: 607409, done. > remote: Compressing objects: 100%

Hi Hal, Thanks for your comments! I'm inlining my responses below. Jingyue On Sat, Apr 19, 2014 at 6:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Jingyue, > > I can't speak for the NVPTX backend, but I think this looks useful as an > (optional) target-independent pass. A few thoughts: > > - Running GVN tends to be pretty expensive; have you tried EarlyCSE

2012/6/5 Kok, Auke-jan H <auke-jan.h.kok@intel.com> wrote on systemd-devel list: > It seems your system is taking well into 15+ seconds before btrfs is > actually *ready* on your system, which seems to be the main hiccup > (note, speculation here). I''ve personally become a bit displeased with > btrfs performance recently myself, so, I''m wondering if you should

Hi, We wrote an optimization that eliminates common sub-expressions in a group of similar GEPs for the NVPTX backend. It speeds up some of our benchmarks by up to 20%, which convinces us to try to upstream it. Here's a brief description of why we wrote this optimization, what we did, and how we did it. Loops in CUDA programs are often extensively unrolled by programmers and compilers,

On Tue, Nov 1, 2011 at 5:57 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Hello Anton and Takumi. > > Anton Korobeynikov <anton at korobeynikov.info> writes: > > >> 14 KB/s now. Yesterday 40 KB/s. > >> Is that transitory or there is no enough bandwidth on llvm.org? > > Something is wrong on your side: > > > > $ git clone

On Fri, Aug 7, 2015 at 12:01 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/07/2015 11:35 AM, Jingyue Wu wrote: > > + the new llvm-dev > > On Fri, Aug 7, 2015 at 11:30 AM, Jingyue Wu <jingyue at google.com> wrote: > >> Hi folks, >> >> Unsurprisingly, leveraging the fact that certain address spaces don't >> alias can

There is no MCJIT support for PTX at the moment (mainly because PTX does not have a binary format, and is not machine code per se). To generate PTX at run-time, you just set up a standard codegen pass manager like you would like an off-line compiler. The output will be a string buffer that contains the PTX, which you can load into the CUDA runtime. As for determining if PTX support is compiled

Ah, that's helpful. I knew that I'd need to end up with PTX as text, not a true binary, but I would have figured that it would come out of MCJIT. Thanks for helping to steer me away from the wrong trail. OK, one more question: Can anybody clarify the pros and cons of generating the PTX through the standard LLVM distro, versus using the "libnvvm" that comes with the Cuda SDK?

On Fri, Sep 6, 2013 at 9:35 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi Eli > > I don’t know a workaround which will keep support for coloured terminal > output, but if you can live without it then passing these to configure > should work. > > --enable-curses=no > --enable-terminfo=no > > Re-doing the configure & build in a new directory solved

On Aug 7, 2015, at 8:28 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: ________________________________ From: "Jingyue Wu" <jingyue at google.com<mailto:jingyue at google.com>> To: "Matt Arsenault" <Matthew.Arsenault at amd.com<mailto:Matthew.Arsenault at amd.com>> Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at

> > Ah! This is the one that's messing up. Could someone take a look at > this and see why it's failing? It doesn't even seem to be getting to > the "svn" checkout. > > Hi Bill, [sorry I was not subscribed to llvm-testresults, and noticed this only now] This is a buildbot bug apparently, see http://buildbot.net/trac/ticket/284 and

>> I suppose this tradeoff can be evaluated by looking at the delta >> between 4.5 and 4.6 which is actually supported by MSVC 2010 and Clang >> 3.1 > > Makes perfect sense to me. > > -Chris According to http://gcc.gnu.org/projects/cxx0x.html, these features are available from 4.6 (language features only): - Null pointer constant - Forward declarations for enums -

On Sat, Dec 1, 2012 at 2:08 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 2012-12-01 21:57, Gregory Szorc wrote: >> >> I'd like to continue the discussion about minimum Python versions from the >> "Use multiprocessing instead of threading" thread in its own thread because >> I feel it warrants additional discussion. > > ... >

On 08/07/2015 06:13 PM, Hal Finkel wrote: > But you seem to be implying that you'll use different address spaces > at the IR level, but that these address spaces will be changed prior > to the target seeing them? Or that the target will internally map them > all to address space 0 (instead of aborting). If the target knows to > do this mapping, it can also understand the

Hello, I'm trying to build some code that relies on LLVM as a library (out-of-source). It uses llvm-config for the compilation & linkage flags. Some recent change breaks it, and with the newest trunk LLVM I get: /home/eliben/llvm/build_llvm_svn_rw/Debug+Asserts/lib/libLLVMSupport.a(Process.o): In function `terminalHasColors':