<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 Aug 29, 2020, at 6:53 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="Singleton"><blockquote type="cite" cite="mid:0489E46F-1111-4134-8428-01859A4615D5@nondot.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class=""><br class="Apple-interchange-newline">Sorry for the delay responding Leonard. I don’t really understand your rationale here. A PLT entry is a completely target specific concept because some targets don’t have PLTs. I don’t think there is any reason that a frontend would abstractly generate this unless they already have a target-specific plan in mind.</div><div class=""><br class=""></div><div class="">If you go with your “unnamedfunc” approach, you’ll have to define the semantics of what that means, and it will need to mean something on targets without a PLT. If it isn’t generally implementable, then it is target specific again.</div><div class=""><br class=""></div><div class="">I feel like you are trying (earnestly!) to make the IR better here, but by making this abstract it is actually just making it more opaque for no obvious benefit.</div></blockquote><p style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></p><p style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">+1 to this. LLVM already has a large issue with implicit ABI contracts between Clang (and other frontends) and the various backends. We should not make that worse. The problem here is that there are multiple ways to represent the reference to the function symbol, and in this case, there's an ABI requirement to pick a specific one of them. We should make that clear and explicit. If there's an abstraction here that's useful, it's in the way to pass along that target-specific information -- I think of this like a target-specific attribute.</p></div></div></blockquote>Completely agreed, a lot of my perspective comes from bitter experience having messed up the ABI lowering design :-). Sorry for that :)</div><div><br class=""></div><div>-Chris</div></body></html>