On 06/04/2012 03:25 PM, Daniel Berlin wrote:> I'm pretty sure neither llvm nor clang have any technical debt at all. > > On Mon, Jun 4, 2012 at 5:18 PM, reed kotler<rkotler at mips.com> wrote: >> something to think about as llvm and clang grows. >> >> http://en.wikipedia.org/wiki/Technical_debt >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdevI hope you are joking. It's not meant as a criticism of llvm or clang but there is already an enormous amount of technical debt. It's something to try and get a handle on before it gets out of hand. Documentation is one area where it is accumulating fast but there are others. Testing is another area. Tablegen alone has huge technical debt. To me, there should be a cap placed on the number of lines of code in llvm. Like a budget. We should try and rewrite and refactor to keep the number of lines from growing without bound. At this point lots of patterns should be developing where other tools (like tablegen) could be written to reduce the amount of code and make things more understandable. Reed
On Mon, Jun 4, 2012 at 7:53 PM, reed kotler <rkotler at mips.com> wrote:> On 06/04/2012 03:25 PM, Daniel Berlin wrote: >> >> I'm pretty sure neither llvm nor clang have any technical debt at all. >> >> On Mon, Jun 4, 2012 at 5:18 PM, reed kotler<rkotler at mips.com> wrote: >>> >>> something to think about as llvm and clang grows. >>> >>> http://en.wikipedia.org/wiki/Technical_debt >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > I hope you are joking. >Why would I be joking?> It's not meant as a criticism of llvm or clang but there is already an > enormous amount > of technical debt.I don't see that.> > It's something to try and get a handle on before it gets out of hand.The consequences will never be the same> > Documentation is one area where it is accumulating fast but there are > others.I think LLVM is incredibly well documented> Testing is another area.It also has at least 10-15 tests.> Tablegen alone has huge technical debt.I'm sorry you feel that way.> > To me, there should be a cap placed on the number of lines of code in llvm.Will there be a credit offset system?> Like a budget. We should try and rewrite and refactor to keep the number of > lines from growing > without bound. > > At this point lots of patterns should be developing where other tools (like > tablegen) could be > written to reduce the amount of code and make things more understandable.I agree. We should macroize most of the passes so they aren't so wordy.> > Reed >
Well, differences of opinion is what makes horse races. Reed On 06/04/2012 04:57 PM, Daniel Berlin wrote:> On Mon, Jun 4, 2012 at 7:53 PM, reed kotler<rkotler at mips.com> wrote: >> On 06/04/2012 03:25 PM, Daniel Berlin wrote: >>> I'm pretty sure neither llvm nor clang have any technical debt at all. >>> >>> On Mon, Jun 4, 2012 at 5:18 PM, reed kotler<rkotler at mips.com> wrote: >>>> something to think about as llvm and clang grows. >>>> >>>> http://en.wikipedia.org/wiki/Technical_debt >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> I hope you are joking. >> > Why would I be joking? > >> It's not meant as a criticism of llvm or clang but there is already an >> enormous amount >> of technical debt. > I don't see that. > >> It's something to try and get a handle on before it gets out of hand. > The consequences will never be the same >> Documentation is one area where it is accumulating fast but there are >> others. > I think LLVM is incredibly well documented >> Testing is another area. > It also has at least 10-15 tests. >> Tablegen alone has huge technical debt. > I'm sorry you feel that way. >> To me, there should be a cap placed on the number of lines of code in llvm. > Will there be a credit offset system? >> Like a budget. We should try and rewrite and refactor to keep the number of >> lines from growing >> without bound. >> >> At this point lots of patterns should be developing where other tools (like >> tablegen) could be >> written to reduce the amount of code and make things more understandable. > I agree. We should macroize most of the passes so they aren't so wordy. > >> Reed >>