[llvm-dev] [cfe-dev] Demystifying the byte type

[Philip Reames via llvm-dev]

On 10/19/21 7:51 AM, Johannes Doerfert via llvm-dev wrote:
>
> On 10/18/21 23:59, Michael Kruse via cfe-dev wrote:
>>  From the linked document:
>>
>>> Solution 3: Annotations and tags
>>> LLVM optimizers work with the assumption that attributes can be 
>>> discarded if the optimizer does not know how to handle them.
>> I don't think this is necessarily the case.
>
> To be really clear about this: The statement in the blog post is not 
> true.
>
> Michael is right that one can design the absence of the attribute to be a
> conservative things (like mustprogress) but that is not all.
>
> Attributes cannot be dropped by the optimizer, that was never (or at 
> least
> not for a long time) an option. The same is true for operand bundles and
> to some degree metadata.
>
> Here are some, not all, examples of non-droppable attributes:
>   - convergent
>   - alwaysinline
>   - naked
>   - nobuiltin
>   - noduplicate
>   - noimplicitfloat
>   - noinline
>   - optnone
>   - byval
>   - preallocated
>
> Operand bundles cannot be dropped and having them on arbitrary 
> instructions
> would not be the worst thing. Metadata is partially dropped but also 
> often
> preserved already as if it is required. Several backends crash if you 
> drop
> the wrong debug info metadata, which is almost as good as requiring to
> preserve them.

+1 one on the attributes and operand bundles.  These are semantic, and 
can not be dropped without understanding their meaning.

Metadata, by contract, can always be dropped.  Any backend which doesn't 
tolerate that has a bug.  It may not be a bug we care about or bother to 
fix, but it's still a bug.

>
> Now one can argue if attributes (or annotations in general) make IR 
> less readable
> but that is not the strongest argument. IR is not meant to be readable 
> in the same
> sense as a language you would program in is.
>
> The effort to to introduce new attributes, preserve them, an use them 
> is not necessarily
> high. A lot of the new attributes we introduced in the last 2 years 
> were implemented by
> students under guidance. Incl. the latest two being under review: 
> `objectsize` and `globalmemonly`
>
> All that said, I still believe the underlying problem here is with the 
> fact when a pointer
> escapes. It is just important to keep the description of alternative 
> options correct.
>
> ~ Johannes
>
>
>>   Such attributes can be
>> designed such that a missing attribute represents the most
>> conservative, like the `mustprogress` attribute/metadata. That is, a
>> missing annotation has an implicit provenance of {all}. GVN can fold q
>> and p after `if (q == p)` with a new provenance being the union of q
>> and p's provenance, like a PHINode. In other models, p and q cannot be
>> folded or in the case of the proposed byte type, cannot carry
>> provenance information.
>>
>>
>>> High engineering effort to enforce that attributes are preserved in 
>>> every transformation and used by analyses.
>> IMHO, it is still lower than introducing a new first-class type.
>>
>>
>> Michael
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev