search for: dyn_cast_or_nul

On Jul 22, 2010, at 10:57 AM, Gabor Greif wrote: > Am 22.07.2010 um 00:21 schrieb Chris Lattner: > >> On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote: >>> Is this a recommended approach/good style/good idea to use >>> dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other >>> is and cast functions). >> >> We generally don't want auto-dereference. There is some special magic for unwrapping Uses etc though. Is this what you're in contact with Gabor? >> >> -Ch...

On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote: > Is this a recommended approach/good style/good idea to use > dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other > is and cast functions). We generally don't want auto-dereference. There is some special magic for unwrapping Uses etc though. Is this what you're in contact with Gabor? -Chris > > Eugene > > On Wed, Ju...

...Chris Lattner: > > On Jul 22, 2010, at 10:57 AM, Gabor Greif wrote: > >> Am 22.07.2010 um 00:21 schrieb Chris Lattner: >> >>> On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote: >>>> Is this a recommended approach/good style/good idea to use >>>> dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And >>>> other >>>> is and cast functions). >>> >>> We generally don't want auto-dereference. There is some special >>> magic for unwrapping Uses etc though. Is this what you're...

Hi all, at the moment I am trying to fix an unnecessary iterator dereferencing in Casting.h and am uncovering several ugly things. For example, look at this code: > // dyn_cast_or_null<X> - Functionally identical to dyn_cast, except that a null > // value is accepted. > // > template <class X, class Y> > inline typename cast_retty<X, Y>::ret_type dyn_cast_or_null(const Y &Val) { > return (Val && isa<X>(Val)) ? cast<X, Y>...

Is this a recommended approach/good style/good idea to use dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other is and cast functions). Eugene On Wed, Jul 21, 2010 at 12:42 PM, Gabor Greif <gabor at mac.com> wrote: > Hi all, > > at the moment I am trying to fix an unnecessary iterator dereferencing > in Casting.h and am unc...

...Agreed that the new isa_or_null style is better. Just wanted mention the > other style so we know we should migrate those to the new one. > I have a checker under review that could be enhanced to do that -- though it currently replaces `X->foo() && isa<Y>(X->foo())` with `dyn_cast_or_null<Y>(X->foo())`. Please see: https://reviews.llvm.org/D59802 thanks... don > > ~Craig > > > On Thu, Apr 4, 2019 at 4:37 PM Don Hinton <hintonda at gmail.com> wrote: > >> On Thu, Apr 4, 2019 at 6:29 PM Craig Topper <craig.topper at gmail.com> >>...

On Thu, Apr 4, 2019 at 6:29 PM Craig Topper <craig.topper at gmail.com> wrote: > There are a handful of places in LLVM that dosomething like if > (dyn_cast_or_null<UndefValue>(P->hasConstantValue())) > Yes, I've seen those, but while working on a new checker, I was advised that replacing `X && isa<Y>(X)` with `dyn_cast_or_null<Y>(X)` was suboptimal, and it was suggested something like a `isa_or_null` style operator would...

Am 22.07.2010 um 00:21 schrieb Chris Lattner: > On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote: >> Is this a recommended approach/good style/good idea to use >> dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other >> is and cast functions). > > We generally don't want auto-dereference. There is some special > magic for unwrapping Uses etc though. Is this what you're in > contact with Gabor? > > -Chris >...

...; +++ PatternMatch.h (revision 149912) > @@ -98,13 +98,6 @@ > Res = &CI->getValue(); > return true; > } > - // FIXME: Remove this. > - if (ConstantVector *CV = dyn_cast<ConstantVector>(V)) > - if (ConstantInt *CI = > - dyn_cast_or_null<ConstantInt>(CV->getSplatValue())) { > - Res = &CI->getValue(); > - return true; > - } > if (ConstantDataVector *CV = dyn_cast<ConstantDataVector>(V)) > if (ConstantInt *CI = > dyn_cast_or_null<ConstantInt>(CV-...

...t;(var)) { > > > ... > > > } > > > > > > at least according to what "isa_or_null" conveys to me. > > > > This is the same convention used by the existing "_or_null" varieties, > > i.e., "cast_or_null" and "dyn_cast_or_null". They accept a null and > > propagate it. In the "isa" case, it would accept a null and propagate > > it as false. > > isa<> is very different from *cast<>. *cast<> gives you a pointer back, > which may be null. isa<> is precondition...

...vision 149912) >> @@ -98,13 +98,6 @@ >> Res = &CI->getValue(); >> return true; >> } >> - // FIXME: Remove this. >> - if (ConstantVector *CV = dyn_cast<ConstantVector>(V)) >> - if (ConstantInt *CI = >> - dyn_cast_or_null<ConstantInt>(CV->getSplatValue())) { >> - Res = &CI->getValue(); >> - return true; >> - } >> if (ConstantDataVector *CV = dyn_cast<ConstantDataVector>(V)) >> if (ConstantInt *CI = >> dyn_cast_or_null&l...

...,13 +98,6 @@ >>> Res =&CI->getValue(); >>> return true; >>> } >>> - // FIXME: Remove this. >>> - if (ConstantVector *CV = dyn_cast<ConstantVector>(V)) >>> - if (ConstantInt *CI = >>> - dyn_cast_or_null<ConstantInt>(CV->getSplatValue())) { >>> - Res =&CI->getValue(); >>> - return true; >>> - } >>> if (ConstantDataVector *CV = dyn_cast<ConstantDataVector>(V)) >>> if (ConstantInt *CI = >>>...

Hi, Here is the code in IndVarSimplify.cpp. SmallVector<WeakVH, 16> DeadInsts; while (!DeadInsts.empty()) if (Instruction *Inst = dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val())) RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI); Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL pointer, the expression, &*DeadInsts.pop_back_val(), could be &*NULL. Then NULL pointer is dereferenced here....

...a few test cases that crash at head, without my debugging assertions for accessing pointee types. One of them is test/Transforms/StripSymbols/2010-06-30-StripDebug.ll Its retainedTypes metadata points to a metadata array of a single null element. This crashes the dyn_cast (because it's not a dyn_cast_or_null) Verifier.cpp:3785 Do you have a preferred/canonical representation intended in this case - an extant, but zero-length list, or no list at all? I tend to prefer no list at all, just because it simplifies reading of the debug info. Rather than seeing a "retainedTypes" property, following...

+1 on not adding the new API On Sat, May 4, 2019, 11:51 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +1, if we're voting. I don't think it adds to the readability of code > for me personally. > > On Sat, May 4, 2019 at 11:47 AM Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Mon, Apr 29, 2019,

...t; } > > is not the same as: > > if (isa_or_null<T>(var)) { > ... > } > > at least according to what "isa_or_null" conveys to me. > This is the same convention used by the existing "_or_null" varieties, i.e., "cast_or_null" and "dyn_cast_or_null". They accept a null and propagate it. In the "isa" case, it would accept a null and propagate it as false. > > not_null_and_isa<T> would seem a better fit, or maybe exists_and_isa<T>. > > That said, I'm not sure sure we need a special API for this....

...they are defined in the class body. I tried the following patch, which I believe handles the in-class definition case: --- a/lib/CodeGen/CodeGenFunction.cpp +++ b/lib/CodeGen/CodeGenFunction.cpp @@ -630,7 +630,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) { if (!CGM.getCodeGenOpts().NoInline) { for (auto RI : FD->redecls()) - if (RI->isInlineSpecified()) { + if (RI->isInlined()) { Fn->addFnAttr(llvm::Attribute::InlineHint); break; } I tried this on C++ ben...

...asic blocks in a functions [iter_blocks] > * instructions in a block [iter_instrs] > > The other things that i'd like are to know what kind of > instruction a given instruction was. Hi Ranjit, There are recently aded C bindings for the "isa<>" template (actually, dyn_cast_or_null<>), which is usually the preferred manner to access the type ID. There are no corresponding ocaml bindings yet. I think this is the most important missing feature for what you've described; most of the instruction properties have getters and setters. Re exposing the type ID as an...

...ection it belongs, in this case .text, but it could be any section. I can get a MCSectionELF class object from MCSymbol that I get from MCSymbolRefExpr: int Kind = Value->getKind(); if (Kind == MCExpr::SymbolRef) { const MCSymbol &Sym = SRE->getSymbol(); const MCSectionELF = dyn_cast_or_null<MCSectionELF>(Sym.getSection()); } But can't see how to get the virtual address of the section. This is odd since I would have expected methods for accessing every part of the ELF section header entry. How does one get the virtual address (sh_addr in ELF) starting from a MCSymbolRefE...

----- Original Message ----- > Hi, > > I noticed that ConstantFP::get automatically returns the > appropriately > types Constant depending on the LLVM type passed in (i.e. if called > with a vector, it returns a splat vector with the given constant). > > Is there any simple way to do the inverse of this function? i.e., > given a llvm::Value, check whether it is either