[LLVMdev] technical debt

[reed kotler]

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