llvm dev - Jun 2016 - Tail call optimization is getting affected due to local function related optimization with IPRA

Sent from my iPhone
> On Jun 28, 2016, at 2:27 PM, Matthias Braun <matze at braunis.de>
wrote:
> 
> 
>> On Jun 28, 2016, at 10:09 AM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Jun 28, 2016, at 12:53 PM, vivek pandya <vivekvpandya at
gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at
apple.com> wrote:
>>>> 
>>>>> On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya
at gmail.com> wrote:
>>>>> 
>>>>> Hello ,
>>>>> 
>>>>> 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:
>>>>> 
>>>>> bool isEligibleForTailCallOptimization(Function *F) {
>>>>>   CallingConv::ID CC = F->getCallingConv();
>>>>>   if (CC == CallingConv::Fast || CC == CallingConv::GHC ||
CC == CallingConv::HiPE)
>>>>>     return true;
>>>>>   return false;
>>>>> }
>>>>> 
>>>>> Any other suggestions are always welcomed.
>>>> 
>>>> Why aren’t checking for the presence of a tail call?
>>> Are you asking about if tail call optimization is enable or not? 
If not then above method is inspired from X86ISelLowering::canGuaranteeTCO().
>>> 
>> 
>> Are we turning calls into tail calls during codegen?
>> My assumption is that tail call is inferred on the IR, so you can
inspect every *call site*.
> The final decision on whether to tail call or not is done during
instruction selection (it is part of
X86TargetLowering::LowerCall()/IsEligibleForTailCallOptimization() for example).
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?

-- 
Mehdi


> 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?
> 
> - Matthias
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/0f5c8f57/attachment.html>

> On Jun 28, 2016, at 11:34 AM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On Jun 28, 2016, at 2:27 PM, Matthias Braun <matze at braunis.de
<mailto:matze at braunis.de>> wrote:
> 
>> 
>>> On Jun 28, 2016, at 10:09 AM, Mehdi Amini via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>> On Jun 28, 2016, at 12:53 PM, vivek pandya <vivekvpandya at
gmail.com <mailto:vivekvpandya at gmail.com>> wrote:
>>> 
>>>> 
>>>> 
>>>> On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at
apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>>> 
>>>>> On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya
at gmail.com <mailto:vivekvpandya at gmail.com>> wrote:
>>>>> 
>>>>> Hello ,
>>>>> 
>>>>> 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:
>>>>> 
>>>>> bool isEligibleForTailCallOptimization(Function *F) {
>>>>>   CallingConv::ID CC = F->getCallingConv();
>>>>>   if (CC == CallingConv::Fast || CC == CallingConv::GHC ||
CC == CallingConv::HiPE)
>>>>>     return true;
>>>>>   return false;
>>>>> }
>>>>> 
>>>>> Any other suggestions are always welcomed.
>>>> 
>>>> Why aren’t checking for the presence of a tail call?
>>>> Are you asking about if tail call optimization is enable or
not?  If not then above method is inspired from
X86ISelLowering::canGuaranteeTCO().
>>>> 
>>> 
>>> Are we turning calls into tail calls during codegen?
>>> My assumption is that tail call is inferred on the IR, so you can
inspect every *call site*.
>> The final decision on whether to tail call or not is done during
instruction selection (it is part of
X86TargetLowering::LowerCall()/IsEligibleForTailCallOptimization() for example).
> 
> 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?
The backend does only tail call if the middleend marked the call with the
"tail" or "musttail" marker. But that happens for most
calls. We can only really transform a franction of those into real tail calls
later.

- Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/d38758ad/attachment.html>

> On Jun 28, 2016, at 3:01 PM, Matthias Braun <matze at braunis.de>
wrote:
> 
>> 
>> On Jun 28, 2016, at 11:34 AM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Jun 28, 2016, at 2:27 PM, Matthias Braun <matze at braunis.de
<mailto:matze at braunis.de>> wrote:
>> 
>>> 
>>>> On Jun 28, 2016, at 10:09 AM, Mehdi Amini via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>> 
>>>> 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On Jun 28, 2016, at 12:53 PM, vivek pandya <vivekvpandya at
gmail.com <mailto:vivekvpandya at gmail.com>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini
<mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>>>> 
>>>>>> On Jun 27, 2016, at 12:25 PM, vivek pandya
<vivekvpandya at gmail.com <mailto:vivekvpandya at gmail.com>>
wrote:
>>>>>> 
>>>>>> Hello ,
>>>>>> 
>>>>>> 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:
>>>>>> 
>>>>>> bool isEligibleForTailCallOptimization(Function *F) {
>>>>>>   CallingConv::ID CC = F->getCallingConv();
>>>>>>   if (CC == CallingConv::Fast || CC == CallingConv::GHC
|| CC == CallingConv::HiPE)
>>>>>>     return true;
>>>>>>   return false;
>>>>>> }
>>>>>> 
>>>>>> Any other suggestions are always welcomed.
>>>>> 
>>>>> Why aren’t checking for the presence of a tail call?
>>>>> Are you asking about if tail call optimization is enable or
not?  If not then above method is inspired from
X86ISelLowering::canGuaranteeTCO().
>>>>> 
>>>> 
>>>> Are we turning calls into tail calls during codegen?
>>>> My assumption is that tail call is inferred on the IR, so you
can inspect every *call site*.
>>> The final decision on whether to tail call or not is done during
instruction selection (it is part of
X86TargetLowering::LowerCall()/IsEligibleForTailCallOptimization() for example).
>> 
>> 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?
> 
> The backend does only tail call if the middleend marked the call with the
"tail" or "musttail" marker. But that happens for most
calls. We can only really transform a franction of those into real tail calls
later.
Thanks, so back to my original point: if we have to disable the CSR optimization
on function that “may be tail called”, it would still be better IMO to do
something like `llvm::any_of(callsites, isTailCall)` instead of
IsEligibleForTailCallOptimization().

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/75660b11/attachment.html>