<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jan 5, 2017 at 9:49 AM Rafael Avila de Espindola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Chandler Carruth via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" class="gmail_msg" target="_blank">llvm-commits@lists.llvm.org</a>> writes:<br class="gmail_msg">
> For example, it seemed like a bug that GlobalDCE didn't consider comdat<br class="gmail_msg">
> participation of ifuncs. Specifically it seemed like an accident because<br class="gmail_msg">
> testing didn't really cover that case. But in fact, ifuncs specifically<br class="gmail_msg">
> cannot participate in a comdat despite having that API. The new test<br class="gmail_msg">
> case covers this and explicitly documents that DCE gets to fire here<br class="gmail_msg">
> even though there are comdats involved.<br class="gmail_msg">
<br class="gmail_msg">
I think your first impression was correct and you found a bug.<br class="gmail_msg">
<br class="gmail_msg">
Given just<br class="gmail_msg">
<br class="gmail_msg">
$test5_c = comdat any<br class="gmail_msg">
@test5_if = linkonce_odr ifunc void (), void ()* @test5_f<br class="gmail_msg">
define linkonce_odr void @test5_f() comdat($test5_c) {<br class="gmail_msg">
  ret void<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
llc produces<br class="gmail_msg">
<br class="gmail_msg">
        .weak   test5_if<br class="gmail_msg">
        .type   test5_if,@function<br class="gmail_msg">
        .type   test5_if,@gnu_indirect_function<br class="gmail_msg">
test5_if = test5_f<br class="gmail_msg">
<br class="gmail_msg">
which both gas and MC map to test5_f and test5_if having the same<br class="gmail_msg">
section and that section being in a comdat:<br class="gmail_msg">
<br class="gmail_msg">
COMDAT group section [    3] `.group' [test5_c] contains 1 sections:<br class="gmail_msg">
   [Index]    Name<br class="gmail_msg">
   [    4]   .text.test5_f<br class="gmail_msg">
<br class="gmail_msg">
Symbol table '.symtab' contains 6 entries:<br class="gmail_msg">
   Num:    Value          Size Type    Bind   Vis      Ndx Name<br class="gmail_msg">
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND<br class="gmail_msg">
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test.ll<br class="gmail_msg">
     2: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    3 test5_c<br class="gmail_msg">
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    4<br class="gmail_msg">
     4: 0000000000000000     1 FUNC    WEAK   DEFAULT    4 test5_f<br class="gmail_msg">
     5: 0000000000000000     1 IFUNC   WEAK   DEFAULT    4 test5_if<br class="gmail_msg">
<br class="gmail_msg">
So if this comdat is not selected, the linker will treat test5_f and<br class="gmail_msg">
test5_if as undefined.<br class="gmail_msg"></blockquote><div><br></div><div>I mean, that does indeed make sense. It seemed very odd for aliases to be in comdats but not ifuncs. However:</div><div><a href="https://github.com/llvm-project/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L157-L159">https://github.com/llvm-project/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L157-L159</a><br></div><div><br></div><div>Makes it clear that LLVM doesn't (yet) support this at all. =/ Maybe file a PR where this makes a difference and assign it to the folks who added ifunc support? The test case should get updated when the code above does.</div><div><br></div><div>-Chandler</div></div></div>