[LLVMdev] technical debt

Mon Jun 4 22:00:46 PDT 2012

I definitely trust what you say now with time to think at your keyboard
over what you said on the spot in a live presentation. The comment that I
was referring to was:
36:44 of http://llvm.org/devmtg/2012-04-12/videos/Reed_Kotler-mobile.mov
"there's not really more than a couple thousand lines of .td ... I mean
there's not tons of this code so if we had to use a different one I don't
think it would be a huge problem"

On Mon, Jun 4, 2012 at 9:01 PM, Reed Kotler <rkotler at mips.com> wrote:

>  Hi Sean,
>
> Glad to hear there is clean up of tablegen going on.
>
> Just for the record, I don't know what you are referring to regarding some
> comment of mine
> at my talk about 10K LOC.
>
> I don't know how big tablegen is itself nor how much code has been written
> in it so I would not have ventured such a guess.
>
> The idea of totally replacing the tablegen language came up at the talk
> during the question and answer period and I was not optimistic about that
> possibility for various reasons.
>
> I will definitely get in touch with you about tablegen.
>
> Reed
>
>
> On 06/04/2012 08:48 PM, Sean Silva wrote:
>
> FWIW, I'm putting together (hopefully to be done by the end of this
> weekend) a substantial refactoring of the TableGen backend API along with
> shiny new documentation (reStructuredText with sphinx) of all of TableGen,
> including documentation about how to write backends and---depending on how
> adventurous I get---a more detailed coverage of the syntax.
>
>  Also, Reed, in your TableGen talk, IIRC, you guessed that there are
> maybe ~10KLOC of TableGen, and said something to the tune that it wasn't
> too late to move over to something new and better. There are over 100KLOC
> in TableGen files, so unfortunately a "flag day" transition to another
> language is out of the question.
>
>  Feel free to get in contact with me if you would like to discuss
> TableGen or related topics.
>
>  --Sean Silva
>
> On Mon, Jun 4, 2012 at 5:42 PM, reed kotler <rkotler at mips.com> wrote:
>
>> On 06/04/2012 05:17 PM, Daniel Berlin wrote:
>> > Can we get back to the substantive discussion about your ideas for
>> > lessening the technical debt?
>>
>>  The lessening requires enlisting people that are willing to do this as
>> opposed to doing fun science like cool optimization. I,for example, find
>> the documentaiton, cleanup and refactoring to be interesting so I don't
>> feel cheated to work on it as opposed to implementing some new fangled
>> register allocator.
>>
>> For example, there is almost no documentation on all the application
>> specific plugins for tablegen.
>> There are some tablegen files and some small comments here and there and
>> you can guess
>> some of it from just knowing about compilers but it's nothing close to
>> what could be called
>> documentation.
>>
>> I've started on my own to try and further document tablegen. I gave a
>> talk/tutorial at LLVM
>> Europe on the general tablegen language and it was well received. Even
>> people that had worked
>> with it for a while said they took away things they never understood
>> about it.
>>
>> It was clear when I studied tablegen that there are many serious
>> problems with it from a language
>> point of view and from a tool point view. Those things would all need to
>> be cleared up before
>> some bigger form of it that could go beyond just laying out data
>> structures could be
>> developed.
>>
>> If there is sufficient interest, I think that maybe a separate
>> discussion list to deal with technical
>> debt would make sense. I think for a lot of people it would be
>> uninteresting to get all those
>> extra posts.
>>
>> It's a question of enlisting people that want to work on it and
>> convincing people that are not interested to work on it that it's
>> something important to do and to welcome the help and
>> not obstruct the effort.
>>
>> So far I have created some google code projects for various things I'm
>> interested to work on.
>> I've created separate google code projects because I don't have the
>> bandwidth to work on this
>> if there is resistance to it. So in my google code areas, I can do what
>> I want without a big
>> discussion on every step. So maybe only my team will use it and then it
>> can just sit in google code
>> forever.
>>
>> So there is a cutting edge of the llvm/clang project which will never
>> want to wait for all the technical debt to get paid. This is a natural
>> thing. You can't more forward trying to make everything be A+ quality;
>> you can only do the A+ work after some reflection and experience with a
>> given problem and rewriting and refactoring it many times. But at the
>> same time, the technical debt needs to be settled or it will get out of
>> hand and unpayable in the future.
>>
>> Reed
>>
>> > On Mon, Jun 4, 2012 at 8:05 PM, reed kotler<rkotler at mips.com>  wrote:
>> >> 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
>> >>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120604/48132fe5/attachment.html>