search for: dereferenceable_or_null

Hi, While working on PR21780, I used "dereferenceable_or_null" metadata and I realized now that it is not correct for my solution to use this metadata type since it might point to an address that it is not dereferenceable but null. I think that we need another new metadata type, something like "dereferenceable" with that we could annotate an...

...idn't read > the whole thread carefully). > > Nuno > > -----Original Message----- > From: Dinar Temirbulatov via llvm-dev > Sent: Tuesday, July 18, 2017 7:36 PM > Subject: [llvm-dev] [RFC] dereferenceable metadata > > Hi, > While working on PR21780, I used "dereferenceable_or_null" metadata > and I realized now that it is not correct for my solution to use this > metadata type since it might point to an address that it is not > dereferenceable but null. I think that we need another new metadata > type, something like "dereferenceable" with that...

...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 know...

...n 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...

...he >> 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...

...on'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 fo...

...ut 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 > wri...

...; 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 -- u...

...> 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 wrap...

...change. I'll let him describe his objection since I was never quite clear on it. *Option 2* We introduce a new attribute with the desired semantics. This results in a collection of confusing overlapping attributes, but is otherwise straight forward. My proposed strawman syntax would be: dereferenceable_or_null(N). (Bikeshedding welcomed.) This would be a legal parameter and return attribute on both function declarations and call sites (i.e. calls and invokes). As with above, we'd extend all the places that currently consider 'dereferenceable' to consider the new attribute in combination...

...ptimizations taken together are particularly nice, because it means that changing enum attributes on functions and arguments won't trigger copies of immutable objects. It will only involve flipping bits in a locally stored bitset. Separately, I want to collapse dereferenceable(N), nonnull, and dereferenceable_or_null(N) for efficiency and orthogonality. I will probably raise this in a separate RFC, but I think it was a mistake to have to attribute imply nonnull. I'm mostly looking at this from an efficiency and redundancy perspective, though, not a semantic one. ---------- Does this all seem reasonable? S...

Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantRange(V, Result, CxtI); ... return Result; } Other