This is an archive of the discontinued LLVM Phabricator instance.

[FuncSpec] Use std::pow instead of operator^
ClosedPublic

Authored by ChuanqiXu on Jun 14 2021, 11:06 PM.

Details

Summary

The original implementation uses operator ^, which means XOR in C++ language.
At the first glance of reviewing, I thought it should be power, my bad.
It doesn't make sense to use XOR here. So I believe it should be a carelessness as I made.

Test Plan: check-all

Diff Detail

Event Timeline

ChuanqiXu created this revision.Jun 14 2021, 11:06 PM
ChuanqiXu requested review of this revision.Jun 14 2021, 11:06 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 14 2021, 11:06 PM
ChuanqiXu added inline comments.Jun 14 2021, 11:08 PM
llvm/test/Transforms/FunctionSpecialization/function-specialization-recursive.ll
41–42

Now it couldn't specialize recursiveFunc due to the change of cost model. I would try to fix it by considering branch condition in getUserBonus.

ChuanqiXu added inline comments.Jun 14 2021, 11:22 PM
llvm/lib/Transforms/IPO/FunctionSpecialization.cpp
274

Converting to double here is to reduce the ambitious reloading.

SjoerdMeijer added inline comments.Jun 15 2021, 12:38 AM
llvm/test/Transforms/FunctionSpecialization/function-specialization-loop.ll
3

Just checking, this test didn't trigger before, and now it does?
If so, would be good to precommit the test, then we can also see the differences better here.

llvm/test/Transforms/FunctionSpecialization/function-specialization-recursive.ll
41–42

I don't think it was able to specialise recursive (see also comment at the top).
I haven't looked very long at this, but something else must have led to different codegen.

ChuanqiXu added inline comments.Jun 15 2021, 12:45 AM
llvm/test/Transforms/FunctionSpecialization/function-specialization-loop.ll
3

Yeah, I had checked that.

llvm/test/Transforms/FunctionSpecialization/function-specialization-recursive.ll
41–42

Yeah, I think the title is confusing. Function Specialization only did simple specialization without considering recursiveness (I don't know the noun form). Then the change in this test case looks good to me.

ChuanqiXu added inline comments.Jun 15 2021, 1:15 AM
llvm/test/Transforms/FunctionSpecialization/function-specialization-loop.ll
3

Do you mean that send a NFC patch which contains the test case only? Then we tried to update this one, is it?

SjoerdMeijer accepted this revision.Jun 15 2021, 3:00 AM
SjoerdMeijer added inline comments.
llvm/test/Transforms/FunctionSpecialization/function-specialization-loop.ll
3

Yeah, I mean committing just the test first, then rebase this on top of that.
But with your confirmation that this now triggers and it didn't before, perhaps that's extra work we don't need, so you can commit this in one go.

This looks like a good fix to me.

This revision is now accepted and ready to land.Jun 15 2021, 3:00 AM
SjoerdMeijer added inline comments.Jun 15 2021, 3:03 AM
llvm/test/Transforms/FunctionSpecialization/function-specialization-loop.ll
4

Perhaps before committing rephrase this a bit:

check -> Check

and say something along the lines of:

Check that the loop depth results in a larger specialization bonus.
ChuanqiXu updated this revision to Diff 352089.Jun 15 2021, 3:41 AM

Address the comments.

This revision was automatically updated to reflect the committed changes.