[llvm-dev] [cfe-dev] RFC: Supported Optimizations attribute

[Philip Reames via llvm-dev]

Honestly, I think well defined nulls are a complete different problem, 
and the approach taken by the null-pointer-is-valid attribute is simply 
wrong.  We have existing mechanisms for this (data layout, implicit null 
checks, etc..), and don't need a separate attribute on the function.

Philip

On 12/5/18 2:31 AM, Piotr Padlewski wrote:
> An additional bit to the discussion:**I think that 
> *"null-pointer-is-valid"* attribute should also be handled in a 
> similar manner - if one function calls
> another one marked with *"null-pointer-is-valid"*, then after 
> inlining the function should also be marked 
> with* "null-pointer-is-valid"*.
> I assume this attribute was added to handle kernel or embedded code 
> correctly and probably there was no use case to do LTO between
> modules with and without this attribute (yet).
> This, unfortunately, can't be solved with our 
> *supported_optimizations* attribute, as null pointer dereference is 
> considered to be UB by default.
> We would need something like *"unsupported_optimizations"*, but I 
> think this shows that this is not the last time when a similar problem 
> will arise.
>
>
> śr., 5 gru 2018 o 09:57 Piotr Padlewski <piotr.padlewski at gmail.com 
> <mailto:piotr.padlewski at gmail.com>> napisał(a):
>
>
>
>     śr., 5 gru 2018 o 00:22 John McCall via cfe-dev
>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> napisał(a):
>
>         On 4 Dec 2018, at 17:50, Philip Reames wrote:
>
>             Skimming along, apologies if I'm repeating something which
>             already got said.
>
>             If I understand this correctly, the basic problem we're
>             trying to solve is to use a local hint (the
>             invariant.group) to make a global assumption about other
>             code which might exist elsewhere outside the function. 
>             The attribute proposed can basically be phrased as
>             describing a universe of functions within which our
>             desired global property holds. There's an ambiguity about
>             what is allowed to be assumed about code outside that
>             universe.
>
>             I think it's important to note that we have a precedent of
>             something similar to this in TBAA.  TBAA information
>             coming from different modules has the same base problem. 
>             We solve it by using the "root" of the TBAA tree as a
>             scope descriptor, and essentially making two TBAA nodes
>             from distinct roots incomparable.
>
>             Can someone explain concisely why a similar scheme
>             couldn't be used to solve this problem?
>
>         TBAA is conservative in /two/ ways:
>         - It allows two accesses to alias if they have TBAA nodes with
>         different roots.
>         - It allows two accesses to alias if only one of them has a
>         TBAA node.
>
>         The second is what doesn't generalize: there are optimizations
>         where you need to
>         rely on transition points being explicitly identified. Looking
>         at a function
>         with no identified transition points, you don't know whether
>         it actually doesn't
>         transition or whether it was compiled without the transitions
>         being explicitly
>         marked. There's no way to extend the TBAA idea to make that work.
>
>     The other reason why similar scheme doesn't work for
>     !invariant.group is that we rely on a calls to launder/strip being
>     present for some constructs to preserve
>     information about invartianess of an object (like in the example
>     from RFC).
>
>             On 12/4/18 11:24 AM, John McCall via llvm-dev wrote:
>
>                 Note that IPO is generally permitted to partially
>                 inline or outline code,
>                 and so good-faith optimizations that e.g. require two
>                 instructions to be moved
>                 in tandem or not at all must use tokens to establish
>                 that unbreakable
>                 relationship.
>
>             I think the way your framing this is dangerous.  We
>             absolutely can not allow any annotation of this form to
>             *weaken* the semantics of the existing IR.  We can and
>             should impose a criteria that any extension of this
>             variety strictly add information to the IR which might not
>             have been previously inferred.  We can then design rules
>             for how to preserve our new information as long as
>             possible, but framing this in terms of disallowed
>             transformations is really a non-starter.
>
>         That's exactly what I was trying to convey here. Authors of
>         good-faith
>         optimizations need to design their representations so that
>         transformations
>         that know nothing about their optimizations but merely
>         preserve semantics
>         and well-formed IR structure will not break their
>         representations. The only
>         transforms that need to know about the existence of good-faith
>         optimizations
>         are interprocedural optimizations; furthermore, those
>         optimizations don't
>         need to know about any good-faith optimizations specifically,
>         they just need
>         to understand how to correctly update the
>         supported_optimizations list.
>         That is a very small burden on IPO that enables an interesting
>         class of
>         language-specific optimizations.
>
>         John.
>
>         _______________________________________________
>         cfe-dev mailing list
>         cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>         http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181205/cb0ee61f/attachment.html>