similar to: [LLVMdev] Casting.h illness

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 uncovering several ugly

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 >

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

On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: > 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

Thanks, Shahid. It is fixed now. On Fri, Apr 17, 2015 at 8:50 PM, Shahid, Asghar-ahmad < Asghar-ahmad.Shahid at amd.com> wrote: > Hi zhi, > > > > You have to also pass the value type to getDecalaration() API such as > > > > Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd, > v->getType()); > > > > Regards, > >

> On 2015-Jan-19, at 12:38, Frédéric Riss <friss at apple.com> wrote: > > >> On Jan 19, 2015, at 12:04 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: >> >> >> I forgot to mention this in my initial email. >> >> The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c >> The date on the

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

Am 22.07.2010 um 23:29 schrieb 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

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

Michael Smith wrote: > Well, line 364 wasn't actually what was holding me up, so it's a bad > example, but the problem's still relevant. Using cast<...>(iter), > dyn_cast<...>(iter), or isa<...>(iter) results in the error messages > mentioned below. .... > When compiling LoadValueNumbering.cpp, I get the following errors: > >

Well, line 364 wasn't actually what was holding me up, so it's a bad example, but the problem's still relevant. Using cast<...>(iter), dyn_cast<...>(iter), or isa<...>(iter) results in the error messages mentioned below. ________________________________ When compiling LoadValueNumbering.cpp, I get the following errors:

Hi All, AllocaInst * AI = builder.CreateAlloca(type, 0, BBName); StoreInst* ST= builderTF.CreateStore(ConstantInt::get(type,1),AI); Value * Vresult = (Value*)ST; Vresult = builderWait.CreateShl(Vresult, 1); I need to make one bit shift left to the variable stored in the second step I've got crash in this step opt: /home/xx/llvm2/llvm/include/llvm/Support/Casting.h:237: typename

I was poking through the black magic in Casting.h, and I see this interesting struct/function: template<class To, class FromTy> struct cast_convert_val<To,FromTy,FromTy> { // This _is_ a simple type, just cast it. static typename cast_retty<To, FromTy>::ret_type doit(const FromTy &Val) { typename cast_retty<To, FromTy>::ret_type Res2 = (typename

In compiling my software to use LLVM, I have noticed many occurrences of C style casting in LLVM header files. Since I compile with the -Wold-style-cast flag to g++, I get warnings about each of them. This isn't a big deal but I try to keep my code compilations both error and warning free (makes spotting true errors easier). I'm wondering why a new C++ (LLVM) would choose to use C style

Hello, everyone! I want to write a pass which can insert a call "printf" instructions before every instruction in the LLVM IR. here is what I wrote: namespace { class call_print : public FunctionPass{ private: DenseMap<const Value*, int> inst_map; public: static char ID; call_print() : FunctionPass(ID){} //define a extern function "printf" static llvm::Function*

On Thu, Apr 4, 2019 at 7:10 PM Craig Topper <craig.topper at gmail.com> wrote: > 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

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

> ... and it's in.  Please let me know if you see any problems. My clang self-hosted build (Release+Asserts on Release+Asserts, Linux x86_64) fails with: make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build clang: /home/jay/svn/llvm-project/llvm/trunk/include/llvm/Support/Casting.h:194: typename

Jay Foad wrote: >> ... and it's in. Please let me know if you see any problems. > > My clang self-hosted build (Release+Asserts on Release+Asserts, Linux > x86_64) fails with: > > make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' > llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build > clang:

Hi Chris, this was a very tempting commit to make, unfortunately it broke pattern matching of vectors of booleans. The problem is that a ConstantDataVector is only formed if the element type is one of i8, i16, etc. So vectors of funky types, or not so funky types like i1, are no longer matched. I noticed this while working on PR11948. The good thing is that the testcase there no longer crashes