search for: cast_or_null

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? >> >> -Chr...

...s 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 i...

Hi! in the description of llvm::cast it says: But it will correctly return NULL when the input is NULL. And in the description of llvm::cast_or_null it says: Functionally identical to cast, except that a null value is accepted This sounds to me as if both functions accept a null pointer. What is then the difference between cast and cast_or_null? -Jochen

...s initializer. In that case, create a // dummy basic block for now, and replace it once we've materialized all // the initializers. BasicBlock *BB; if (F->empty()) { DelayedBBs.push_back(DelayedBasicBlock(BA)); BB = DelayedBBs.back().TempBB.get(); } else { BB = cast_or_null<BasicBlock>(mapValue(BA.getBasicBlock())); } return getVM()[&BA] = BlockAddress::get(F, BB ? BB : BA.getBasicBlock()); } Thanks, Pei On 6/28/17, 10:59 AM, "陳韋任" <chenwj.cs97g at g2.nctu.edu.tw> wrote: 2017-06-29 1:55 GMT+08:00 Pei Wang via llvm-dev <llvm...

...t;T>(var)) { > ... > } > > 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...

...> 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. > > isa<> is very different from *cast<>. *cast<> gives you a pointer back, > which may be nu...

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

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

...of a frame: (lldb) frame #6: 0x0000000103a67c3e clasp_boehm_d`llvm::DIDescriptor::replaceAllUsesWith(this=0x00007fff5fb9e288, D=0x000000010985b330) + 254 at DebugInfo.cpp:399 396 MDNode *Node = const_cast<MDNode *>(DbgNode); 397 const MDNode *DN = D; 398 const Value *V = cast_or_null<Value>(DN); -> 399 Node->replaceAllUsesWith(const_cast<Value *>(V)); 400 MDNode::deleteTemporary(Node); 401 } 402 (lldb) print Node (llvm::MDNode *) $3 = 0x00000001180b74c0 (lldb) call Node->dump() !{i32 786468} (lldb) call V->dump() !{} (lldb) Here’...

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, Jul...

...ed 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> >> w...

...; frame #6: 0x0000000103a67c3e clasp_boehm_d`llvm::DIDescriptor::replaceAllUsesWith(this=0x00007fff5fb9e288, D=0x000000010985b330) + 254 at DebugInfo.cpp:399 >> 396 MDNode *Node = const_cast<MDNode *>(DbgNode); >> 397 const MDNode *DN = D; >> 398 const Value *V = cast_or_null<Value>(DN); >> -> 399 Node->replaceAllUsesWith(const_cast<Value *>(V)); >> 400 MDNode::deleteTemporary(Node); >> 401 } >> 402 >> (lldb) print Node >> (llvm::MDNode *) $3 = 0x00000001180b74c0 >> (lldb) call Node->dump() >&...

+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,

What's the RightWay(tm) to get a named type? I want to use the Module's symbol table as a repository for named types. But, it doesn't have a way to get the type out unless you already know what it is (i.e. the addTypeName() method). Similarly the SymbolTable class's lookup() method requires a type as well. The Type class also didn't have anything obvious. I want something

Bruce, Thanks for the explanation. But based on my inspection on the source code, it seems that materialization is related to lazily reading LLVM objects (Module, Function, etc.) into the memory from bitcode files, which is possibly useful during LTO. I’m not sure though. Pei From: <bruce.hoult at gmail.com> on behalf of Bruce Hoult <bruce at hoult.org> Date: Wednesday, June 28,

+1 for "isa_nonnull" --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hubert Tong via llvm-dev Sent: Friday, April 05, 2019 12:10 AM To: Aaron Ballman Cc: LLVM Development List Subject: Re: [llvm-dev] [RFC] Should we add isa_or_null<>? On Thu, Apr 4, 2019 at 11:15 PM Aaron Ballman via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at

I'd like to propose adding `isa_or_null<>` to replace the following usage pattern that's relatively common in conditionals: var && isa<T>(var) =>> isa_or_null<T>(var) And in particular when `var` is a method call which might be expensive, e.g.: X->foo() && isa<T>(X->foo()) =>> isa_or_null<T>(X->foo()) The

Moving to LLVM dev to discuss the possibility of extending the cast infrastructure to handle this. On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: > On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >> TypeLoc casting looks bogus. >> >> TypeLoc derived types return true from classof when the dynamic type >>

...inline typename cast_retty<X, Y*>::ret_type cast(Y *Val) { + assert(isa<X>(Val) && "cast<Ty>() argument of incompatible type!"); + return cast_convert_val<X, Y*, + typename simplify_type<Y*>::SimpleType>::doit(Val); +} + // cast_or_null<X> - Functionally identical to cast, except that a null value is // accepted. // @@ -229,11 +243,21 @@ // if (const Instruction *I = dyn_cast<Instruction>(myVal)) { ... } // -template <class X, class Y> +template <class X, class Y, class S = typename std::enable_if<!s...