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

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 9 13:57:03 PDT 2017


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.


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/6d10c910/attachment.html>


More information about the llvm-dev mailing list