<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 6, 2020 at 5:58 AM Zakk <<a href="mailto:zakk0610@gmail.com">zakk0610@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> 於 2020年1月6日 週一 下午2:23寫道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">If this is something that can vary per file in a compilation and resolve correctly when one object file is built with one ABI and another object file is built with a different ABI (that seems to be antithetical to the concept of "ABI" Though) - then it should be a subtarget feature.<br><br>ABI is generally something that has to be agreed upon across object files - so it wouldn't make sense to link two object files with two different ABIs. What's going on here that makes that valid in this case?</div><br></blockquote><div><br></div><div>Are you talking about that "<span style="color:rgb(0,0,0);white-space:pre-wrap">[mips] Pass ABI name via -target-abi instead of target-features"?</span></div></div></div></blockquote><div><br>I'm not talking about that patch in particular (I have no specific knowledge of mips or its implementation) - but speaking about the general design of LLVM's subtarget features.<br><br>Might be interesting to know why that change was made & may help explain what's going on here.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><span style="color:rgb(0,0,0);white-space:pre-wrap">I don't know WHY -target-abi is passing via different option, not via -mattr (subtarget feature)</span><br></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">maybe usually subtarget feature is used to </span>manages different specific ISA.</div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 5, 2020 at 10:04 PM Zakk 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all.<div><br><div>There are two steps in LTO codegen so the problem is how to pass ABI info into LTO code generator. <br></div><div><br></div><div>The easier way is pass -target-abi via option to LTO codegen, but there is linking issue when linking two bitcodes generated by different -mabi option. (see <a href="https://reviews.llvm.org/D71387#1792169" target="_blank">https://reviews.llvm.org/D71387#1792169</a>)</div><div><br></div><div><div>Usually the ABI info  for a file is derived from target triple, mcpu or -mabi, but in RISC-V, target-abi is only derived from -mabi and -mattr option, so the one of solutions is encoding target-abi in IR via LLVM module flags metadata.</div><div><br></div><div>But there is an another issue in assembler. In current LLVM design, there is no mechanism to extract info from IR before AsmBackend construction, so I  use some little weird approach to init target-abi option before construct AsmBackend[1] or reassign target-abi option in 

getSubtargetImpl 

and do some hack in backend[2].</div><div><br></div><div>1. <a href="https://reviews.llvm.org/D72245#change-sHyISc6hOqcy" target="_blank">https://reviews.llvm.org/D72245#change-sHyISc6hOqcy</a> (see llc.cpp<span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:14px;font-weight:700">)</span></div><div>2. <a href="https://reviews.llvm.org/D72246" target="_blank">https://reviews.llvm.org/D72246</a> (see RISCVAsmBackend.h)</div><div><br></div><div>I think [1] and [2] are not good enough, the other ideals like<br></div><div><br></div><div>3. encode target abi info in triple name. ex. riscv64-unknown-elf-lp64d</div><div>4. encode target-abi into in target-feature (maybe it's not a good ideal because mips reverted this approach </div><div>before. <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=227583" target="_blank">http://llvm.org/viewvc/llvm-project?view=revision&revision=227583</a>)<br></div><div><br></div><div>5. users should pass target-abi themselves. (append -Wl,-plugin-opt=-target-abi=ipl32f when compiling with 

-mabi=ilp32f)<br></div><div><br></div><div></div><div>Is it a good idea to encode target-abi into bitcode? </div><div>If yes, is there another good approach to fix AsmBackend issue?</div><div>I’d appreciate <span>any</span> help or <span>suggestions</span>.  <br></div><div><br></div><div>Thanks.</div><div><br></div><div>-- <br><div dir="ltr">Best regards,<br>Kuan-Hsu<br><br><br><br></div></div></div></div></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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Best regards,<br>Kuan-Hsu<br><br><br></div></div>
</blockquote></div></div>