[llvm-dev] [RFC] A nofree (and nosynch) function attribute: Mixing dereferenceable and delete

[Dean Michael Berris via llvm-dev]

On Wed, Jul 11, 2018 at 12:37 PM Hal Finkel <hfinkel at anl.gov> wrote:
>
>
> On 07/10/2018 09:12 PM, Dean Michael Berris wrote:
> >
> > Is the default assumption going to be that a function that isn't
> > marked `nofree` *will* free and pessimize that way? Does it make more
> > sense then to make an attribute that's positive, say 'frees' and relax
> > the default assumption to "does not free"?
>
> The default for unknown functions needs to be that they might free
> memory. Otherwise, it's not conservatively correct.
>

Yes, for unknown functions we can assume the worst and be
conservatively correct.

For the fully-defined in-module function (or even special functions
defined by the front-end) then marking the functions that definitely
free might be a stronger signal to inhibit code motion or aggressive
reordering.

I'm essentially trying to see whether there's a way to achieve the
goal without having to sprinkle `nofree` in majority of functions that
take pointers but don't free them, just to be able to allow correct
but more aggressive optimisation.


> >>
> > I've not worked out the full matrix of possibilities here in my head
> > yet, but what are the risks with relaxing the default semantics then
> > introducing the stronger attributes?
>
> Benefits: Current IR produced by Clang becomes conservatively correct.
> No changes to Clang's codegen are necessary (minor).
> Downsides: Other frontends producing the attribute in a
> currently-correct way now need to change to a new attribute to retain
> current behavior.
>

Yeah that sounds like it's not ideal and may cost more than
introducing the attribute with weaker semantics.

> If we introduce a new attribute with the weaker semantics, then:
>
> Benefits: Currently-correct IR remains unchanged and will continue to be
> optimized strongly.
> Downsides: Older IR produced by Clang will remain incorrect. Clang's
> codegen will need to be updated (minor).
>
> I don't have sufficient knowledge of non-Clang usage of the attribute to
> have a strong opinion. I'm happy to add a new weaker attribute, we just
> need to figure out what to name it. deferenceable_entry, perhaps?
>

I suspect the attribute really ought to communicate a post-condition,
so that optimisations can check for legality of a transformation (or
avoid making transformations that are provably incorrect). There's a
number of these, which might be useful:

- maybe_invalidated : says that the pointer may be invalidated after a
call to the function (because there are branches that lead to
invalidation) (can be the default)
- is_preserved : says strongly that the pointer is live after the
function is called
- invalidated : says strongly that the pointer is definitely, without
shadow of a doubt invalidated after a call to the function (you can
mark all calls to 'free' and similar to have this attribute on the
pointer)

Whether these map to existing attributes is something I'll need to
learn myself, but I would think will cover the use-cases for
optimisations for code-motion on pointers.

The more I think about it, the more I'm wondering whether the
attribute has to be on the function or whether it's on the pointer.
Or, if we want both -- an attribute on the function that it mark which
pointers (not just the ones it takes as parameters) are invalidated or
maybe invalidated (globals for example).

> >  Maybe you or someone has thought
> > that through before, and it would be great to have a summary or an
> > idea what the pros/cons are of doing that instead of attempting to
> > infer non-freeing behaviour.
>
> I think that we need to infer regardless to get optimizations going forward.
>

Indeed.

Thanks, Hal!

/me subscribes to the patch.

Cheers

-- 
Dean