search for: looppredication

Hi Thomas, Looks good. Your changes in loopPredicate.cpp does not match original changes - they miss iff->is_RangeCheck() check [1]. But in JDK8 we did not have specialized RangeCheckNode class in C2. Suggested fix should be fine fro jdk 8u. Reviewed. Please, when sending RFA ( approval request) use original 8174050 bug id. Thanks, Vladimir [1]

Hi Thomas, Thanks for your kind response! Please review my backport for hs25, thanks a lot! diff -r 3544d85cfe11 src/share/vm/opto/lcm.cpp --- a/src/share/vm/opto/lcm.cpp Thu Jul 19 10:00:36 2018 +0100 +++ b/src/share/vm/opto/lcm.cpp Fri Jul 20 10:06:37 2018 +0800 @@ -49,7 +49,7 @@ // Check whether val is not-null-decoded compressed oop, // i.e. will grab into the base of the heap

Hi HotSpot and LLVM developers, I am building OpenJDK8[1] with LLVM toolchain[2] for mips64el, it failed to build: /home/loongson/jdk8-mips/hotspot/src/share/vm/opto/lcm.cpp:52:35: error: ordered comparison between pointer and zero ('address' (aka 'unsigned char *') and 'int') if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.

...ibility allows an earlier guard to be "widened" (i.e. made to fail more often) if doing so allows the elimination of a later guard or otherwise is useful to prune possible code paths.  At this point, the basic notion of a guard is fairly well proven with both critical transformations (LoopPredication, GurardWidening) available upstream, and multiple downstream speculative optimizations built on top. As we've explored the design, we've stumbled on a implementation challenge.  Today, guards are modeled as call, not invokes.  As it turns out, LLVM is not terribly good at dealing with p...

Hi, This is Ariel from the Rust team again. I am having another pass ordering issue. Looking at the pass manager at https://github.com/llvm-mirror/llvm/blob/7034870f30320d6fbc74effff539d946018cd00a/lib/Transforms/IPO/PassManagerBuilder.cpp (the early SimplifyCfg now doesn't sink stores anymore! I can't wait until I can get to use that in rustc!) I find that the loop optimization group

...n earlier guard to be "widened" (i.e. made to fail > more often) if doing so allows the elimination of a later guard or > otherwise is useful to prune possible code paths.  At this point, the > basic notion of a guard is fairly well proven with both critical > transformations (LoopPredication, GurardWidening) available upstream, > and multiple downstream speculative optimizations built on top. > > As we've explored the design, we've stumbled on a implementation > challenge.  Today, guards are modeled as call, not invokes.  As it > turns out, LLVM is not terribly g...