search for: churn

Displaying 20 results from an estimated 690 matches for "churn".

2020 Oct 01
2
OrcV1 removal
...but we want to shift to calling it outside the lock and passing a > lookup-continuation. This would allow definition discovery to take an > arbitrarily long time without blocking forward progress on other JIT work. Sounds useful. > I'm guessing your objective for now is to minimize churn, right? If that's > the case I'll focus on moving to the continuation passing API on the > orcv1-removal branch before I update the C API. Yes, I do prefer less churn. It's not a deal breaker, but I try to keep PG compiling against trunk LLVM, and there's multiple stable bran...
2018 May 24
1
Style: getFoo() vs foo()
...about this change? Clearly a mix of these styles will exist in practice for a long time (this is already the case!) but which should be encouraged? >> >> (*dons flame-retardant suit and mumbles something about Java*) > > I like it, but only if this means we’re going to introduce churn for the public interfaces. I’m not sure this is actually worth the trouble to do, but more consistent rules just sound like better rules to me at least. I assume there is a "not" missing in the first sentence there? I'd also prefer not to have API churn just for the sake of minor st...
2014 Jul 03
6
[LLVMdev] The poor organization of TargetLowering (and related subclasses) is out of hand
(Sorry for CC'ing piles of people, but didn't want folks to miss this in the mailing list churn.) See the subject. The problem is in the target-independent code generator and especially in the x86 backend. I would like to fix it. This will be a mechanical change just organizing code in a way that makes it easy and fast to find methods and related static helpers. It will not change any actua...
2014 Jun 07
2
[LLVMdev] Stack maps no longer experimental in 3.5
..., Filip Pizlo wrote: > That would work. :-) > > What about exposing C API a function to query for the presence of an intrinsic? It seems with hindsight that the "experimental" prefix has turned out to be a waste of time. At least without the prefix there was a good chance this churn could be avoided as long as the original review was sound, whereas the prefix has necessitated churn. I suggest performing a configure-time check in your build system to retain backward/forward compatibility instead of attempting to specify C API for instruction introspection(!). Alp. &g...
2020 Feb 19
5
amount of camelCase refactoring causing some downstream overhead
...is not relevant, because these patches were not reviewed (in accordance with current policy, that this kind of mechanical fixup is “obvious” and does not require pre-commit review). The patches were not really very distinct, with a HUGE overlap in the set of affected files. We do like to minimize churn; this kind of fixup clearly qualifies as churn, but I respectfully submit that the way it was done does not *minimize* the churn. And minimizing the churn is good for both the project and those of us who live downstream of it. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On B...
2018 May 24
3
Style: getFoo() vs foo()
The coding guidelines say: > Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). This means that functions that just compute or access a value (no side-effects) should be named e.g. `getParent()`, rather than `parent()` as they are in
2014 Jun 08
3
[LLVMdev] Stack maps no longer experimental in 3.5
...> > It's only a waste of time if you think that run-time feature detection is a > bad idea. I believe that run-time feature detection is a good idea even if > we didn't need it in this particular case. > > > > At least without the prefix there was a good chance this churn could be > avoided as long as the original review was sound, whereas the prefix has > necessitated churn. > > The intrinsic changed a fair bit since the original review. Both its > signature and the stackmap format changed. > > > > I suggest performing a configure-time c...
2013 Feb 05
3
[LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API
...013, at 01:32, Bill Wendling wrote: > No. It hasn't been written up. We typically don't do write-ups for API changes. However, we do list the thing we do change in the ReleaseNotes (these changes haven't made it there though). The attributes API has undergone a horrendous amount of churn over the last few months, both before and after the 3.2 release. I've lost track of the number of times I've rewritten code interacting with this API over the past year and I now have a mess of #ifdefs just to support 3.1, 3.2 and trunk. Each time, the only warning I got was that my code...
2017 Apr 07
3
Widescale clang-tidy (or similar) based cleanup
...imilar automated refactoring to make project-wide cleanups/improvements to the LLVM codebase that appear to me to be a bit out of character with the sort of changes & philosophies that have been applied in the past. I think there are a few issues at hand which I'll try to summarize: * Churn/blame-convenience: Previously, large scale changes (classically whitespace cleanup, with things like clang-format) have been rejected or discouraged due to the risk of making it harder to find the original source of a semantic change. I'm not too wedded to this issue myself, but it did seem...
2013 Jan 13
3
[LLVMdev] Using C++'11 language features in LLVM itself
...isn't very encouraging. Anecdotally from what I've seen in LLD (whose C++11 feature use is bounded only by MSVC 2012), the features that get the most mileage by a large margin are `auto`, range-for, and `nullptr`, along with library offerings like unique_ptr<>. Just based on that, the churn and overhead of imposing new build requirements doesn't seem worth it at the moment. -- Sean Silva
2013 Feb 06
0
[LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API
...Wendling wrote: > >> No. It hasn't been written up. We typically don't do write-ups for API changes. However, we do list the thing we do change in the ReleaseNotes (these changes haven't made it there though). > > The attributes API has undergone a horrendous amount of churn over the last few months, both before and after the 3.2 release. I've lost track of the number of times I've rewritten code interacting with this API over the past year and I now have a mess of #ifdefs just to support 3.1, 3.2 and trunk. Each time, the only warning I got was that my code...
2009 Jul 15
3
[LLVMdev] please stabilize the trunk
We've had a lot of churn in all the trunks (llvm, llvm-gcc, clang) recently, and the testing buildbots have been failing repeatedly. I spoke with Chris this AM, and he suggested we have a "stabilization day." Please avoid large, destabilizing changes for about twenty-four hours. We would like for the tes...
2003 Apr 17
3
sma
in the sma library, I m trying to use stat.t2 but I don t know what the parameter cl actually means!! cheers
2013 Nov 06
0
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
...hat on, it's frustrating that we don't make it easier, because we end up having to make sure that it's possible to install half a dozen different versions of LLVM simultaneously because there are always some projects that depend on an old one and only have the manpower to handle the API churn every few releases - I think we've now finally got rid of the ones that depend on LLVM 2.6, but 2.8 is still quite popular. David [1] We make their life very hard by introducing new APIs long before we document them. For example, we still don't have adequate documentation of the new attri...
2020 Mar 25
6
Multi-Threading Compilers
On Mar 25, 2020, at 4:14 PM, Doerfert, Johannes <jdoerfert at anl.gov> wrote: > >> Today, you can walk the use-list of any operand to an instruction. >> This would be broken by this change, > > First, you would be able to walk the use-list of any operand. So nothing > breaks just yet. If I understand correctly, you are suggesting that you can walk it, but you don’t
2013 Jun 27
1
[LLVMdev] Heads up, I've backed out significant amounts of the multiple address space conversion changes
...sign is not necessarily the same as the first initial implementation. There are things that will break and this kind of change touches almost everything, not just the core LLVM libraries. It is hard to get right the first time, and developing it in a sandbox will dramatically decrease the amount of churn that will show up in all the various components on mainline. Just from my experience, the following items have to be solved or considered that my first implementation didn’t handle. Now I am not doing this work, and I haven’t looked at this in many months, so this is based on my memory, so I might...
2010 Feb 15
2
[LLVMdev] Botched Build
Sorry, I botched a commit and broke the build. I've just committed a fix. So expect to see some buildbot churning. -Dave
2010 Feb 15
2
[LLVMdev] Botched Build
On Monday 15 February 2010 11:54:25 Óscar Fuentes wrote: > David Greene <dag at cray.com> writes: > > Sorry, I botched a commit and broke the build. I've just committed a > > fix. > > > > So expect to see some buildbot churning. > > Don't hurry. A buildbot already decided that I am the only culprit of > the breakage. :-/ Hmm...given that MC/AsmParser/X86/x86_32-encoding.s has been failing for a while, maybe someone should mark it XFAIL? -Dave
2019 Jul 30
2
[PATCH 03/13] nouveau: pass struct nouveau_svmm to nouveau_range_fault
On Tue, Jul 30, 2019 at 08:51:53AM +0300, Christoph Hellwig wrote: > This avoid having to abuse the vma field in struct hmm_range to unlock > the mmap_sem. I think the change inside hmm_range_fault got lost on rebase, it is now using: up_read(&range->hmm->mm->mmap_sem); But, yes, lets change it to use svmm->mm and try to keep struct hmm opaque to drivers
2019 Jul 30
1
[PATCH 03/13] nouveau: pass struct nouveau_svmm to nouveau_range_fault
...s > > now using: > > > > up_read(&range->hmm->mm->mmap_sem); > > > > But, yes, lets change it to use svmm->mm and try to keep struct hmm > > opaque to drivers > > It got lost somewhat intentionally as I didn't want the churn, but I > forgot to update the changelog. But if you are fine with changing it > over I can bring it back. I have a patch deleting hmm->mm, so using svmm seems cleaner churn here, we could defer and I can fold this into that patch? Jason