<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 06/04/2012 10:00 PM, Sean Silva wrote:
<blockquote
cite="mid:CAHnXoamM4O2XbjYCs0DRxW0e15KWs7_7Fx=n75vGEeGNgh++zw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<div>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:</div>
</div>
36:44 of <a moz-do-not-send="true"
href="http://llvm.org/devmtg/2012-04-12/videos/Reed_Kotler-mobile.mov">http://llvm.org/devmtg/2012-04-12/videos/Reed_Kotler-mobile.mov</a>
<div>
"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"</div>
<div><br>
</div>
</blockquote>
hmm. that would have been a stupid thing to say if i said that.
well, i'd be rich if i had a dime<br>
for everything stupid thing i've said in my life.<br>
<br>
anyway, i agree that it's a non starter to think of just making a
wholesale change at this point.<br>
<br>
we would have to have a plan for such a change. <br>
<br>
the first step is to clean up and define the syntax and semantics of
what is already there in tablegen.<br>
<br>
at that an point evolutionary as opposed to revolutionary path of
changes could be possible.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAHnXoamM4O2XbjYCs0DRxW0e15KWs7_7Fx=n75vGEeGNgh++zw@mail.gmail.com"
type="cite">
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Mon, Jun 4, 2012 at 9:01 PM, Reed
Kotler <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rkotler@mips.com" target="_blank">rkotler@mips.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi Sean,<br>
<br>
Glad to hear there is clean up of tablegen going on.<br>
<br>
Just for the record, I don't know what you are referring
to regarding some comment of mine<br>
at my talk about 10K LOC.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I will definitely get in touch with you about tablegen.<span
class="HOEnZb"><font color="#888888"><br>
<br>
Reed</font></span>
<div>
<div class="h5"><br>
<br>
On 06/04/2012 08:48 PM, Sean Silva wrote:
<blockquote type="cite">
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Feel free to get in contact with me if you
would like to discuss TableGen or related topics.</div>
<div><br>
</div>
<div>--Sean Silva</div>
<div><br>
<div class="gmail_quote">On Mon, Jun 4, 2012 at
5:42 PM, reed kotler <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:rkotler@mips.com"
target="_blank">rkotler@mips.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>On 06/04/2012 05:17 PM, Daniel Berlin
wrote:<br>
> Can we get back to the substantive
discussion about your ideas for<br>
> lessening the technical debt?<br>
<br>
</div>
The lessening requires enlisting people that
are willing to do this as<br>
opposed to doing fun science like cool
optimization. I,for example, find<br>
the documentaiton, cleanup and refactoring to
be interesting so I don't<br>
feel cheated to work on it as opposed to
implementing some new fangled<br>
register allocator.<br>
<br>
For example, there is almost no documentation
on all the application<br>
specific plugins for tablegen.<br>
There are some tablegen files and some small
comments here and there and<br>
you can guess<br>
some of it from just knowing about compilers
but it's nothing close to<br>
what could be called<br>
documentation.<br>
<br>
I've started on my own to try and further
document tablegen. I gave a<br>
talk/tutorial at LLVM<br>
Europe on the general tablegen language and it
was well received. Even<br>
people that had worked<br>
with it for a while said they took away things
they never understood<br>
about it.<br>
<br>
It was clear when I studied tablegen that
there are many serious<br>
problems with it from a language<br>
point of view and from a tool point view.
Those things would all need to<br>
be cleared up before<br>
some bigger form of it that could go beyond
just laying out data<br>
structures could be<br>
developed.<br>
<br>
If there is sufficient interest, I think that
maybe a separate<br>
discussion list to deal with technical<br>
debt would make sense. I think for a lot of
people it would be<br>
uninteresting to get all those<br>
extra posts.<br>
<br>
It's a question of enlisting people that want
to work on it and<br>
convincing people that are not interested to
work on it that it's<br>
something important to do and to welcome the
help and<br>
not obstruct the effort.<br>
<br>
So far I have created some google code
projects for various things I'm<br>
interested to work on.<br>
I've created separate google code projects
because I don't have the<br>
bandwidth to work on this<br>
if there is resistance to it. So in my google
code areas, I can do what<br>
I want without a big<br>
discussion on every step. So maybe only my
team will use it and then it<br>
can just sit in google code<br>
forever.<br>
<br>
So there is a cutting edge of the llvm/clang
project which will never<br>
want to wait for all the technical debt to get
paid. This is a natural<br>
thing. You can't more forward trying to make
everything be A+ quality;<br>
you can only do the A+ work after some
reflection and experience with a<br>
given problem and rewriting and refactoring it
many times. But at the<br>
same time, the technical debt needs to be
settled or it will get out of<br>
hand and unpayable in the future.<br>
<span><font color="#888888"><br>
Reed<br>
</font></span>
<div>
<div><br>
> On Mon, Jun 4, 2012 at 8:05 PM, reed
kotler<<a moz-do-not-send="true"
href="mailto:rkotler@mips.com"
target="_blank">rkotler@mips.com</a>>
wrote:<br>
>> Well, differences of opinion is
what makes horse races.<br>
>><br>
>> Reed<br>
>><br>
>><br>
>> On 06/04/2012 04:57 PM, Daniel
Berlin wrote:<br>
>>> On Mon, Jun 4, 2012 at 7:53
PM, reed kotler<<a
moz-do-not-send="true"
href="mailto:rkotler@mips.com"
target="_blank">rkotler@mips.com</a>>
wrote:<br>
>>>> On 06/04/2012 03:25 PM,
Daniel Berlin wrote:<br>
>>>>> I'm pretty sure
neither llvm nor clang have any technical
debt at all.<br>
>>>>><br>
>>>>> On Mon, Jun 4, 2012
at 5:18 PM, reed kotler<<a
moz-do-not-send="true"
href="mailto:rkotler@mips.com"
target="_blank">rkotler@mips.com</a>>
wrote:<br>
>>>>>> something to
think about as llvm and clang grows.<br>
>>>>>><br>
>>>>>> <a
moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/Technical_debt"
target="_blank">http://en.wikipedia.org/wiki/Technical_debt</a><br>
>>>>>>
_______________________________________________<br>
>>>>>> LLVM Developers
mailing list<br>
>>>>>> <a
moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu"
target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu"
target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>>>> <a
moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>>> I hope you are joking.<br>
>>>><br>
>>> Why would I be joking?<br>
>>><br>
>>>> It's not meant as a
criticism of llvm or clang but there is
already an<br>
>>>> enormous amount<br>
>>>> of technical debt.<br>
>>> I don't see that.<br>
>>><br>
>>>> It's something to try and
get a handle on before it gets out of
hand.<br>
>>> The consequences will never
be the same<br>
>>>> Documentation is one area
where it is accumulating fast but there
are<br>
>>>> others.<br>
>>> I think LLVM is incredibly
well documented<br>
>>>> Testing is another area.<br>
>>> It also has at least 10-15
tests.<br>
>>>> Tablegen alone has huge
technical debt.<br>
>>> I'm sorry you feel that way.<br>
>>>> To me, there should be a
cap placed on the number of lines of code
in<br>
>>>> llvm.<br>
>>> Will there be a credit offset
system?<br>
>>>> Like a budget. We should
try and rewrite and refactor to keep the
number<br>
>>>> of<br>
>>>> lines from growing<br>
>>>> without bound.<br>
>>>><br>
>>>> At this point lots of
patterns should be developing where other
tools<br>
>>>> (like<br>
>>>> tablegen) could be<br>
>>>> written to reduce the
amount of code and make things more
understandable.<br>
>>> I agree. We should macroize
most of the passes so they aren't so
wordy.<br>
>>><br>
>>>> Reed<br>
>>>><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu"
target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu"
target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>