similar to: [LLVMdev] Eliminating gotos

On Aug 11, 2008, at 2:02 PM, Benedict Gaster wrote: > We would like to develop a code generator using LLVM for a target > language that does not support conditional branches and in fact only > supports structured control flow, eg. If and while. What's the difference between an "if" and a conditional branch? > As far as I can tell that the problem with doing this in

Hi, Comments inline. Ben On 12/08/2008 03:14, "Owen Anderson" <resistor at mac.com> wrote: >> We would like to develop a code generator using LLVM for a target language >> that does not support conditional branches and in fact only supports >> structured control flow, eg. If and while. What's the difference between an "if" and a conditional

Hi Mon Ping, Discussing this with others in AMD it came up if it is possible for LLVM to take a program that has a reducible graph (any C code without goto/setjmp) and generate one that is irreducible? If it is the case that the code is actually structured coming in, a simple pattern matcher could turn everything into if/endif and so on. Ben On 14/08/2008 18:39, "Mon P Wang"

Hi, That is interesting. Do you have any pointers to the test cases in question? The problem is that we don't have conditional branches and so we are going to have to do some form of goto elimination and as such do you have any alternatives in mind? Thanks, Ben On 12/08/2008 16:40, "Daniel Berlin" <dberlin at dberlin.org> wrote: >> [bg] Actually this does not need

Hi, I like Eli approach here. Phases like SimplifyCFG and various loop transformations are just to useful to cleanup code and generate much high quality output. If we look at the passes, I hope we might be able to quantify what changes they make. My hope is that since the incoming graph is reducible that it doesn't cost that much after running these phases to make them reducible

On Thu, Aug 14, 2008 at 2:55 PM, Benedict Gaster <benedict.gaster at amd.com> wrote: > Hi Mon Ping, > > Discussing this with others in AMD it came up if it is possible for LLVM to > take a program that has a reducible graph (any C code without goto/setjmp) > and generate one that is irreducible? If it is the case that the code is > actually structured coming in, a simple

Hi Owen, On 12/08/2008 16:52, "Owen Anderson" <resistor at mac.com> wrote: > > SNIP > > > I'm still not seeing how these two are any different. You just replace the > text of "if" with "br", and add the explicit target labels. I should also > point out that, in LLVM IR, the order the blocks are laid out in is not > meaningful

On Aug 12, 2008, at 2:39 AM, Benedict Gaster wrote: > [bg] Consider the LLVM code: > > define i32 @foo(i32 %x, i32 %y) { > entry: > %tobool = icmp eq i32 %x, 0 ; <i1> [#uses=1] > br i1 %tobool, label %ifelse, label %ifthen > > ifthen: ; preds = %entry > %add = add i32 %x, 10 ; <i32> [#uses=1] > ret i32 %add > >

Hi Ben, On Aug 12, 2008, at 11:36 AM, Benedict Gaster wrote: > Hi Owen, > > On 12/08/2008 16:52, "Owen Anderson" <resistor at mac.com> wrote: > >> >> SNIP >> >> >> I'm still not seeing how these two are any different. You just >> replace the text of "if" with "br", and add the explicit target >>

On Thu, Oct 01, 2015 at 07:09:02PM +0300, Roman Kagan wrote: > On Thu, Oct 01, 2015 at 04:22:14PM +0100, Richard W.M. Jones wrote: > > On Thu, Oct 01, 2015 at 06:04:03PM +0300, Roman Kagan wrote: > > > On Mon, Aug 10, 2015 at 06:55:28PM +0300, Roman Kagan wrote: > > > > Libguestfs supports passing an ISO image as a source of virtio windows > > > > drivers

> [bg] Actually this does not need to be the case. The paper that I sighted > does not use code replication to resolve irreducible control flow but > instead introduces a loop construct. We implemented this in GCC back when we first started GIMPLE (since GIMPLE is based on the IL the authors of that paper used in their compiler), and the code size increases on a bunch of testcases were

I'm probably missing something simple here but in: CGDebugInfo.h: std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; but then in CGDebugInfo.cpp: llvm::DIType TC = getTypeOrNull(Ty); void * v = Ty.getAsOpaquePtr(); std::pair<void *, llvm::WeakVH> tmp = std::make_pair(v, TC); if (TC.Verify() && TC.isForwardDecl())

Hi Ben, Thanks that helped a lot. The problem seems to be that with the move to C++11 we now have: void std::vector<_Ty>::push_back(std::pair<_Ty1,_Ty2> &&)' and there no conversion operator that can be applied to convert: 'std::pair<_Ty1,_Ty2>' to 'std::pair<_Ty3,_Ty4> && Where: [ _Ty1=void *,

On 09.08.2012, at 19:43, "Gaster, Benedict" <Benedict.Gaster at amd.com> wrote: > I’m probably missing something simple here but in: > > CGDebugInfo.h: > > std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; > > but then in > > CGDebugInfo.cpp: > > llvm::DIType TC = getTypeOrNull(Ty); > > void * v =

The following code causes opt to not terminate! With TOT this morning, and of a week ago: clang foo.c and clang -O1 foo.c work fine. clang -O2 foo.c and clang -O3 foo.c do not terminate. (At least after 10 minutes) If I generate the bit code (clang-cc -emit-llvmbc) and then run: opt -O3 foo.bc it does not terminate. //foo.c int get_id(int); typedef short

Hi Eli, Thanks for the response I have one question inline. Regards, Ben [...] > The main problem that I have hit is regarding the use of CL register in the > shift instructions. The problem is that ATT syntax states that it should be > referenced as "%cl" while Intel says just "cl" but these references occur in > X86InstInfo.td and this means that it is shared

Hi Eli, Yep I was being stupid. Please find attached a patch for initial changes to get MASM working. There is still one problem that I am looking into around changing alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256 alignments, default being 16, but LLVM is sometimes generating 32 alignment, for example, consider the following code: float bar(float fy, float fx) {

On 2008-07-07, at 05:40, Benedict Gaster wrote: > %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* > %ptr0, i32 4) > %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* > %ptr11, i32 4) > call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 false, > i32 11, i1 false) ; force read-modify-write %ptr11 to complete > > A problem with

Hi Eli, Sorry about that Visual Studio seems to have inserted tabs and I used an internal diff tool. Anyway, I synced TOT LLVM and made the changes with Emacs and the svn diff is attached. Regards, Ben -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, June 16, 2009 11:19 AM To: LLVM Developers

On Fri, Sep 4, 2009 at 9:37 AM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote: > The following code causes opt to not terminate! Please flle in bugzilla with a bitcode testcase; it would help to reduce the testcase using bugpoint. -Eli