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 > >
Nuno Lopes via llvm-dev
2018-Feb-17 23:52 UTC
[llvm-dev] Missing attribute inference cases
I can step in, if that's ok with you. Nuno -----Original Message----- From: Philip Reames Sent: Saturday, February 17, 2018 1:04 AM To: Davide Italiano ; Nuno Lopes Cc: llvm-dev Subject: Re: [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
Philip Reames via llvm-dev
2018-Feb-19 06:47 UTC
[llvm-dev] Missing attribute inference cases
SGTM On 02/17/2018 03:52 PM, Nuno Lopes wrote:> I can step in, if that's ok with you. > Nuno > > -----Original Message----- From: Philip Reames > Sent: Saturday, February 17, 2018 1:04 AM > To: Davide Italiano ; Nuno Lopes > Cc: llvm-dev > Subject: Re: [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 >