similar to: [LLVMdev] Break operands into multiple instructions

Hi, I am investigating a performance degradation between llvm-3.1 and llvm-3.2 (Note: current top-of-tree shows a similar degradation) One issue I see is the following: - 'loop invariant code motion' seems to be depending on the result of the 'reassociate expression' pass: In the samples below I observer the following behavior: Both start with the same expression: %add = add

As far as I can understand of the code, the Reassociate tries to achieve this result by its "ranking" mechanism. If it dose not, it is not hard to achieve this result, just restructure the expression in a way such that the earlier definition of the sub-expression is permute earlier in the resulting expr. e.g. outer-loop1 x= outer-loop2 y =

It's an interesting problem. The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. Cooper gives a nice intro in one of his lectures: http://www.cs.rice.edu/~keith/512/2012/Lectures/26ReassocII-1up.pdf I can't tell, quickly, what's going on in Reassociate; as usual, the documentation resolutely avoids giving any credit for the ideas. Why is that?

On Apr 25, 2013, at 10:51 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > It's an interesting problem. > The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. > Cooper gives a nice intro in one of his lectures: http://www.cs.rice.edu/~keith/512/2012/Lectures/26ReassocII-1up.pdf > I can't tell, quickly, what's going on

Hi everyone, For reasons beyond the scope of this message, I'd like to append a NULL element to the end of a list. tmp0 <- list(a=1, b=NULL, c=3) append(tmp0, c(d=4)) ## works as expected append(tmp0, c(d=NULL)) ## list with a/b/c only Given that I could use tmp0$a <- NULL to remove 'a', I seem to understand why appending NULL returns me the original list... But how should I

Hi, I'm running into some strange errors with the CBE. I've narrowed the problem down to a very simple CPP program: main.cpp: -------------------------------------------------------------------------------- #include <string> static std::string hello("Hello world!"); int main() { return 0; }

Hi all, I have been writing a pass to heapify some alloca's (it is pessimistization, not optimization). For example, in the following control flow graph, there is a call to malloc inserted in block BB12. In order to avoid memory leak, free's are needed. The free cannot be inserted in BB23 because BB23 is not dominated by BB12. There are two ways to go I can think of here. One way is to

Hello, I am working on a AVR backend and have a version up and running that will convert LLVM IR code to assembly code for my target. I have written a bunch of instructions from the AVR Instruction Set in AVRInstrInfo.td and not much else. In a simple test case I am attempting to compile (if that is the word you are supposed to use for this operation) test.ll: define i8 @foo(i8 %a, i8 %b) {

PRE normally uses a latest placement algorithm to do something of the sort. I don't know about GVN/PRE, but older version of PRE might have it. Just placing the calls to free at the predecessors (dominated by BB12) of the dominance frontier of BB12 seems to work, however. Is there anything wrong with this? H. On Tue, Nov 12, 2013 at 11:30 PM, Bin Tzeng <bintzeng at gmail.com> wrote:

Hi Henrique, Thanks for the quick reply! On Tue, Nov 12, 2013 at 9:13 PM, Henrique Santos < henrique.nazare.santos at gmail.com> wrote: > PRE normally uses a latest placement algorithm to do something of the sort. > I don't know about GVN/PRE, but older version of PRE might have it. > Just placing the calls to free at the predecessors (dominated by BB12) of > the dominance

> > It seems that placing the calls to free at the predecessors of dominance > frontier is inadequate. It is possible that there are exit blocks that are > dominated by BB12 (calls to malloc). I guess we can also insert calls to > free at these exit blocks too. That crossed my mind a few minutes later. : ) If you're interested, PRE.cpp existed last at r25315. It calculates the

Thanks! I will try that and see whether it works. On Wed, Nov 13, 2013 at 5:01 AM, Henrique Santos < henrique.nazare.santos at gmail.com> wrote: > It seems that placing the calls to free at the predecessors of dominance >> frontier is inadequate. It is possible that there are exit blocks that are >> dominated by BB12 (calls to malloc). I guess we can also insert calls to

I'm cross-compiling for MIPS. The test-case is as simple as it can be: void foo() {} $clang -target mips64-octeon-linux -c -B path/to/cross/compiled/mips/assembler a.c And then I look at the object file: $ nm a.o 0000000000000020 t $tmp0 0000000000000000 T foo I would like to know what "$tmp0" is. Furthermore, if I pass -g to clang, I see a whole bunch of such symbols. Some of

Bill, Just in case this is relevant for you: If you're working with C++ code, or otherwise have any functions that might throw exceptions, you might also need to catch those exceptions in order to free the allocated memory. This will involve looking for calls to functions that mayThrow(), changing their calls to invokes, and freeing the memory before resuming the unwinding. -Hal -----

It seems that Tablegen is generating intrinsic ID's off by in DAGISel.inc In DAGISel.inc, I have the following pattern: int64_t CN1 = Tmp0->getZExtValue(); // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Emits: (MACRO_FMA_f32:f32 GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Pattern complexity = 8 cost

Hello, I get the following error when I kill icecast. I am running icecast2 from source on a debian unstable box. I have looked around google and tried a couple of suggestions like moving and linking the libgcc library around, without any luck. "libgcc_s.so.1 must be installed for pthread_cancel to work?" Anyone have any suggestions? Thanks, Alex Martin shorewall@rettc.com

Hi Henrique, I have tried using -mergereturn and inserting a free into the predecessors of dominance frontier of malloc block and it caused double free. It is possible for multiple free's to be inserted on the path from malloc to an exit. For example, in the following CFG: BB10 (malloc) / \ BB11 BB12 ... / \ / \

Hi, when I delete some instruction, I got some error prompt message. - %i.0.reg2mem.0 = phi i32 [ 0, %bb5 ], [ %indvar.next, %bb12 ] ; <i32> [#uses=2] - %s.0.reg2mem.0 = phi i32 [ 0, %bb5 ], [ %tmp16, %bb12 ] ; <i32> [#uses=1] - %tmp14 = tail call i32 @foobar(i32 %i.0.reg2mem.0) nounwind ; <i32> [#uses=1] - %tmp16 = add i32 %tmp14, %s.0.reg2mem.0 ; <i32>

Are you using isTarget = 1 in your intrinsics file? On Apr 14, 2009, at 6:34 PM, Villmow, Micah wrote: > It seems that Tablegen is generating intrinsic ID’s off by in > DAGISel.inc > > In DAGISel.inc, I have the following pattern: > int64_t CN1 = Tmp0->getZExtValue(); > > // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, > GPRF32:f32:$src1,

On 12/9/2016 11:03 AM, Jim Lewis via llvm-dev wrote: > > Thanks, that helps enormously! The issue is that the match is supposed > to support both cascade and tree OR patterns, but there appears to be > a problem with the tree matching. Both test1 and test6 in the ARM > tests exercise the cascade pattern, and I remember now our fix is > confined to the tree case. > > I