llvm dev - Oct 2017 - Expose aliasing information in getModRefInfo (or viceversa?)

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!
>
> 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/184808e8/attachment-0001.html>

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/1928dc88/attachment.html>

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>