[PATCH] optimize MachineBasicBlock::getSymbol a bit

Eli Bendersky eliben at google.com
Mon Apr 22 10:41:08 PDT 2013


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







> On Apr 22, 2013, at 9:14 AM, Eli Bendersky <eliben at google.com> wrote:
>
> Ping!
>
>
> On Thu, Apr 18, 2013 at 3:27 PM, Eli Bendersky <eliben at google.com> wrote:
>
>> MachineBasicBlock::getSymbol gets called quite a lot and was doing a lot
>> of repetitive work. Most of the symbol remains unchanged between MBBs in
>> the same function, and yet getSymbol was laboriously reconstructing the
>> full symbol with a concatenation of Twines. This patch optimizes this away:
>> MachineFunction caches the symbol "template" for its MBBs and does a
>> minimal amount of work to generate a new symbol without too much copying.
>>
>> There's no change in functionality, but this makes
>> MachineBasicBlock::getSymbol somewhere between 25-50% faster (exact numbers
>> are hard to obtain for this very internal method).
>>
>> Please take a look,
>> Eli
>>
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130422/8a815b83/attachment.html>


More information about the llvm-commits mailing list