Mehdi AMINI via llvm-dev
2017-Jun-01 04:36 UTC
[llvm-dev] Should we split llvm Support and ADT?
2017-05-31 17:11 GMT-07:00 Michael Spencer <bigcheesegs at gmail.com>:> On Mon, May 29, 2017 at 10:22 AM, Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> 2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: >> >>> On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >>>> llvm-dev at lists.llvm.org>: >>>> >>>>> Changing a header file somewhere and having to spend 10 minutes >>>>> waiting for a build leads to a lot of wasted developer time. >>>>> >>>>> The real culprit here is tablegen. Can we split support and ADT into >>>>> two - the parts that tablegen depends on and the parts that it doesn't? >>>>> >>>> >>>> Splitting ADT just based on tablegen usage seems dubious to me. If we >>>> need to go this route, I'd replace as many uses of ADT data structure with >>>> STL ones to begin with to reduce the surface. >>>> >>> >>> Tablegen would not need to determine WHERE to split, it would just >>> motivate the why. >>> >> >> Well even the why :) >> (note I was mentioning ADT and not Support above). >> >> >> >>> It's obvious just from looking at Support's include directory though >>> that a lot of stuff in there doesn't belong together. A quick look over >>> the include directory already suggests a split into "broadly useful stuff" >>> and "narrowly useful stuff" >>> >> >> I agree, Support is a mess IMO (we have target specific stuff here just >> for the sake of sharing code with clang AFAIK) and I'm not sure anyone >> would oppose to split it. Ideally the way I would split it would be such >> that it could (at some point) be useful outside of LLVM (just like ADT), so >> one main criteria could be "could this component of Support be useful >> outside of LLVM (and its subprojects)". >> > > While it would be nice to easily use parts of support outside of llvm (as > I've done on many occasions), I'm not sure the llvm project wants to > maintain and support a generic c++ library. >Sorry, I'm not sure to follow you, because my impression is that we're *already* maintaining a generic C++ library in-tree. The fact that the mess that is libSupport today does not allow to split ADT (or other generic utilities in libSupport) out-of-tree easily does not change that.> Given that I don't think use outside of llvm is a great line to split on. >I think on the opposite that it is a valuable line because it matches a conceptual layer. -- Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170531/44f9123d/attachment.html>
Zachary Turner via llvm-dev
2017-Jun-01 05:03 UTC
[llvm-dev] Should we split llvm Support and ADT?
I'm somewhere in the middle. I don't think we need to maintain build files, documentation, upstream buildbots etc for using LLVMSupport out of tree, but I do like the conceptual separation and I think "is this useful outside of LLVM" is a good conceptual litmus test for what should go in such a hypothetical library. On Wed, May 31, 2017 at 9:36 PM Mehdi AMINI <joker.eph at gmail.com> wrote:> 2017-05-31 17:11 GMT-07:00 Michael Spencer <bigcheesegs at gmail.com>: > >> On Mon, May 29, 2017 at 10:22 AM, Mehdi AMINI via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> 2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: >>> >>>> On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >>>>> llvm-dev at lists.llvm.org>: >>>>> >>>>>> Changing a header file somewhere and having to spend 10 minutes >>>>>> waiting for a build leads to a lot of wasted developer time. >>>>>> >>>>>> The real culprit here is tablegen. Can we split support and ADT into >>>>>> two - the parts that tablegen depends on and the parts that it doesn't? >>>>>> >>>>> >>>>> Splitting ADT just based on tablegen usage seems dubious to me. If we >>>>> need to go this route, I'd replace as many uses of ADT data structure with >>>>> STL ones to begin with to reduce the surface. >>>>> >>>> >>>> Tablegen would not need to determine WHERE to split, it would just >>>> motivate the why. >>>> >>> >>> Well even the why :) >>> (note I was mentioning ADT and not Support above). >>> >>> >>> >>>> It's obvious just from looking at Support's include directory though >>>> that a lot of stuff in there doesn't belong together. A quick look over >>>> the include directory already suggests a split into "broadly useful stuff" >>>> and "narrowly useful stuff" >>>> >>> >>> I agree, Support is a mess IMO (we have target specific stuff here just >>> for the sake of sharing code with clang AFAIK) and I'm not sure anyone >>> would oppose to split it. Ideally the way I would split it would be such >>> that it could (at some point) be useful outside of LLVM (just like ADT), so >>> one main criteria could be "could this component of Support be useful >>> outside of LLVM (and its subprojects)". >>> >> >> While it would be nice to easily use parts of support outside of llvm (as >> I've done on many occasions), I'm not sure the llvm project wants to >> maintain and support a generic c++ library. >> > > Sorry, I'm not sure to follow you, because my impression is that we're > *already* maintaining a generic C++ library in-tree. The fact that the mess > that is libSupport today does not allow to split ADT (or other generic > utilities in libSupport) out-of-tree easily does not change that. > > >> Given that I don't think use outside of llvm is a great line to split on. >> > > I think on the opposite that it is a valuable line because it matches a > conceptual layer. > > -- > Mehdi > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170601/eb773d01/attachment.html>
Mehdi AMINI via llvm-dev
2017-Jun-01 05:16 UTC
[llvm-dev] Should we split llvm Support and ADT?
2017-05-31 22:03 GMT-07:00 Zachary Turner <zturner at google.com>:> I'm somewhere in the middle. I don't think we need to maintain build > files, documentation, upstream buildbots etc for using LLVMSupport out of > tree, but I do like the conceptual separation and I think "is this useful > outside of LLVM" is a good conceptual litmus test for what should go in > such a hypothetical library. >Right, to clarify: that is exactly my view as well at this point :) -- Mehdi> > On Wed, May 31, 2017 at 9:36 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> 2017-05-31 17:11 GMT-07:00 Michael Spencer <bigcheesegs at gmail.com>: >> >>> On Mon, May 29, 2017 at 10:22 AM, Mehdi AMINI via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> >>>> >>>> 2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: >>>> >>>>> On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < >>>>> llvm-dev at lists.llvm.org> wrote: >>>>> >>>>>> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >>>>>> llvm-dev at lists.llvm.org>: >>>>>> >>>>>>> Changing a header file somewhere and having to spend 10 minutes >>>>>>> waiting for a build leads to a lot of wasted developer time. >>>>>>> >>>>>>> The real culprit here is tablegen. Can we split support and ADT >>>>>>> into two - the parts that tablegen depends on and the parts that it doesn't? >>>>>>> >>>>>> >>>>>> Splitting ADT just based on tablegen usage seems dubious to me. If we >>>>>> need to go this route, I'd replace as many uses of ADT data structure with >>>>>> STL ones to begin with to reduce the surface. >>>>>> >>>>> >>>>> Tablegen would not need to determine WHERE to split, it would just >>>>> motivate the why. >>>>> >>>> >>>> Well even the why :) >>>> (note I was mentioning ADT and not Support above). >>>> >>>> >>>> >>>>> It's obvious just from looking at Support's include directory though >>>>> that a lot of stuff in there doesn't belong together. A quick look over >>>>> the include directory already suggests a split into "broadly useful stuff" >>>>> and "narrowly useful stuff" >>>>> >>>> >>>> I agree, Support is a mess IMO (we have target specific stuff here just >>>> for the sake of sharing code with clang AFAIK) and I'm not sure anyone >>>> would oppose to split it. Ideally the way I would split it would be such >>>> that it could (at some point) be useful outside of LLVM (just like ADT), so >>>> one main criteria could be "could this component of Support be useful >>>> outside of LLVM (and its subprojects)". >>>> >>> >>> While it would be nice to easily use parts of support outside of llvm >>> (as I've done on many occasions), I'm not sure the llvm project wants to >>> maintain and support a generic c++ library. >>> >> >> Sorry, I'm not sure to follow you, because my impression is that we're >> *already* maintaining a generic C++ library in-tree. The fact that the mess >> that is libSupport today does not allow to split ADT (or other generic >> utilities in libSupport) out-of-tree easily does not change that. >> >> >>> Given that I don't think use outside of llvm is a great line to split on. >>> >> >> I think on the opposite that it is a valuable line because it matches a >> conceptual layer. >> >> -- >> Mehdi >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170531/489f3f93/attachment.html>