<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body 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.<br>
    <br>
    Reed<br>
    <br>
    On 06/04/2012 08:48 PM, Sean Silva wrote:
    <blockquote
cite="mid:CAHnXoa=YATr3+78zX-dNKJ9MdqERMpLCOoxJot-uvC1Kfs6EZw@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <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 class="im">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 class="HOEnZb"><font color="#888888"><br>
                Reed<br>
              </font></span>
            <div class="HOEnZb">
              <div class="h5"><br>
                > On Mon, Jun 4, 2012 at 8:05 PM, reed kotler<<a
                  moz-do-not-send="true" href="mailto:rkotler@mips.com">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">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">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">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">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>
  </body>
</html>