Missing attribute inference cases

This email is just to summarize a bit of digging I did last night into our attribute inference. Unfortunately, I’m not going to have time to implement any of the gaps I noticed, but I figured someone else out there might be interested.

Missing Attributes

argmemonly - influences AA, particularly relevant for libraries which wrap build in functions which are annotated, but don’t manually annotate the wrappers

dereferenceable - influences speculation safety, this primarily drives LICM, but can also effect things like PRE – probably best to implement as a deref_or_nuill analysis and then merge nonnull inference to promote

dereferenceable_or_null - see previous

nounwind - currently implemented in PruneEH, missing in new pass manager – this one will get fixed in the near future

Untrusted Declarations

In several cases, we check hasExactDefinition before checking properties of the function declaration (such as return type). To my knowledge, facts on declarations are valid even in the place of derefinement. This results in the analysis being unnecessarily conservative around external declarations.

AlwaysInline and hasExactDefinition

I believe, but have not fully thought through, that it is legal to IPO across an inexact definition boundary if a particularly callsite or declaration is marked alwaysinline. It’s not clear this matters since we’ll eventually inline it anyway, but this might be a compile time savings by simplifying callers earlier than otherwise possible.

Philip

Other cases I just noticed… noreturn – useful for exception throw wrappers allocsize – useful for allocation wrappers writeonly – useful for AA speculatable - useful for speculation, LICM, PRE, etc…

Maybe we could list some of these as a GSoC project?
Seems like a self-contained task that can be simple as desired and as hard as the student wants it to be.

Nuno

Yes, I agree with you this sounds like a great GSoC.

Sure, but is anyone willing to mentor? I don't have time. I can advise, but only infrequently.

Philip

Thanks for the digging!

A quick note:

Untrusted Declarations

In several cases, we check hasExactDefinition before checking properties of the function declaration (such as return type). To my knowledge, facts on declarations are valid even in the place of derefinement. This results in the analysis being unnecessarily conservative around external declarations.

We need to be careful here. Totally agree with you, just worried about something somewhere inferring things onto declarations when it shouldn’t and a general lack of adequate understanding of the line between the good and bad cases…

AlwaysInline and hasExactDefinition

I believe, but have not fully thought through, that it is legal to IPO across an inexact definition boundary if a particularly callsite or declaration is marked alwaysinline. It’s not clear this matters since we’ll eventually inline it anyway, but this might be a compile time savings by simplifying callers earlier than otherwise possible.

Given pass ordering, I’d not worry about this. The inliner runs first (in the new PM) and then we deduce attributes so we should already have nuked any always_inline edges.

We also have the pre-call-graph cleanup passes that do most of the code deletion and such prior to inlining.

I can step in, if that's ok with you.
Nuno

SGTM

Cool, it's here: http://llvm.org/OpenProjects.html#llvm_function_attributes
Nuno