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

[Alina Sbirlea via llvm-dev]

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>