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

[Hal Finkel via llvm-dev]

On 10/09/2017 03:57 PM, Daniel Berlin 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.
>
> My guess is that we should go with mustmod.

I agree.

  -Hal

>
>
> 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 
> <mailto: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
>
>
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171009/939adbb4/attachment.html>