[LLVMdev] technical debt

Daniel Berlin dberlin at dberlin.org
Mon Jun 4 17:17:51 PDT 2012


Can we get back to the substantive discussion about your ideas for
lessening the technical debt?

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
>>>
>




More information about the llvm-dev mailing list