[llvm-dev] Expose aliasing information in getModRefInfo (or viceversa?)

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 9 19:05:15 PDT 2017


Yes, this is odd.

On my clang.bc

Without:
   2.2967 ( 53.8%)   0.0242 ( 26.4%)   2.3210 ( 53.2%)   2.3227 ( 53.2%)
Memory SSA
   2.3364 ( 53.7%)   0.0246 ( 25.7%)   2.3610 ( 53.1%)   2.3636 ( 53.1%)
Memory SSA
   2.3353 ( 54.0%)   0.0258 ( 27.0%)   2.3611 ( 53.4%)   2.3632 ( 53.3%)
Memory SSA

With two getModRefInfo calls:
   3.0302 ( 58.8%)   0.0328 ( 29.9%)   3.0630 ( 58.2%)   3.0858 ( 58.2%)
Memory SSA
   3.0097 ( 58.9%)   0.0325 ( 30.0%)   3.0422 ( 58.3%)   3.0590 ( 58.3%)
Memory SSA
   3.0486 ( 58.8%)   0.0317 ( 29.4%)   3.0804 ( 58.2%)   3.1331 ( 58.3%)
Memory SSA

with alias followed by getModRefInfo
   2.2487 ( 52.9%)   0.0259 ( 27.1%)   2.2746 ( 52.4%)   2.2820 ( 52.4%)
Memory SSA
etc


Not entirely sure what is going on.

But if alias is free, problem solved!


On Mon, Oct 9, 2017 at 4:05 PM, Alina Sbirlea <alina.sbirlea at gmail.com>
wrote:

> On Mon, Oct 9, 2017 at 2:08 PM, Alina Sbirlea <alina.sbirlea at gmail.com>
> wrote:
>
>> On Mon, Oct 9, 2017 at 1:57 PM, Daniel Berlin <dberlin at dberlin.org>
>> wrote:
>>
>>> FWIW:  Bootstrap is probably not a good test of this, there are bugs
>>> filed where we end up with tons of loads and stores to test against each
>>> other.  That's actually fairly rare in bootstrap, as you can see.
>>> Let me get you some test cases.
>>>
>>
>> SG, thanks!
>>
>
> I ran a few quick timings of "opt -memoryssa" for gvn_hoist.small.bc in
> PR28670/PR28832, and a larger version extracted then.
>
> Reporting:
> mssalimit    /  single call getModRef   /   call getModRef followed by
> alias().
>
> Smaller test hits the case with 2 alias calls 1282 times. Timings, average
> over 5-10 runs (s):
> 100 / 8.99 / 8.87
> 200 / 9.24 / 9.113
> 500 / 48.228 / 48.453
>
> Larger case hits it 1872 times. Timings, average over 5 runs (s):
> 100 / 23.575 / 23.962
> 200 /  23.874 / 23.848
>
>
> My guess is that we should go with mustmod.
>>>
>>>
>>> As for callsites, adding mustmod works for call, memloc and call, call
>>> testing.
>>>
>>
>>>
>>
>>>
>>> On Mon, Oct 9, 2017, 4:48 PM Alina Sbirlea <alina.sbirlea at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> This came up in https://reviews.llvm.org/D38569, and I'd like some
>>>> input on what's the best way to get alias and mod-ref info without having
>>>> two alias calls.
>>>>
>>>> A couple of ideas:
>>>> (a) Extend the getModRefInfo interface (+getModRefBehavior,
>>>> +gerArgModRefInfo) to return a pair {ModRefInfo, AliasResult}.
>>>>
>>>> The AliasResult can be optional based on an argument
>>>>      e.g.:
>>>>     struct MRI_AR { ModRefInfo MRI, AliasResult AR };
>>>>     MRI_AR getModRefInfoAlias (LoadInst *LI, MemoryLocation Loc, bool
>>>> SetAliasResultField);
>>>>
>>>> Add wrapper APIs to preserve current calls.
>>>>     e.g.:
>>>>      ModRefInfo getModRefInfo (LoadInst *LI, MemoryLocation Loc) {
>>>>           return getModRefInfoAlias (LI, Loc, false).MRI;
>>>>       }
>>>>
>>>> (b) From talking offline with George, introducing a MRI_MustMod in
>>>> ModRefInfo.
>>>>
>>>>
>>>> Open question: How to handle callsites.
>>>>
>>>>
>>>> In terms of whether this is worth doing, as a preliminary timing test I
>>>> timed the llvm bootstrap build with 1 vs 2 alias calls in D38569:
>>>> instructionClobbersQuery:296, and got the following:
>>>> 2 alias calls:
>>>> real    62m52.627s
>>>> user    2769m46.964s
>>>> sys     17m48.072s
>>>> 1 alias call:
>>>> real    62m56.659s
>>>> user    2766m40.452s
>>>> sys     17m46.312s
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> Thanks,
>>>> Alina
>>>>
>>>>
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171009/f6d1676e/attachment.html>


More information about the llvm-dev mailing list