[PATCH] optimize MachineBasicBlock::getSymbol a bit

Eli Bendersky eliben at google.com
Mon Apr 22 13:23:56 PDT 2013


On Mon, Apr 22, 2013 at 10:41 AM, Eli Bendersky <eliben at google.com> wrote:

> On Mon, Apr 22, 2013 at 10:20 AM, Chris Lattner <clattner at apple.com>wrote:
>
>> Hi Eli,
>>
>> What is the specific problem here?  Is the cost to compute this too high,
>> or is the symbol requested for the same MBB multiple times?  If it is the
>> latter, it should be enough to add a simple "MCSymbol*" cache to MBB.  This
>> would be cleaner than adding a scratch buffer to MachineFunction.
>>
>> -Chris
>>
>>
> Hi Chris,
>
> My fix addresses the first problem: multiple MBBs in the same MF
> recomputing the same information, which is wasteful.
> You're raising a good point that there may be another problem hiding here
> - this computation being done multiple times for a single MBB. In that
> case, a cache can be added, yes. I'll take a look if this is indeed a
> problem. In any case, the patch still addresses a slightly different
> problem of caching most of the computation between different MBBs.
>
> Eli
>

Hi Chris,

I did a bit more measuring, implementing also rudimentary caching of the
MCSymbol as you suggested. The results suggest that a large part of the
cost comes from symbol requests in the same MBB multiple times, and both
solutions mitigate that (my original patch simply by virtue of making the
computation much cheaper). The numbers are:

baseline runtime of all getSymbol calls combined (no patches): B
with original (scratch buffer in MC) patch: ~0.75B
with caching MCSymbol patch: ~0.75B
with both patches: ~0.7B

Given this, do you think it's worth it to apply both patches? If not then I
agree that caching MCSymbol is the cleaner way to go.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130422/e3bc5225/attachment.html>


More information about the llvm-commits mailing list