<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 6, 2020, at 14:29, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><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" class="">zakk0610@gmail.com</a>> wrote:<br class=""></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" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> 於 2020年1月6日 週一 下午2:23寫道：<br class=""></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" class="">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 class=""><br class="">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 class=""></blockquote><div class=""><br class=""></div><div class="">Are you talking about that "<span style="white-space: pre-wrap;" class="">[mips] Pass ABI name via -target-abi instead of target-features"?</span></div></div></div></blockquote><div class=""><br class="">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 class=""><br class="">Might be interesting to know why that change was made & may help explain what's going on here.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>It's been a while so I don't remember the detail but IIRC one of the reasons was that mips had a feature bit per ABI and had a lot of duplicated code sanity checking that only one bit was enabled and deriving the ABI from the feature bits. The -target-abi option already existed and using that prevented the possibility of having more than one ABI selected.</div><div><br class=""></div><div>There was a lot of code (some of which didn't have access to target features) in the backend that tried to derive the ABI from the arch component of the triple (e.g. mips64 => n64 ABI) even though there were multiple possible ABI's for each arch (mips64 => o32, n32, or n64 ABI's) and there isn't a canonical choice for any given triple (it varies between linux distributions and toolchains in general). Settling on -target-abi allowed us to sort out the inconsistencies in the backends opinion of what the selected ABI was. It also allowed us to move the selection of the ABI into the frontend where disagreements between distributions/toolchains on what each triple means was easier to deal with.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_quote"><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" class=""><div class="gmail_quote"><div class=""><span style="white-space: pre-wrap;" class="">I don't know WHY -target-abi is passing via different option, not via -mattr (subtarget feature)</span><br class=""></div><div class=""><span style="white-space: pre-wrap;" class="">maybe usually subtarget feature is used to </span>manages different specific ISA.</div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""> </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" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></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" class="">Hi all.<div class=""><br class=""><div class="">There are two steps in LTO codegen so the problem is how to pass ABI info into LTO code generator. <br class=""></div><div class=""><br class=""></div><div class="">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" class="">https://reviews.llvm.org/D71387#1792169</a>)</div><div class=""><br class=""></div><div class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">1. <a href="https://reviews.llvm.org/D72245#change-sHyISc6hOqcy" target="_blank" class="">https://reviews.llvm.org/D72245#change-sHyISc6hOqcy</a> (see llc.cpp<span style="font-family: "Segoe UI", "Segoe UI Emoji", "Segoe UI Symbol", Lato, "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: 700;" class="">)</span></div><div class="">2. <a href="https://reviews.llvm.org/D72246" target="_blank" class="">https://reviews.llvm.org/D72246</a> (see RISCVAsmBackend.h)</div><div class=""><br class=""></div><div class="">I think [1] and [2] are not good enough, the other ideals like<br class=""></div><div class=""><br class=""></div><div class="">3. encode target abi info in triple name. ex. riscv64-unknown-elf-lp64d</div><div class="">4. encode target-abi into in target-feature (maybe it's not a good ideal because mips reverted this approach </div><div class="">before. <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=227583" target="_blank" class="">http://llvm.org/viewvc/llvm-project?view=revision&revision=227583</a>)<br class=""></div><div class=""><br class=""></div><div class="">5. users should pass target-abi themselves. (append -Wl,-plugin-opt=-target-abi=ipl32f when compiling with
-mabi=ilp32f)<br class=""></div><div class=""><br class=""></div><div class=""></div><div class="">Is it a good idea to encode target-abi into bitcode? </div><div class="">If yes, is there another good approach to fix AsmBackend issue?</div><div class="">I’d appreciate <span class="">any</span> help or <span class="">suggestions</span>. <br class=""></div><div class=""><br class=""></div><div class="">Thanks.</div><div class=""><br class=""></div><div class="">-- <br class=""><div dir="ltr" class="">Best regards,<br class="">Kuan-Hsu<br class=""><br class=""><br class=""><br class=""></div></div></div></div></div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="">Best regards,<br class="">Kuan-Hsu<br class=""><br class=""><br class=""></div></div>
</blockquote></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></blockquote></div><br class=""></body></html>