[llvm-dev] Tail call optimization is getting affected due to local function related optimization with IPRA
vivek pandya via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 29 09:25:40 PDT 2016
On Wed, Jun 29, 2016 at 9:51 PM, vivek pandya <vivekvpandya at gmail.com>
wrote:
> I have tried out the following code which examines each call site in a
> module for tail call and do not perform optimization in such case:
>
bool RegUsageInfoCollector::isEligibleForTailCallOptimization(Function *F) {
const Module *M = F->getParent();
for (const Function &Fu : *M)
for (const BasicBlock &BB : Fu)
for (const Instruction &II : BB) {
if (auto CS = ImmutableCallSite(&II))
if (CS.getCalledFunction() == F && CS.isTailCall()) {
outs() << "Function : " << F->getName() << " is tailCall\n";
return true;
}
}
return false;
}
This allows many static function from sqlite3 code to be a candidate for
local function optimization (that is good compare to previous attempt) but
it fails at runtime. I will analyze it but before that I have test-case
which fails at -O2 but when I try -O2 -finline-hint-functions it works I am
currently analyzing it.
-Vivek
> On Wed, Jun 29, 2016 at 12:34 AM, Mehdi Amini <mehdi.amini at apple.com>
> wrote:
>
>>
>> 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> wrote:
>>
>>
>>
>> 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?
>>
>>
>> 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/20160629/d0ff8519/attachment.html>
More information about the llvm-dev
mailing list