[PATCH] D23214: [MDA] Treat invariant.start as non-dependence

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 8 09:16:24 PDT 2016


On Mon, Aug 8, 2016 at 6:40 AM, Anna Thomas <anna at azul.com> wrote:

> Right now, with the alias analysis change marking invariant.start as
> readonly, we do not  value forward to invariant.end (which is still
> readwrite).
>
> I'm quite aware, but what later happens is someone says "oh, these are the
same", and changes invariant.end, and without a test explicitly breaking,
they are likely to think it is okay :)


> Also, the only use of invariant.start is the corresponding
>

> However, the value forwarding will happen when invariant.end is marked
> readonly as well.
>
> foo = invariant.start(a)
> <stuff>
> bar = invariant.start(a)
> invariant.end (foo) <— was invariant.end(bar) initially
>
>
> Daniel,
>
> Even with the value forwarding , I think the “invariant set of statements”
> are not modified. We are not increasing/decreasing the number of “invariant
> uses" of %a, even though the range of statements within invariant.start and
> end for foo and bar has changed. I think this is true for any other case
> where the value forwarding modifies invariant.end (since there would be
> some invariant.start which is still alive, and maintaining the invariance
> for uses of %a)
>

Well, no.
If invariant end was readonly, it would value forward past invariant ends,
and extend the range in the case it was like this:

%a =invariant.start
...
invariant.end(%a)

<non-memory affecting instructions>

%b=invariant.start
...
invariant.end(%b)

As long as there are no memory writing instructions in the middle, things
will believe the two invariant starts produce the same value, and forward
it :)

GVN is not quite smart enough yet, but it's about to be.

GCC even has testcases that we both eliminate and PRE pure/const
(readonly/readnone) calls.



>
> Thanks,
> Anna
>
> On Aug 6, 2016, at 12:30 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
> So, this value forwards in a case i hadn't thought about.
>
> foo = lifetime.start(p)
> <stuff>
> bar = lifetime.start(p)
> lifetime.end (bar)
>
> will become
> foo = lifetime.start(p)
> <stuff>
> bar = lifetime.start(p)
> lifetime.end (foo)
>
>
> I'm not sure the above is even valid, but i found it in Real Live Code(TM).
>
> Thoughts?
>
>
>
> On Fri, Aug 5, 2016 at 10:15 PM, Anna Thomas <anna at azul.com> wrote:
>
>> anna added a comment.
>>
>> Changing the code to teach Alias analysis (instead of MDA) about the
>> readonly nature of MDA. All the tests are still valid (and checks remain
>> the same).
>> getModRefInfo is used by MDA, so the implications on the various passes
>> (GVN, Memcpyopt and DSE) should be the same, it’s just that the code change
>> will be within the same code region where other special cases for
>> llvm.assume and guard intrinsics exist.
>>
>> Making the change in alias analysis rather than MDA stemmed from the
>> discussion in llvm-commits mailing list with dberlin and sanjoy.
>>
>>
>> https://reviews.llvm.org/D23214
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160808/69a7bdff/attachment.html>


More information about the llvm-commits mailing list