search for: is_base_of

...()`s of the form: > static bool classof(const Foo *) { return true; } > Is the only purpose of this to optimize away "trivial" upcasts/isa<> > checks which are known statically? Yes. > If so, could we factor out this > case into Casting.h (using a trait like std::is_base_of<>)? That's a great idea, please do! :) -Chris

...tic bool classof(const Foo *) { return true; } >> Is the only purpose of this to optimize away "trivial" upcasts/isa<> >> checks which are known statically? > > Yes. > >> If so, could we factor out this >> case into Casting.h (using a trait like std::is_base_of<>)? > > That's a great idea, please do! :) Ok. We already have an is_base_of<> in Support/type_traits.h, so hopefully it's mostly a matter of wiring it up. Thankfully we already have some unittests for Casting.h so no new ground needs to be broken there. I'll try to g...

...One question regarding `classof()`s of the form: static bool classof(const Foo *) { return true; } Is the only purpose of this to optimize away "trivial" upcasts/isa<> checks which are known statically? If so, could we factor out this case into Casting.h (using a trait like std::is_base_of<>)? --Sean Silva On Thu, Oct 4, 2012 at 2:06 AM, Chris Lattner <sabre at nondot.org> wrote: > It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory. > > -Chris > > On Oct 3, 2012, at 9:39 PM, Sean Si...

...lgorithm.cpp.o > In file included from /local/mnt/workspace/llvm/src/projects/libcxx/include/algorithm:591:0, > from /local/mnt/workspace/llvm/src/projects/libcxx/src/algorithm.cpp:10: > /local/mnt/workspace/llvm/src/projects/libcxx/include/type_traits:731:2: error: #error is_base_of not implemented. My command looks: > cmake_args="Unix Makefiles" > cmake -G "$cmake_args" -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_BUILD_TYPE="Release" -DCMAKE_INSTALL_PREFIX="../bin" ../src > make Alternatively, I tried to compile llvm...

It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory. -Chris On Oct 3, 2012, at 9:39 PM, Sean Silva <silvas at purdue.edu> wrote: > Thanks for the feedback! > >>> Does anybody have anything else they think should go into TGContext or >>> any other responsibilities it should have? Or any

Thanks for the feedback! >> Does anybody have anything else they think should go into TGContext or >> any other responsibilities it should have? Or any feedback about the >> idea in general? > > All memory allocations should go into its bump pointer, RecordKeeper should as well. Any other global state that exist should also. Sounds good. >> I'm also hoping