search for: burden

...of a monotonically increasing number that corresponds across repositories. While admittedly you do get a linear history with using the mono-repository, that isn’t the only way to solve the problem, and I don’t really think that the benefit (not needing to write some tooling) justifies the increased burden applied to contributors that don’t use the full LLVM family of projects. > > What do you believe is this increased burden? > > The entire commit history of all llvm projects in a mono-repository is a 449 MB .git directory. It can be downloaded in about two minutes on a typical domesti...

...lly increasing number that corresponds across repositories. While > admittedly you do get a linear history with using the mono-repository, that > isn’t the only way to solve the problem, and I don’t really think that the > benefit (not needing to write some tooling) justifies the increased burden > applied to contributors that don’t use the full LLVM family of projects. > What do you believe is this increased burden? The entire commit history of all llvm projects in a mono-repository is a 449 MB .git directory. It can be downloaded in about two minutes on a typical domestic internet...

I'm removing old targets that no longer appear actively maintained, to reduce the burden for target-independent codegen maintenance. Does anyone object to the removal of the Alpha backend? Dan

I'm removing old targets that no longer appear actively maintained, to reduce the burden for target-independent codegen maintenance. Does anyone object to the removal of the Sparc backend? Dan

I have read http://www.theora.org/theorafaq.html#42 This put quite a burden onto the Windows-user - a burden that most Windows-users will not be able to lift. Has anyone made a webpage with a link to a theora-file that automatically (or with a few clicks on Accept/OK) installs the needed codecs on a unmodified Windows machine? (The links to theora-files on www.theora.org...

On Oct 25, 2011, at 9:29 AM, David A. Greene wrote: > Dan Gohman <gohman at apple.com> writes: > >> I'm removing old targets that no longer appear actively maintained, >> to reduce the burden for target-independent codegen maintenance. >> >> Does anyone object to the removal of the Alpha backend? > > It would be a shame to lose it. Alpha is an excellent example of a good > RISC-style ISA. There's at least one simulator out there that uses it. In this case,...

...M, Justin Lebar <jlebar at google.com> wrote: > > Chris, > > What I notice in your latest e-mail -- and I don't know if this is > intentional, so sorry if I'm reading too much into it -- is that the > language has switched from "an unwarranted and unacceptable burden" to > "a burden”: I consider it unwarranted and unacceptable to me, however that is based on a context of my workflows. Without a wider context I cannot know if the burden to me is justifiable by benefits to the wider community. I’m trying to be explicit here. I’m stating my opinions...

Dan Gohman <gohman at apple.com> writes: > I'm removing old targets that no longer appear actively maintained, > to reduce the burden for target-independent codegen maintenance. > > Does anyone object to the removal of the Alpha backend? It would be a shame to lose it. Alpha is an excellent example of a good RISC-style ISA. There's at least one simulator out there that uses it. What is the burden you are trying to r...

...e are several > advantages to this, as noted here: > I agree, this would be useful even for other environments to solve the bloat that can happen by exporting all the symbols. Adding targeted dllexport annotations won't work because non-Windows developers (the majority) shouldn't be burdened with keeping them up to date. On Wed, May 8, 2013 at 5:21 PM, Reid Kleckner <rnk at google.com> wrote: > Adding targeted dllexport annotations won't work because non-Windows > developers (the majority) shouldn't be burdened with keeping them up > to date. > IMHO it...

...t; The DragonEgg project is, as far as I can tell, abandoned, but it is still an LLVM project that is tightly coupled to LLVM versions. So it meets criteria #1. I think it fails to meet criteria #2 because DragonEgg is basically abandoned and provides no real value to the community. Even though the burden of a dead project on the mono-repo is minuscule, I think there is no good reason to include DragonEgg. > > If DragonEgg is abandoned, I think we should keep the history in our > repository and just delete it from head. > > My argument for keeping it in our history is: Suppose we go...

Hi, I used to rsync a /home with thousands of home directories every night, although only a hundred or so would be used on a typical day, and many of them have not been used for ages. This became too large a burden on the poor old destination server, so I switched to a script that uses "find -ctime -7" on the source to select recently used homes first, and then rsyncs only those. (A week being a more than good enough safety margin in case something goes wrong occasionally.) Is there a smarter way...

...reasonable alternates. OK, good to know. I put you on the path because you wrote: "I am opposed to extending the instructions without a strong motivating case. I don't care anywhere near as much about metadata based schemes, but extending the instruction semantics imposes a much larger burden on the rest of the community. That burden has to be well justified and supported." It is not clear to me right now if the "use case" makes it "well justified" or not (an alternative being using intrinsic for OpenCL as Justin Lebar mentioned). I don’t feel I can answer thi...

...te: >> >> Prior to FTL, JavaScriptCore had no dependence on the LLVM project. Maintaining a dependence on an external project naturally has integration overhead. > > And the fact that a company that has as much in-house LLVM expertise as Apple decided that this was a significant burden is something that we should take note of. LLVM is particularly unfriendly to out-of-tree developers, with no attempt made to provide API compatibility between releases. I maintain several out-of-tree projects that use LLVM and the effort involved in moving between major releases is significant (a...

...It takes hours to traverse all these directories with loads of small files on the backup server. That is the limiting factor. Not even copying: just checking the timestamp and size of the old copies. The source server is the actual live system, which has fast disks, so I can afford to move the burden to the source side, using the find utility to select homes that have been touched recently and using rsync only on these. But it would be nice if a clever invocation of rsync could remove the extra burden entirely. Dirk van Deun -- Ceterum censeo Redmond delendum

...y. > I would like to build an "insertNoOp" and add it to MRegisterInfo. I would have one for each target. For the x86 I am moving the stack pointer to itself. Is there a better "no-op"? A better one would be one that does not use any register, so it will add absolutely no burden on the register allocator. Fernando

If you don't use BBVectorize at all, you can ignore this. Hal suggested this in a thread in 2014: http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html None objected then, and I don't think any new uses have arisen so I plan to just remove it. It is causing maintenance burden, complexity, and is a set of features I'd rather not port to the new PM. Just an FYI email to folks so they aren't confused when the patches land. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201706...

...nd all of the disadvantages! James On Wed, 27 Jul 2016 at 19:30, David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 27 Jul 2016, at 19:03, Bruce Hoult via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > What do you believe is this increased burden? > > > > The entire commit history of all llvm projects in a mono-repository is a > 449 MB .git directory. It can be downloaded in about two minutes on a > typical domestic internet connection (50 Mbps). > > > > If you download only a snapshot of the current HEAD commi...

...builds, but it's not easy. There's no way to blanket export every symbol from a dll. Even if you did, I've heard there are issues with exporting more than 2^16 symbols. Adding targeted dllexport annotations won't work because non-Windows developers (the majority) shouldn't be burdened with keeping them up to date. On Wed, May 8, 2013 at 11:30 AM, Peng Cheng <gm4cheng at gmail.com> wrote: > According to http://llvm.org/docs/CMake.html, "Shared libraries are not > supported on Windows and not recommended in the other OSes". > > The problem is that st...

Personally, every machine I work with only has Python 2.7. Justin is correct that there is a non-trivial amount of effort to convert the bots. Python 3 is wonderful. But, a Python 3 dependency seems like one burden that could be avoided. We have already made that trade-off in the past, for example by only using standard python packages, so there is less/nothing to pip install when getting started. Dependencies likes host compiler and cmake totally make sense given they are central to how LLVM is made. I do...

Instead of putting the burden on the back-ends to implement special lowering code, why not implement code in the legalizer that would automatically sign extend them to the next largest power of 2 integer if the specific integer types were not supported. This would then remove the need of the back-ends to implement anything as L...