[llvm-dev] [cfe-dev] RFC: Supported Optimizations attribute
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Wed Dec 5 09:21:48 PST 2018
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.
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
> 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
> 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
> optimizations need to design their representations so that
> 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
> 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.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev