<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Jun 28, 2016, at 2:27 PM, Matthias Braun <<a href="mailto:matze@braunis.de">matze@braunis.de</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 28, 2016, at 10:09 AM, Mehdi Amini 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 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-stroke-width: 0px;" class=""><br class=""><br class="">Sent from my iPhone</div><div 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-stroke-width: 0px;" class=""><br class="">On Jun 28, 2016, at 12:53 PM, vivek pandya <<a href="mailto:vivekvpandya@gmail.com" class="">vivekvpandya@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" 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;" class=""><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 27, 2016, at 12:25 PM, vivek pandya <<a href="mailto:vivekvpandya@gmail.com" target="_blank" class="">vivekvpandya@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hello ,<div class=""><br class=""></div><div class="">To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this:</div><div class=""><br class=""></div><div class=""><div class="">bool isEligibleForTailCallOptimization(Function *F) {</div><div class=""> CallingConv::ID CC = F->getCallingConv();</div><div class=""> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE)</div><div class=""> return true;</div><div class=""> return false;</div><div class="">}</div></div><div class=""><br class=""></div><div class="">Any other suggestions are always welcomed.</div></div></div></blockquote><div class=""><br class=""></div></span>Why aren’t checking for the presence of a tail call?</div></div></blockquote><div class="">Are you asking about if tail call optimization is enable or not? If not then above method is inspired from X86ISelLowering::canGuaranteeTCO(). </div><div class=""><br class=""></div></div></div></div></div></blockquote><div 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-stroke-width: 0px;" class=""><br class=""></div><div 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-stroke-width: 0px;" class="">Are we turning calls into tail calls during codegen?</div><div 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-stroke-width: 0px;" class="">My assumption is that tail call is inferred on the IR, so you can inspect every *call site*.</div></div></blockquote><div>The final decision on whether to tail call or not is done during instruction selection (it is part of X86TargetLowering::LowerCall()/IsEligibleForTailCallOptimization() for example).</div></div></div></blockquote><div><br></div><div>Sorry i don't have access to the source code right now, can you clarify if the backend can tail call when the IR didn't mark the call as such, or if what you're referring to is "not honoring the tail call From the IR and demoting to a normal call?</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><br><blockquote type="cite"><div><div><div>The decision there also takes the callee saved registers into account, but as you can see it is using TRI->getCallPreservedMask() which is different from the stuff computed by the IPRA analysis. Maybe it would be best to somehow get the compute regmask into LowerCall() and isEligibleForTailCallOptimization() instead of changing the regmask in a separate pass afterwards?</div><div><br class=""></div><div>- Matthias</div><div><br class=""></div></div></div></blockquote></body></html>