[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