similar to: [LLVMdev] running test suite with valgrind

Hi, As a follow up of this thread I've made a patch that implements a simple approach to propagate the function return values as described previously. It can transform e.g. the following program: define i32 @f(...) nounwind { (...) %cond = select i1 %tobool, i32 2, i32 3 ; <i32> [#uses=1] ret i32 %cond } define i32 @g(...) nounwind { entry: %call = call i32 (...)* @f() ;

Not sure how off-topic this is, but should we consider/have we considered porting our InstCombines to Alive? The PLDI '15 paper even demos C++ extraction from Alive theorems. I think it'd be a small step from that to extracting tightly optimized VM code, not unlike what Tablegen emits. Everything would be so clean and readable and organized. And edge cases can still be handled manually,

On Tue, Sep 16, 2008 at 1:59 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > This kind of transformation isn't currently done by LLVM (note that here > this pass is only removing case statements. other transformations are not of > my responsibility :). > The patch is available at > http://web.ist.utl.pt/nuno.lopes/llvm_function_ret_infer.txt > I would love to

Hi LLVM developers, I am implementing Loong Language[1] using Clang FrontEnd and LLVM MiddleEnd. I add `wire`[2] Builtin Type, and clang is able to parse very small testcase fulladder[3] but failed to work for 10+K loc RISCV E203 project[4]: Loongson clang version 7.0.0 (git at github.com:Loong-Language/loong-clang.git 8f7e826f27abbe12ea08d9563490298c38d3adc1) (git at

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.

Hi Sanjay, You used Alive correctly, of course :) At this moment we cannot give you the best precondition. It’s on the todo list, but it’s not even started yet. It’s a much harder problem to solve. We do have a mode to compute the best set of nsw/nuw/exact attributes in the transformed expression, but it’s not enabled on the web interface yet (InstCombine was missing quite a few cases last

Hi, Today I found a nice bug in the JIT global variable emitter. The problem may lead to an assert() failure when doing the following: 1) compile some function 2) emit a global variable 3) compile another function. an assert() may trigger in the JIT memory manager This happens because the JIT global variable emitter is using the MachineCodeEmitter::allocate() function, which uses memory

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

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de

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, This is a follow up on a discussion around shufflevector with undef mask in https://reviews.llvm.org/D70641 and https://bugs.llvm.org/show_bug.cgi?id=43958. The current semantics of shufflevector in http://llvm.org/docs/LangRef.html#shufflevector-instruction states: "If the shuffle mask is undef, the result vector is undef. If any element of the mask operand is undef, that element

>> Today I found a nice bug in the JIT global variable emitter. >> The problem may lead to an assert() failure when doing the following: >> 1) compile some function >> 2) emit a global variable >> 3) compile another function. an assert() may trigger in the JIT memory >> manager >> >> This happens because the JIT global variable emitter is using the

On Oct 13, 2008, at 2:42 PMPDT, Nuno Lopes wrote: > Hi, > > Today I found a nice bug in the JIT global variable emitter. > The problem may lead to an assert() failure when doing the following: > 1) compile some function > 2) emit a global variable > 3) compile another function. an assert() may trigger in the JIT memory > manager > > This happens because the JIT

On Sun, Feb 8, 2015 at 10:02 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > When you say, "we'd like to", I'm assuming your justification for this is > so that we can model poison using these undef semantics. Is that correct? > Yes, but I also think 'icmp sgt i32 undef, %a -> i1 undef' is a pretty reasonable transform by itself. Well-defined programs

I think calling the attribute "used" is confusing. I'd suggest the following: "not_poison": If an argument is marked not_poison, and the argument is poison at runtime, the call is instant UB. Whether an argument is poison is checked after the rules for other attributes like "nonnull" and "align" are applied. This makes it clear that the IR semantics

[resending since the previous copy was apparently dropped by the mailing list] >> Today I found a nice bug in the JIT global variable emitter. >> The problem may lead to an assert() failure when doing the following: >> 1) compile some function >> 2) emit a global variable >> 3) compile another function. an assert() may trigger in the JIT memory >> manager

> So just to be clear (mainly so i can go back to letting y'all hash this out), in value numbering: > 1. I can value number all freeze operations on the same operand to the same value > *as long as* > 2. I replace all freeze values of the same operand with a single one. > > Or am i misunderstanding? > If i've got it right, the issue i see with #2 is whether i can

Hi, Let me try to give a bit more context on why select is so tricky. First thing to consider is which transformations we would like to support: 1) Control-flow -> select (SimplifyCFG) if (c) a = x else a = y => %a = select %c, %x, %y 2) select -> control-flow; reverse of 1) Not sure if this is done at IR level, or only later at SDAG. 3) select ->

>> Ok, thanks for the explanation. So my first patch doesn't work. >> Also, to be >> clear, this bug has nothing to do with overflowing the JIT memory >> buffer. >> I made another one that takes keeps the allocation of global >> variables in >> the JIT buffer, but it creates a new mem block if it doesn't exist >> (i.e. >> when dumping a

On Thu, Sep 4, 2008 at 8:39 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > I have two questions about optimizations performed by llvm. > > Consider these simple functions: > int x(int b) { return b?4:6; } > int y() { return x(0); } > > int x2() { return 5; } > int y2() { return x2(); } > > the optimized bitcode (with clang + opt