<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 3, 2017 at 2:37 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <div class="m_8780138701776340653moz-cite-prefix">On 10/03/2017 04:30 PM, Eric
      Christopher wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr"><br>
        <br>
        <div class="gmail_quote">
          <div dir="ltr">On Tue, Oct 3, 2017 at 8:54 AM Hal Finkel via
            llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <p><br>
              </p>
              <div class="m_8780138701776340653m_3858040240877242542moz-cite-prefix">On
                10/02/2017 10:57 PM, Matthias Braun via llvm-dev wrote:<br>
              </div>
              <blockquote type="cite"> The distinction between the
                LLVMTargetMachine and TargetMachine classes has become
                somewhat muddy recently. So I created:
                <div><br>
                </div>
                <div><a href="https://reviews.llvm.org/D38482" target="_blank">https://reviews.llvm.org/D38482</a></div>
                <div><br>
                </div>
                <div>to clean things up. During review it was noted that
                  we may rather merge the two instead which looks like
                  this:</div>
                <div><br>
                </div>
                <div><a href="https://reviews.llvm.org/D38489" target="_blank">https://reviews.llvm.org/D38489</a></div>
                <div><br>
                </div>
                <div>We really should choose one of the two over the
                  status quo. Some points for the discussion:</div>
                <div><br>
                </div>
                <div>- I am not aware of any target that is actually
                  implementing TargetMachine only but not
                  LLVMTargetMachine (I assume the C backend used to do
                  it before it was removed)</div>
                <div>- Even when merging the two, I believe it is still
                  possible to implement a target without linking to
                  lib/CodeGen by returning nullptr for the various
                  methods related to CodeGen.</div>
              </blockquote>
              <br>
            </div>
            <div bgcolor="#FFFFFF" text="#000000"> If this is true, then
              it seems like we don't lose anything from doing this (and
              the code gets cleaner). We don't currently have anything
              in tree that </div>
          </blockquote>
          <div><br>
          </div>
          <div>This was my suggestion of yesterday.</div>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">motivates the current
              split. It does seem useful to retain the ability to have a
              direct-from-the-IR backend (mostly for translation into
              another IR).<br>
              <br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>I'm dubious of this need, but as long as it doesn't add
            any overhead to the resultant code I'm good.</div>
        </div>
      </div>
    </blockquote>
    <br></div><div bgcolor="#FFFFFF" text="#000000">
    The other thing that I asked in the other review thread, which I'll
    repeat here, is: does GlobalISel further reduce the motivation for
    this? The primary reason, as I understand it, for needing this kind
    of "direct" translation is to avoid going through type legalization.
    This can be important for software targeting FPGAs, for example,
    because the hardware can deal with arbitrary bit widths. With
    GlobalISel, can you go into CodeGen effectively without any
    legalization and then go on from there (if one needed such a thing)?<br>
    <br></div></blockquote><div><br></div><div>Not right now, no.</div><div> </div><div>That said I'm uncertain how much we particularly care about keeping two classes here when we can just change how initialization works to provide nullptr versions of the local bits rather than having a separate overhead class.</div><div><br></div><div>-eric</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
     -Hal</div><div bgcolor="#FFFFFF" text="#000000"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>-eric</div>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">  -Hal</div>
            <div bgcolor="#FFFFFF" text="#000000"><br>
              <br>
              <blockquote type="cite">
                <div>- The split would give some notion of an internal
                  CodeGen interface and an external interface visible to
                  frontend/middleend etc.</div>
                <div>- The code gets simpler when merging the two and we
                  have to document/explain less.</div>
                <div><br>
                </div>
                <div>- Matthias</div>
                <br>
                <fieldset class="m_8780138701776340653m_3858040240877242542mimeAttachmentHeader"></fieldset>
                <br>
                <pre>_______________________________________________
LLVM Developers mailing list
<a class="m_8780138701776340653m_3858040240877242542moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_8780138701776340653m_3858040240877242542moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
              </blockquote>
              <br>
            </div>
            <div bgcolor="#FFFFFF" text="#000000">
              <pre class="m_8780138701776340653m_3858040240877242542moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
            </div>
            _______________________________________________<br>
            LLVM Developers mailing list<br>
            <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
            <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
    <pre class="m_8780138701776340653moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </div></blockquote></div></div>