similar to: [LLVMdev] Slow GIT/SVN Connection

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. >

Is anyone else experiencing very slow SVN checkouts/updates? I've tried from two separate networks now, and checkouts are 15+ minutes on both. -- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130102/46cbecca/attachment.html>

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,

I always though the /tags/RELEASE_xx/final branch would hold the final, released tarball contents, but this does not appear to be the case, at least not for 3.1. I can confirm that diffing /tags/RELEASE_31/final and the 3.1 tarball shows some non-trivial changes. The 3.2 release seems to be okay though; the diff only shows changes in the last-modified timestamps in the HTML docs. Though I just

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%

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

> Understanding the internal llvm/clang structure is easy, > deducing the correct code owner is not due to the > vague and changing nature of the CODE_OWNERS.TXT Does not seem to me and many people around. If in doubt - ask at ML or IRC. > "Exception handling, Windows codegen, ARM EABI" Just for your information - this covers some lines in some files in llvm/CodeGen, some

Won't it be http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_31/final/ On Tue, Jan 8, 2013 at 7:46 PM, Pankaj Gode <godepankaj at yahoo.com> wrote: > Hi All, > > I was checking for GIT or SVN versions corresponding to llvm3.1 release by > checking svn and git logs, but failed to find the exact match. > > I checked with r156747, which is the last version it shows

Hi All, I was checking for GIT or SVN versions corresponding to llvm3.1 release by checking svn and git logs, but failed to find the exact match. I checked with r156747, which is the last version it shows in      http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_31/ but when I 'diff' this with the 'downloaded llvm3.1 release'(http://llvm.org/releases/download.html#3.1), then I

> Just to be clear: we _really_ do not want all the sha's to change for trunk. Yes. That's why I said there will be other way :) In any case - please try clang.git once again. It should contain new branch/tag layout. If there will be some problems - let me know and I'll revert to prev. repository. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics,

It is my understanding that all you need to do is specify let isTarget = 1 in your .td file and it will generate target specific intrinsics. This should allow you to keep the IntrinsicsPTX.td file in the same location. Micah From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Monday, December 05, 2011 6:13 AM To: Alberto Magni Cc: Villmow, Micah; LLVM Developers Mailing List

I'm curious about the design rationale for how ManagedStatic instances are cleaned up, and I'm hoping someone can shed some light on it. Currently, ManagedStatic objects are cleaned up when llvm_shutdown() traverses the global list of initialized objects and calls destroy() on each. This leads to two questions: 1. An assertion enforces that the objects are deleted in reverse order of

Hi, We've recently encountered a problem in our compiler where the line number in debug info jumps back and force even at O0. This is caused by DAG node ordering not being properly kept during legalization and instruction selection. There are still uncaught cases after applying the patch mentioned here. So I have decided to implement the approach suggested by Andy as below. i.e. maintain the

Hi Justin, sorry for the delay, I have been busy. Micah's proposal requires to move the definitions of the intrinsics from include/llvm/IntrinsicsPTX.td to lib/Target/PTX/PTXIntrinsics.td thus allowing the generation of the file PTXGenIntrinsics.inc which will be included by PTXIntrinsicInfo.cpp. This is a quite big modification, do you agree with this ? Or do you have a better solution.

----- Original Message ----- > From: dag at cray.com > To: "Justin Holewinski" <justin.holewinski at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, January 11, 2013 2:13:50 PM > Subject: Re: [LLVMdev] Documentation of fmuladd intrinsic > > Justin

On Thu, Dec 8, 2011 at 11:36 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > It is my understanding that all you need to do is specify let isTarget = > 1 in your .td file and it will generate target specific intrinsics. This > should allow you to keep the IntrinsicsPTX.td file in the same location. > So we keep the intrinsics defined in include/llvm/IntrinsicsPTX.td?

Yes, total number of PTX registers that will be emitted is exactly what I need. It's hard to figure out this in LLVM IR level. 2013/8/7 Justin Holewinski <justin.holewinski at gmail.com> > Is there any way you could approximate the register/instruction usage and > perform live-range analysis in a higher-level LLVM IR pass? I'm not sure > how useful NVPTXRegisterInfo

On 29 September 2011 13:54, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Did you try to re-run configure after pulling that commit? > I just tried a shared build with: > ../configure --enable-optimized --enable-assertions > --enable-targets=host,ptx --enable-shared > And the build is successful. > What is your configure line, and system OS? Not sure it's

On Mon, Nov 21, 2011 at 11:45 AM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: > > On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni < > alberto.magni86 at gmail.com> > > wrote: > >> > >> Hi Justin, > >> > >> attached you find