similar to: Finding label of basic block where a conditional branch merges

Joshua, David much appreciate your quick help! What I am actually doing is statically tracing values. If one of the traced values is part of a condition (e.g. in an if statement) all instructions in the then and else part are also traced. The automatic tracing of instructions however needs to stop when I hit the first instruction after the if statement (same for switch). Dominators seem to be a

Hi all, I have the following test case: #define FLT_EPSILON 1.19209290E-7 int err = -1; int main() { float a = 8.1; if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am using FLT_EPSILON to check whether (a != 2.0). err = 1; } else { err = 0; } return 0; } with -O3 optimization level clang generates already incorrect LLVM IR: ; Function Attrs:

It seems there is no -enable-iv-rewrite now in llvm3.2, and it suggest -enable-load-pre, but it still does not work. So, how to active the transform? -- View this message in context: http://llvm.1065342.n5.nabble.com/indvars-issues-tp4646p58587.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Hello . I'm trying to implement FunctionPass for detecting loops in llvm IR. How can I get <condition> for loop from llvm::Loop object.? Is there any example? Thanks in advance, Edvard  -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120723/85e7f2f9/attachment.html>

The LRM (http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic) essentially states that: - ptr is dead before a call to "lifetime.start size, ptr" - ptr is dead after a call to "lifetime.end size, ptr" This is all good and fine, and the expected use case is that all "lifetime.end size, ptr" markers are matched with a preceding "lifetime.start

Hi! I'm having some trouble with a pass I'm writing. I'm using DemotePHIToStack to remove all phi node in my code with this code (this is the first thing I do in my pass): // Erase phi node vector<PHINode*> phis; for (Function::iterator i=f->begin();i!=f->end();++i) { for(BasicBlock::iterator b=i->begin();b!=i->end();++b) {

In your original file, %6 is defined in if.end11 and is used in cond.end. if.end11 branches to cond.true and cond.false, both of which branch unconditionally to cond.end. Therefore %6 dominates its use. In your second file %18 is defined in end.11 and used in cond.end. However, end.11 no longer dominates cond.end because you have rewritten all branches to go through the switch statement in

I'd missed the fact that j wasn't just being decremented. This isn't as easy as I said. Philip On 03/03/2016 02:36 PM, Philip Reames via llvm-dev wrote: > SCEV should be able to easily prove that j is positive here. I'm not > sure where the right place to use that information would be in this > case. Sanjoy, can you comment? > > Philip > > On 03/03/2016

Hi Gerolf, I think we have several (perhaps separable) issues here: 1. Do we have a canonical form for loops, preserved through the optimizer, that allows naturally-constructed loop nests to remain separable? 2. Do we forbid non-lowering transformations that turn vectorizable loops into non-vectorizable loops? 3. How do we detect cases where transformations cause a negative answer to either

I have been investigating missing variables / incorrect variable values when debugging code compiled at -O1 (and above) and believe that I have tracked the issue down to the interaction of the generation of IR @llvm.dbg.value entries and phi nodes. I would welcome someone who is more familiar with the generation of debug information to help me determine if what I think is going wrong is correct

This email is related with the code of commit: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20120409/140650.html. This commit will let our unconditional branch instruction not be deleted when its successor is the nature layout and its basic block's instruction only one instruction. However, I have some concerns about it, especially in the debug mode. Let me show you some

Hi, InstCombine canonicalizes index operands (unless they are into struct types) to pointer size. The comment says: "If we are using a wider index than needed for this platform, shrink it to what we need. If narrower, sign-extend it to what we need. This explicit cast can make subsequent optimizations more obvious.". For our architecture, the canonicalization is a bit

Hi all, TL;DR: Should the loop guard branch be part of the canonical loop structure? Background: ----------- While working on the next set of improvements to loop fusion, we discovered that loop rotation will put a guard around a loop if it cannot prove the loop will execute at least once, as seen in the following (simplified) example: entry: br i1 %cmp1, label %for.body.lr.ph, label

The frontend code is a pretty simple for loop, that counts from i = 0; i != 10; i += 1 It gets optimized into and endless loop. export fn entry() void { var array: [10]Bar = undefined; var x = for (array) |elem, i| { if (i == 1) break elem; } else bar2(); } Here's the generated IR: ; ModuleID = 'test' source_filename = "test" target datalayout =

I'm going to show the same function, first normally, and then as a coroutine, and show how gdb can see the variable when it's a normal function, but not when it's a coroutine. I'd like to understand if this can be improved. I'm trying to debug a real world problem, but the lack of debug info on variables in coroutines is making it difficult. Should I file a bug? Is this a

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: 04 November 2014 17:16 > To: Arnaud De Grandmaison > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] lifetime.start/end clarification > > ----- Original Message ----- > > From: "Arnaud A. de Grandmaison" <arnaud.degrandmaison at arm.com> > > To:

Hi, I'm getting: Unhandled exception at 0x00C211F0 in ConsoleApplication830.exe: 0xC00001A5: An invalid exception handler routine has been detected (parameters: 0x00000001). With some fairly simple SEH enabled routine: define i32 @__elements_entry_point_main(%._gt2a_RemObjects_d_Elements_d_System_d_Array_t_1s*) #0 personality i8* bitcast (i32 ()* @_elements_exception_handler to i8*) !dbg

I am studying the Transform/Scalar/LICM.cpp pass, and wrote a simple test program to validate. void testLICM(void){ int i,N=100; int data; for(i=0;i<N;i++){ data = 1; printf("i: %d\n",i); } printf("data: %d\n", data); } I expect the "data=1" will be moved out of loop (either hoist or sink). However, to my surprise, that statement

Indeed, it's 32bits x86 and there's no .safeseh or anything like it, even readobj -coff-load-config says nothing: File: ConsoleApplication830.exe Format: COFF-i386 Arch: i386 AddressSize: 32bit Now I know what to look for, thanks! On Mon, Aug 20, 2018, at 18:46, Reid Kleckner wrote: > This is 32-bit x86, right? Sounds like the exception handler did not > appear in the /safeseh

On Mon, Jun 19, 2017 at 12:06 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > Hi, > > 2017-06-19 8:45 GMT-07:00 Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Greetings, >> >> I have a Zig implementation of ceil which is emitted into LLVM IR like >> this: >> >> ; Function Attrs: nobuiltin nounwind >> define