<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 21, 2014, at 4:32 PM, Akira Hatanaka <<a href="mailto:ahatanak@gmail.com" class="">ahatanak@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Is there a way to distinguish between GlobalValues that are user-defined and those that are compiler-defined? I am looking for a function that I can use to tell if a GlobalValue is user-defined , something like "GlobalValue::isUserDefined", which returns true for user-defined GlobalValue.<div class="">
<div class=""><br class=""></div><div class="">I'm trying to make changes to prevent llvm from placing user-defined constant arrays in the merge able constant sections. Currently, clang places 16-byte constant arrays that are marked "unnamed_addr" into __literal16 for macho (see following example).</div>
<div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">$ cat test1.c</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">static const int s_dashArraysSize1[4] = {2, 2, 4, 6};</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">int foo1(int a) {</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">  return s_dashArraysSize1[a]; </div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">}</div></div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">$ clang test1.c -S -O3 -o - | tail -n 10</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""><span class="" style="white-space:pre"> </span>.section<span class="" style="white-space:pre">  </span>__TEXT,__literal16,16byte_literals</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""><span class="" style="white-space:pre">  </span>.align<span class="" style="white-space:pre">    </span>4                       ## @s_dashArraysSize1</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">_s_dashArraysSize1:</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""><span class="" style="white-space:pre">       </span>.long<span class="" style="white-space:pre">     </span>2                       ## 0x2</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""><span class="" style="white-space:pre">       </span>.long<span class="" style="white-space:pre">     </span>2                       ## 0x2</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""><span class="" style="white-space:pre">       </span>.long<span class="" style="white-space:pre">     </span>4                       ## 0x4</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""><span class="" style="white-space:pre">       </span>.long<span class="" style="white-space:pre">     </span>6                       ## 0x6</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">
<br class=""></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""><br class=""></div><div class="">This is not desirable because macho linker wasn't originally designed to handle user-defined symbols in those sections and having to handle them complicates the linker. Also, there is no benefit in doing so, since the linker currently doesn't try to merge user-defined variables anyway.</div></div></div></div></div></blockquote><br class=""></div><div>I would also appreciate opinions on whether this issue is relevant for other platforms. In general, should we put user-defined symbols into literal sections?</div><div><br class=""></div><div>In Akira’s example above, GlobalOpt is checking that the variable does not have its address taken and marking them it unnamed_addr. Even if that is a legal optimization, it may cause problems, e.g., for debugging, if the linker removes the symbol. I don’t know whether other linkers will keep all the symbols in literal sections or not. I think you could also make a reasonable argument that we don’t guarantee that the variable will remain visible when debugging optimized code.</div></body></html>