[llvm-dev] Well-formed @llvm.lifetime.start and @llvm.lifetime.end intrinsics

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 31 09:59:42 PDT 2017


On Fri, Mar 31, 2017 at 4:48 AM, Michael Kruse <llvmdev at meinersbur.de>
wrote:

> 2017-03-31 3:38 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>:
> > Sure, and you definitely can't transform an unconditional store to a
> > conditional one unless the uses are guarded by the same condition, or you
> > can prove it already had that value (in which case, the memset would
> also be
> > dead) :)
> >
> > ie
> > memset(a, 0)
> > use a
> >
> > can't be transformed to
> > if (c)
> >   memset(a, 0)
> > use a
> >
> > So again, if polly is making a lifetime.start conditional when the use is
> > not conditional, that's a bug in polly, regardless of the bug in stack
> > coloring's ability to handle it.
>
> InstCombine transforms memset(a,1) to a single StoreInst, but keeps
> the memset if the size argument is zero. A StoreInst can be optimized
> away, e.g. by DeadStoreElimination. I wonder, are the semantics of
> memset(a, 0) different than "do nothing"?
>

Yes, they are, because the value of a could be "not zero" :)

to whit:

if (load a == 50)
  memset (a, 0)
if (load a == 0)
   do something


If *a starts out as 50, this memset makes it do something.


>
> Where is the chain of transformations
>
> memset(&a, '0', sizeof a);
> if (c)
>   a = 1;
>
> =>
>
> if (c) {
>   memset(&a, '0', sizeof a);
>   a = 1;
> } else
>   memset(&a, '0', sizeof a);
>
>
=>
>
> if (c) {
>   memset(&a, '0', sizeof a);
>   a = 1;
> } else
>   memset(&a, '0', sizeof a);
>
> =>
>
> if (c) {
>   a = 0;
>   a = 1;
> } else
>   memset(&a, '0', sizeof a);
>
> =>
>
> if (c)
>   a = 1;
> else
>   memset(&a, '0', sizeof a);
>
> =>
> if (c)
>   a = 0;
> if (!c)
>   memset(&a, '0', sizeof a);
>
>
> not legal?
>

This is completely legal assuming no further use of a in the if(a) block

But lifetime.start is *not* a memset, and as mentioned, it was specifically
built to be not moved.
As also mentioned, i think these are crappy semantics, but that's the ones
we built ATM :)







>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170331/5e7a2d5b/attachment.html>


More information about the llvm-dev mailing list