similar to: [LLVMdev] reg2mem pass

Thank you for this comment, Mike. So... your suggestion is to make a valid transform for each loop like: >for (;C;) { > S >} > >is to transform: > >top: >if (!C) goto end; > S >goto top; >end: For now, my code is incomplete so not ready to present for audit yet but I hope it asap. In fact, I couldn't understand what you said: >The cost of the .pdf

Hello. I updated my LLVM with version 2.1 from 1.9. But I am curious why I still have signed integer type. I still get LLVM IR as follows: ...... ...... bb8.outer: ; preds = %bb10, %entry %i.0.0.ph = phi uint [ 0, %entry ], [ %indvar.next26, %bb10 ] ; <uint> [#uses=2] %sum.0.pn.ph = phi uint [ 0, %entry ], [ %sum.1, %bb10 ] ; <uint> [#uses=1] br label %bb8 bb3: ; preds = %bb8

I didn't 'cause my llvm-gcc just seems to be 4.0: ]$ llvm-gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../llvm-gcc4-1.9.source/configure --prefix=/mounts/zion/disks/0/localhome/tbrethou/llvm-gcc4/obj/../install --enable-llvm=/localhome/tbrethou/llvm --enable-languages=c,c++ --disable-threads Thread model: single gcc version 4.0.1 LLVM (Apple Computer, Inc. build

Dear Prof.Adve and Bill, I deeply appreciate your comments and concerns. (Please forgive my late response. I've tried some more cases to make this issue) As Prof.Adve mentioned, I need to explain exactly what my problem is, but I have no good ability that I can explain it in this plain text space. For this reason, I made a .pdf file and linked it as follows:

I have what appears to be a bug in LLVM... I'm deeply hesitant to label it a bug, given my lack of experience with LLVM, but the behaviour of this fragment strongly suggests a bug. In particular, compiling and running this fragment using a fresh SVN build yields this stderr: uccello:/tmp clements$ lli a.out.bc 0 lli 0x005e72b6 char const* std::find<char const*,

Wow... Thank you so much for this. I'll try this one. Thanks again, Wojciech. SJL ---- Original message ---- >Date: Sat, 15 Sep 2007 15:07:34 +0200 >From: Wojciech Matyjewicz <wmatyjewicz at fastmail.fm> >Subject: Re: [LLVMdev] constructing 'for' statement from LLVM bitcode >To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > >Hi, >

Dear Wojciech Matyjewicz: Thank you for your advice. I could follow what you had suggested upto opt -analyze -loops bsloop-opt.bc Therefore, I could get the prints you had showed me as follows: -------------------------------------------------------- Printing analysis 'Natural Loop Construction' for function 'bsloop': Loop Containing: %bb16, %bb13, %bb8, %bb1 Loop

Hi All, I need to write as text files 1000 ish variation of the same data frame, once I permute a row. I would like to use the function write.table() to write the files, and use a loop to do it: for (i in 1:1000){ bb8[2,] = sample(bb8[2,]) write.table(bb8, quote = F, sep = '\t', row.names = F, col.names = F, file = 'whatever?????.txt') } so all the files are called

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Nov 21, 2011 at 10:30 AM Subject: Re: [LLVMdev] Order of Basic Blocks To: Benjamin Kramer <benny.kra at googlemail.com> This worked, though the RPO_iterator apparently wasn't what I was looking for anyways, it seems it doesn't rreally go top->down. I have a simple example code,

Hi, Found CloneBasicBlock utility only does the cloning without any remapping. Consider below example: Input block: sw.epilog: ; preds = %sw.bb20, %sw.bb15, %sw.bb10, %sw.bb6, %sw.bb2, %sw.bb, %while.body, %if.end29 %no_final.1 = phi i32 [ %no_final.055, %while.body ], [ 1, %if.end29 ], [ %no_final.055, %sw.bb20 ], [ %no_final.055, %sw.bb15 ], [

Hi, I've stumbled upon a case where I think gvn does a bad (wrong) optimization. It's a bit messy to debug though so I'm not sure if I should just write a PR about it a let someone who knows the code look at it instead. Anyway, for the bug to trigger I need to run the following passes in the same opt invocation: -sroa -instcombine -simplifycfg -instcombine -gvn The problem

Try breaking the critical edges (-break-crit-edges). This way, a new block will be created between BB13 and BB11 (call this BB11.break) and BB15 and BB12 (call this BB12.break). The predecessors of the dominance frontier will, thus, be BB11.break, BB12.break, and BB14. When we enter through a block with a call to malloc(), we will end up in one of the blocks in the dominance frontier (kind of).

Hi Sanjay, unfortunately that patch does not help in my case. Here's the IR that fails to get fully optimized: target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" define fastcc zeroext i1 @testfunc(i8** noalias nocapture readonly dereferenceable(8)) unnamed_addr { entry-block: %1 = load i8*, i8**

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 Björn and Daniel, FoldPHIArgOpIntoPHI() is for unary ops (casts), but it calls FoldPHIArgBinOpIntoPHI() for binops which takes care of almost everything else? My minimal patch idea is to ease the restriction in ShouldChangeType because i1 is special. I tried the patch below, and it works on the example...and nothing in 'make check' failed. :) Index:

So, that means that &&(Label) operator, which is defined in C++, is also not supported currently in LLVM. I thought I could obtain address of basic block indirectly through this small hack but it does not seem to work. Actually, I tried to make folloing dummy C++ code which uses this operator: *int main(int argc,char** argv) { int x; int y; L1:

Here's a working testcase: ; ModuleID = '/tmp/crtbegin.bc' target datalayout = "E-p:32:32:128-i1:8:128-i8:8:128-i16:16:128-i32:32:128-i64:32:128-f32:32:128-f64:64:128-v64:64:64-v128:128:128-a0:0:128-s0:128:128" target triple = "spu" @__dso_handle = hidden global i8* null, align 16 ; <i8**> [#uses=0] @__CTOR_LIST__ = internal global [1 x void

Jakub Staszak wrote: > Hi, > > It looks like PDT.getRootNode() returns NULL for: > > define fastcc void @c974001__lengthy_calculation. > 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { > entry: > br label %bb > > bb: > br label %bb > } > > > Isn't it a bug in PostDominatorTree? > > Please note that this crashes: >

Evan: Sorry for the late follow up, I was out of town last week. Enclosed please find the updated patch including all your suggestions and a dejagnus test. Robert On Thu, Jun 11, 2009 at 2:27 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 8, 2009, at 2:42 PM, robert muth wrote: > > > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>