[LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata

[Philip Reames]

On 11/14/2014 10:01 AM, Hal Finkel wrote:
> ----- Original Message -----
>> From: "Philip Reames" <listmail at philipreames.com>
>> To: "Chandler Carruth" <chandlerc at google.com>, "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
>> Sent: Friday, November 14, 2014 11:57:54 AM
>> Subject: Re: [LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata
>>
>>
>>
>> On 11/13/2014 05:02 PM, Chandler Carruth wrote:
>>
>> This intrinsic needs to carry control dependencies (it cannot be
>> hoisted out of a loop, for example) -- in this sense it is very much
>> like @llvm.assume. And like @llvm.assume, we'll need to add logic to
>> various passes to ignore it as appropriate so that it does not block
>> optimizations unnecessarily.
>> We should do something to make this simpler. I think we should have
>> an intrinsic inst base class that assume, lifetime, and other
>> intrinsics which do not represent actual code in the final program
>> derive from so that we don't have to update these lists all over the
>> place. If we need 2 tiers to model assume & noalias as distinct from
>> the lifetime or other intrinsics, fine. We should have high-level
>> categories that can be tested and updated. Agreed.
>>
>> Specific to this point, I've seen a number of cases in discussion
>> recently where a notion of a intrinsic which is control dependent on
>> surrounding control flow, but does not read or write memory would be
>> useful. It really feels like that's what the current implementation
>> of llvm.assume has become and likely what this proposal would
>> require. Maybe it's time to introduce a notion of an arbitrary
>> non-memory control dependence?
>>
>> Cases that come to mind:
>> - invariant.*
>> - lifetime.*
> But these two do have a memory control dependence, right? You can't reorder a store to x and a lifetime.end(x).
The specific case you gave is actually fine, but your point is true.  
I'd gotten myself confused here.

If you have a store immediate before a lifetime.end, the store is dead 
and can be assumed to not be visible in the program.  As a result, I 
don't see why it's illegal to reorder them.

*addr = x;
lifetime.end(addr)
==
lifetime.end(addr)
*addr = x;
==
lifetime.end(addr)

However, the same example with a load can not be reordered, precisely 
because the load is not necessarily dead.
x = *addr;
lifetime.end(addr)
!=
lifetime.end(addr)
x = *addr;

Philip