llvm dev - Nov 2014 - [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.*
- float point state changes (this last one might need a stronger 
restriction than the others)

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141114/1c4980be/attachment.html>

----- 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).

 -Hal
> - float point state changes (this last one might need a stronger
> restriction than the others)
> 
> Philip
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

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