<div dir="ltr"><div dir="ltr">Hi Machiel,<div><br></div><div>I have requested that 84217ad6611 be merged into the LLVM 10 release branch in <a href="http://llvm.org/PR44700">http://llvm.org/PR44700</a>. It's a low-risk fix, so I'm hopeful that it will make it in.</div><div><br></div><div>-- Lang.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 24, 2020 at 8:06 AM Machiel van Hooren <<a href="mailto:jcmac@machiel.info">jcmac@machiel.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>I'm very pleased that PR40074/44337 has been squashed, great
      work! This means I can now use unmodified LLVM for my application
      and perhaps soon target a stable release. Will it be part of the
      LLVM 10 release?</p>
    <p>Machiel<br>
    </p>
    <div>On 24-Jan-20 04:27, Lang Hames via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi All,
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr">
              <div dir="ltr">
                <div dir="ltr">
                  <div dir="ltr">
                    <div dir="ltr">
                      <div dir="ltr">
                        <div dir="ltr">
                          <div dir="ltr">
                            <div><br>
                            </div>
                            <div>This week I've been focused on removing
                              some of the blockers for people
                              transitioning from ORCv1 to ORCv2.</div>
                            <div><br>
                            </div>
                            <div>Issue #1 (<a href="http://llvm.org/PR40074" target="_blank">http://llvm.org/PR40074</a>, <a href="http://llvm.org/PR44337" target="_blank">http://llvm.org/PR44337</a>):</div>
                            <div><br>
                            </div>
                            <div>When LLVM codegens floating point
                              constants for COFF we produce named
                              constant pool entries of the form
                              __real@<bitval>. These are stored in
                              COFF COMDAT sections [1] which allow
                              duplicate symbol definitions to be
                              discarded (roughly equivalent to the
                              concept of a weak symbol). This posed two
                              problems: (1) ORC had no idea about the
                              (rough) mapping between COMDAT and Weak,
                              and (2) did not support late introduction
                              of weak symbols via
                              MaterializationResponsibility::defineMaterializing.
                              This caused use of the same floating point
                              constant in multiple files to result in
                              duplicate definition errors for the
                              constant pool entries. </div>
                            <div><br>
                            </div>
                            <div>Both issues have been addressed in
                              84217ad6611, and floating point constants
                              should now work in COFF. If you run in to
                              any trouble with them please file a bug
                              and CC me.</div>
                            <div><br>
                            </div>
                            <div>Issue #2: Emulated TLS and name
                              mangling (raised by Geoff Levner on
                              llvm-dev):</div>
                            <div><br>
                            </div>
                            <div>Use of emulated-tls affects the name
                              mangling of LLVM IR symbols. For a thread
                              local symbol with name <Name>, when
                              emulated-tls is enabled we will produce at
                              least one emulated-tls symbol:
                              __emutls_v.<Name> (which must then
                              be linker-mangled to get the final symbol
                              name). If that symbol has a non-zero
                              initializer a second symbol will also be
                              produced: __emutls_t.<Name>. ORCv2
                              requires up-front specification of the
                              exact set of <i>linker-level</i> symbol
                              names that a module produces, so that it
                              can dispatch and track compiles, however
                              none of the existing mangling code took
                              emulated-tls into account. This has been
                              fixed in ce2207abaf9 (with follow up fixes
                              for the various examples I broke), and you
                              should now be able to use thread-locals in
                              ORCv2.</div>
                            <div><br>
                            </div>
                            <div>Besides these two bugs, I have
                              continued work on the big static
                              initializer patch. Unfortunately issue #2
                              interacts with it, so I have to do some
                              integration work before it is ready to
                              land, but I'm hopeful that it will be
                              ready some time next week.</div>
                            <div><br>
                            </div>
                            <div>Finally, I have added a new example
                              (bb7a5707ac0)to
                              llvm/examples/LLJITExamples:
                              LLJITWithObjectLinkingLayerPlugin
                              demonstrating how to write a custom
                              ObjectLinkingLayer plugin.
                              ObjectLinkingLayer plugins can be used to
                              receive and respond to events in the
                              linking layer, and to inspect and modify
                              JITLink LinkGraphs during the linking
                              process. ORC uses this internally to
                              register EH frames, but the system is
                              likely to be of interest to anyone who
                              wants low level control/visibility into
                              the JIT linker.</div>
                            <div><br>
                            </div>
                            <div>— Lang.</div>
                            <div><br>
                            </div>
                            <div>[1] <a href="https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#comdat-sections-object-only" target="_blank">https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#comdat-sections-object-only</a>  </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
  </div>

</blockquote></div>