[llvm] r221737 - Canonicalize an assume(load != null) into !nonnull metadata

[Philip Reames]

On 11/11/2014 04:15 PM, Hal Finkel wrote:
> ----- Original Message -----
>> From: "David Blaikie" <dblaikie at gmail.com>
>> To: "Philip Reames" <listmail at philipreames.com>
>> Cc: llvm-commits at cs.uiuc.edu
>> Sent: Tuesday, November 11, 2014 5:47:28 PM
>> Subject: Re: [llvm] r221737 - Canonicalize an assume(load != null) into	!nonnull metadata
>>
>> On Tue, Nov 11, 2014 at 3:33 PM, Philip Reames <
>> listmail at philipreames.com > wrote:
>>
>>
>> Author: reames
>> Date: Tue Nov 11 17:33:19 2014
>> New Revision: 221737
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=221737&view=rev
>> Log:
>> Canonicalize an assume(load != null) into !nonnull metadata
>>
>> We currently have two ways of informing the optimizer that the result
>> of a load is never null: metadata and assume. This change converts
>> the second in to the former. This avoids a need to implement
>> optimizations using both forms.
>>
>> We should probably extend this basic idea to metadata of other forms;
>> in particular, range metadata. We view is that assumes should be
>> considered a "last resort" for when there isn't a more canonical way
>> to represent something.
>>
>>
>> (naively) seems almost a pity, really - if we have the general tool,
>> why not drop the special cases & just use the general one? For
>> things already using the special cases, they can continue to look
>> for the very specific canonicalized case of the general form with
>> relatively low cost, I would imagine - but I know very little about
>> all of this. Just a thought.
>>
> I share your desire for making use of a single general-purpose tool, but in this case, using @llvm.assume as a much higher cost compared to the metadata (both in its representational size and in its ability to block potentially-useful optimizations), so I think it makes sense to canonicalize on the metadata when available.
I was writing up a response, but Hal beat me to it.  :)  He explained 
why canonicalization is worthwhile, but let me give some additional 
background.

The fundamental problem is that assume has to be modeled via control 
dependence (and thus via memory access, currently), where as metadata is 
the property of a Value, and has no other effects on surrounding code.  
Without special casing, a assume(load x != null) implies a full 
reordering barrier and memory clobber, where as a load x, !nonnull does 
not.

Hal has tried to special case assume in the optimizer to avoid this, but 
it leaves us ever chasing cases where the optimizer took a conservative 
view.  (Just to be clear, this is much better than the semantics not 
being conservative enough!)

I doubt we'll add many more forms of metadata, but the existing ones 
should probably be preserved.  We'll evaluate case by case whether the 
gains from having a piece of metadata are worth it or not.

Philip