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

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

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.

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