<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2019, 2:39 PM Steven Wu <<a href="mailto:stevenwu@apple.com" target="_blank" rel="noreferrer">stevenwu@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Sep 18, 2019, at 10:24 AM, Steven Wu <<a href="mailto:stevenwu@apple.com" rel="noreferrer noreferrer" target="_blank">stevenwu@apple.com</a>> wrote:</div><br class="m_-6578991366402839359m_-4919042704586908864Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space">Hi Dwight<div><br></div><div>Thanks for the feedback. For the issue you reported, there has been few reviews trying to tweak the -mllvm option when using legacy LTO interfaces (myself included) but it never got enough traction to moving forward. Note how -tailcallopt is implemented as a -mllvm flag means that it is a debug option and probably not well tested. The option is also not stable which means it can be renamed without notification.</div></div></div></blockquote><div><br></div>Digging out the patch Teresa once pointed out to me: <a href="https://reviews.llvm.org/D19015" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D19015</a></div><div>It is really a two line change. If you build your own libLTO, it is a very patch to maintain downstream.</div><div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Thanks for linking this to me! I will try and see if I can get this to work because it might be the simplest short term solution so we can have something working. It is not ideal as a long term solution because I really don't want us to have to maintain a build of any of the components of llvm ourselves though. So I will respond below to your question and we can figure out the best long term solution.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>I also feel like passing -tailcallopt in the linker stage is kind of fragile. It is better to create an attribute (on function or callInst) to force tailcallopt and some compiler flag to generated that during IRGen.</div></div></div></blockquote><div><br></div>I think I missed you comments about `musttail`. Do you have any example to show why `musttail` doesn’t work for you? Is there anything we can do to make it work so we don’t need to rely on `-mllvm` options?</div><div><br></div><div>Steven</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The problem with musttail is that the behavior of the feature is that IR does not verify if it includes a musttail call where the caller and callee have different numbers of arguments or otherwise differ in certain respects. However, we need guaranteed tail calls for mutually recursive functions, which obviously may not have the same signature. I would love to be able to use musttail though. Maybe you could make musttail functions with a compatible calling convention use the same codepath as -tailcallopt, and then loosen the restrictions? I'm not really sure. I can foresee there might be problems with calling convention if the function was externally visible, but for our use case it should be fine if the looser musttail attribute only worked for functions local to a module, I think...</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>Steven<br><div><br><blockquote type="cite"><div>On Sep 18, 2019, at 10:09 AM, Dwight Guth <<a href="mailto:dwight.guth@runtimeverification.com" rel="noreferrer noreferrer" target="_blank">dwight.guth@runtimeverification.com</a>> wrote:</div><br class="m_-6578991366402839359m_-4919042704586908864Apple-interchange-newline"><div><div dir="auto" style="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;text-decoration:none"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2019, 11:57 AM Teresa Johnson <<a href="mailto:tejohnson@google.com" rel="noreferrer noreferrer" target="_blank">tejohnson@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Dwight,<div><br></div><div>Welcome to LLVM-dev! A few comments below. Cc'ing a few people who hopefully can add info on some of the specific issues here.</div><div><br></div><div>Teresa</div></div><br><div class="gmail_quote"></div><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2019 at 9:04 AM Dwight Guth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Hi,<br></div><div dir="ltr"><div><br></div><div>I am lead developer of a project that is using LLVM to implement an ahead-of-time compiled functional language. We use llc -tailcallopt to ensure that functions that end in a tail call are compiled to a tail call at the machine level, because we have a number of cases in our interpreter where functions with different function signatures call one another in deeply nested recursive calls.</div></div></div></div></blockquote><div><br></div><div>Maybe a naive question - would that be fixable?</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I doubt that we can get around this easily. It's a programming language compiler, so the guarantee that if the user writes a tail call in their code, they will get a tail call at the machine level is pretty important. Restricting that guarantee to only functions that call themselves would probably cause a lot of problems, including stack overflows, for code written in our programming language. Recursion is basically the only way to loop in most functional languages; that's why the tailcallopt flag was created.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr"><div>We can't use `musttail` because the callee and caller often have different signatures.</div><div><br></div><div>We would like to support link time optimization in our programming language, because performance is important to us. However, there is no clang flag to enable the GuaranteedTailCallOpt flag, and the only way to pass target options to the lto plugin currently is via an unsupported API that parses those flags to static variables.</div></div></div></div></blockquote><div><br></div><div>I assume you mean passing internal options via -mllvm through the linker?</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes that's correct, we are passing -mllvm -tailcallopt to lld on Linux.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr"><div>This works on Linux, but the Mac OS linker does not actually initialize the TargetOptions that it passes as an llvm::lto::Config based on the parsed static variables, and Apple is uninterested in spending time supporting an unsupported LLVM API like -mllvm (understandably).</div></div></div></div></blockquote><div><br></div><div>lto::Config is part of the new LTO API. For the most part ld64 uses the old legacy LTO API, and therefore does not even use llvm::lto::Config (the one exception is to share the code for computing a cache key). But it doesn't use this when invoking the code generation passes. I'm surprised that ld64 would not have a way to pass through internal llvm options - presumably that is necessary for debugging and tuning. <a class="gmail_plusreply" id="m_-6578991366402839359m_-4919042704586908864m_-1985895300951367165m_5552590222737411273m_1307007006384030996plusReplyChip-0" href="mailto:stevenwu@apple.com" rel="noreferrer noreferrer noreferrer" target="_blank">+Steven Wu</a> to give more info here (I work on Linux code and therefore have only directly used gold and lld, which both use the new LTO API).</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">ld64 does have an -mllvm flag but when you pass -mllvm -tailcallopt, it will happily parse this flag, but it ignores the resulting value when initializing the code generator, and when I reported the issue to Apple, they said they would not fix it because -mllvm is not an officially supported API.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr"><div><br></div><div>Is there a change to the LLVM project that you might be willing to accept that we might be able to create a patch for that would allow us to get link time optimization enabled in our programming language on Mac OS, at least in the future? And if so, is it possible that someone could give me pointers on how to proceed? I'm a relative novice studying this code and I'm not really sure how all the components fit together at a high level and thus what the correct design for something like this would be.</div></div></div></div></blockquote><div><br></div><div>I guess the question is what interface would work for you. Would passing an internal option like what works on lld or what you are doing with llc be acceptable?</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, this would be fine with us, if it's possible. How would I go about making this happen?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>If you need a more officially supported mechanism, IMO the best way is probably to create a new function attribute (e.g. 'forcetailcall' or something equivalent to what GuaranteedTailCallOpt implies). That would be completely linker agnostic and also not rely on internal options.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr"><div><br></div><div>Or am I going to have to resign myself to waiting until lld is well supported at linking mach-o files?</div></div></div></div></blockquote><div><br></div><div><a class="gmail_plusreply" id="m_-6578991366402839359m_-4919042704586908864m_-1985895300951367165m_5552590222737411273m_1307007006384030996plusReplyChip-1" href="mailto:ruiu@google.com" rel="noreferrer noreferrer noreferrer" target="_blank">+Rui Ueyama</a> and </div><div><a class="gmail_plusreply" id="m_-6578991366402839359m_-4919042704586908864m_-1985895300951367165plusReplyChip-3" href="mailto:echristo@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">+Eric Christopher</a> to comment on lld Mach-O support.</div><div><br></div><div>Teresa</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr"><div><br></div><div>Thanks,<br></div><div><div><br>--<span class="m_-6578991366402839359m_-4919042704586908864Apple-converted-space"> </span><br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial,helvetica,sans-serif"><span style="font-size:12pt;background-color:transparent;font-weight:400;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Dwight Guth</span></span></div><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial,helvetica,sans-serif"><span style="font-size:10pt;color:rgb(0,153,204);background-color:transparent;font-weight:700;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Director of Engineering<br></span></span></div><span style="font-family:arial,helvetica,sans-serif"><br></span><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial,helvetica,sans-serif"><span style="font-size:10pt;background-color:transparent;font-weight:400;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Email: <a href="mailto:dwight.guth@runtimeverification.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">dwight.guth@runtimeverification.com</a></span></span></div><span style="font-family:arial,helvetica,sans-serif"><br></span><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href="https://www.runtimeverification.com/" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank"><span style="font-family:arial,helvetica,sans-serif"><span style="font-size:10pt;background-color:transparent;font-weight:400;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><img width="127" height="29" style="border:medium none"></span></span></a></div><span style="font-family:arial,helvetica,sans-serif"><br></span><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial,helvetica,sans-serif"><a href="https://github.com/dwightguth" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" style="text-decoration:none" target="_blank"><span style="font-size:11pt;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap"><img width="22" height="22" style="border:medium none"></span></a><span style="font-size:11pt;background-color:transparent;font-weight:400;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"> </span><a href="https://www.linkedin.com/company/3142238/" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" style="text-decoration:none" target="_blank"><span style="font-size:11pt;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap"><img width="22" height="22" style="border:medium none"></span></a><span style="font-size:11pt;background-color:transparent;font-weight:400;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">  </span><a href="https://twitter.com/rv_inc" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" style="text-decoration:none" target="_blank"><span style="font-size:11pt;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap"><img width="23" height="23" style="border:medium none"></span></a></span></div><span style="font-family:arial,helvetica,sans-serif"><br></span><br><br><br></div></div></div></div></div></div></div></div></div>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></blockquote><br clear="all"><div><br></div>--<span class="m_-6578991366402839359m_-4919042704586908864Apple-converted-space"> </span><br><div dir="ltr"><div dir="ltr"><div><span style="font-family:Times;font-size:inherit"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-width:2px;border-top-style:solid;border-top-color:rgb(213,15,37)">Teresa Johnson |</td><td nowrap style="border-top-width:2px;border-top-style:solid;border-top-color:rgb(51,105,232)"> Software Engineer |</td><td nowrap style="border-top-width:2px;border-top-style:solid;border-top-color:rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" rel="noreferrer noreferrer noreferrer" target="_blank">tejohnson@google.com</a> |</td></tr></tbody></table></span></div></div></div></div></blockquote></div></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></blockquote></div></div></div>