Nuno Lopes via llvm-dev
2018-Feb-16 23:42 UTC
[llvm-dev] Missing attribute inference cases
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 -----Original Message----- From: Philip Reames via llvm-dev Sent: Friday, February 16, 2018 6:48 PM To: llvm-dev Subject: Re: [llvm-dev] Missing attribute inference cases On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote: 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 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... 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
Davide Italiano via llvm-dev
2018-Feb-16 23:47 UTC
[llvm-dev] Missing attribute inference cases
Yes, I agree with you this sounds like a great GSoC. On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org> wrote:> 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 > > -----Original Message----- From: Philip Reames via llvm-dev > Sent: Friday, February 16, 2018 6:48 PM > To: llvm-dev > Subject: Re: [llvm-dev] Missing attribute inference cases > > > > On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote: > > > 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 > > 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... > > > > 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 > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare
Philip Reames via llvm-dev
2018-Feb-17 01:04 UTC
[llvm-dev] Missing attribute inference cases
Sure, but is anyone willing to mentor? I don't have time. I can advise, but only infrequently. Philip On 02/16/2018 03:47 PM, Davide Italiano wrote:> Yes, I agree with you this sounds like a great GSoC. > > On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> 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 >> >> -----Original Message----- From: Philip Reames via llvm-dev >> Sent: Friday, February 16, 2018 6:48 PM >> To: llvm-dev >> Subject: Re: [llvm-dev] Missing attribute inference cases >> >> >> >> On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote: >> >> >> 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 >> >> 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... >> >> >> >> 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 >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >