similar to: Problem with the LLVM v8.0 IR 'select' instruction

Hi again, It is probably me doing something wrong, but I have attached a trimmed down sample that shows the issue and the output that Clang 8.0.0 makes (using the binary release from llvm.org). I invoke clang as follows: clang -S -O3 -o Evergrowing.s -Wall Evergrowing.ll I tried using -O1, -O2, and -O3, but all where the same. Please notice that I renamed 'main()' to

Hi, I am using LLVM as the backend in a small hobby compiler project I'm working on. I plan to support all platforms that LLVM supports (limited by my available hardware only). As far as I can tell, there are different linkers for the various host systems out there (the output of 'lld' if you invoke it on Arch Linux): lld is a generic driver. Invoke ld.lld (Unix), ld64.lld

On 07/15/2019 04:01 AM, Mikael Holmén via llvm-dev wrote: > Hi, > > Same thing for me, as I described here: > > http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190708/279184.html > > I think the problem is that the patch assumes that if sys/inotify.h > exists, then IN_EXCL_UNLINK is defined in it. > > But I think that there are old versions of inotify.h

Hi Jan, our builds have been failing on Redhat linux kernel version 2.6.32 with the following error: 2019.07.15 11:10:28 ../llvm/tools/clang/lib/DirectoryWatcher/linux/DirectoryWatcher-linux.cpp:335:47: error: 'IN_EXCL_UNLINK' was not declared in this scope 2019.07.15 11:10:28 IN_CREATE | IN_DELETE | IN_DELETE_SELF | IN_EXCL_UNLINK | IN_MODIFY | this is because of the patch

Is there a easy way to copy a Value object, so it can be used in multiple instructions without a dominance issue?

Sorry, I'm a bit confused by your reply. I think part of my problem is I can only think of this in terms of Passes. For instance, my pass looks for assignments and tries to use the same pointer operand, before the assignment it finds. Like this: new ICmpInst(*block, CmpInst::ICMP_NE, shadow, store->getPointerOperand(), "Shadow check"); So I'm not sure how alloca

Hello, Presumably I have two value v1 and v2 from two different basic block A and B. Now I need to insert to a printf to print those two values at the same time. This means I need to find a basic block to insert such a calling isntruction and at the same time, the basic block should be dominated by v1 and v2. Is there any easy way to find such a basic block? Cheers, Zheng

On 9/19/11 12:53 PM, ret val wrote: > Is there a easy way to copy a Value object, so it can be used in > multiple instructions without a dominance issue? A value object can be used multiple times with no problem. The dominance problem stems from the fact that the program must be in SSA form. When the program uses a value, it must have been defined dynamically for all possible executions

On 9/19/11 2:48 PM, ret val wrote: > Sorry, I'm a bit confused by your reply. I think part of my problem is > I can only think of this in terms of Passes. > > For instance, my pass looks for assignments and tries to use the same > pointer operand, before the assignment it finds. Like this: > new ICmpInst(*block, CmpInst::ICMP_NE, shadow, >

Hi, Thanks, John, I just forgot the multi-thread issue. I'll write my own pass to handle this as for my project, it is just single-thread case. Sheng. Date: Thu, 22 May 2008 09:30:45 -0500 > From: John Criswell <criswell at cs.uiuc.edu> > Subject: Re: [LLVMdev] Eliminate Store-Load pair even the LoadInst is > volatile > To: LLVM Developers Mailing List

Hi all, I put a case into llvm and got the following .ll code: ... %r1419_0_0_0_i376 = alloca i32 ; <i32*> [#uses=2] ... %tmp1476_i = lshr i32 %tmp1226_i, 24 ; <i32> [#uses=1] store i32 %tmp1476_i, i32* %r1419_0_0_0_i376, align 4 %tmp1505_i = volatile load i32* %r1419_0_0_0_i376, align 4 ; <i32> [#uses=1] %tmp1542_i = getelementptr [256 x i8]* @Te, i32 0, i32 %tmp1505_i ...

On Wed, May 23, 2012 at 6:12 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Thanks for the quick reply.  I had a feeling that it was due to missing > Windows support in clang++ and LLVM. > > """ > This is due to clang not understanding force_inline. These functions > are defined in a header included from Windows.h, so it ends up getting > a definition

Hi Jon, > >From what I have understood of the LLVM docs about when tail calls get > eliminated on x86 and x64 it should be a tail call, yes. > > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > . Caller and callee have the calling convention fastcc. > . The call is a tail call - in tail position (ret immediately follows call and > ret uses value of call or

Hello Duncan and Jon, I am the criminal responsible for the tail call implementation in the backends. On Mon, Feb 23, 2009 at 9:17 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jon, > >> >From what I have understood of the LLVM docs about when tail calls get >> eliminated on x86 and x64 it should be a tail call, yes. See below. > this list is for the code

Hello everyone, I am writing a pass to instrument program and count how many basic block executed. What I have tried is to instrument a local counter inside each function, add 1 to the local counter inside each basic block, and save the counter value to a global counter. The current runtime overhead is around 25%. Is there any way I can try to lower the overhead? Like keeping the local counter

Thanks for the quick reply. I had a feeling that it was due to missing Windows support in clang++ and LLVM. """ This is due to clang not understanding force_inline. These functions are defined in a header included from Windows.h, so it ends up getting a definition everywhere it is included. """ How much work would it take to add support for force_inline? Are there

On Sunday 22 February 2009 20:36:52 Duncan Sands wrote: > Hi Jon, > > > I have written a variety tests of tail calls for my HLVM and all passed > > with flying colors until I wrote this test (which is actually for > > algebraic datatypes) and discovered that it segfaults after ~100k > > iterations through what I think should be a tail call. Here's the IR: >

While working on my optimization pass (a Function Pass), I try to replicate a call instruction and insert it at some earlier location (similar to LICM). However, the instruction I am trying to replicate has dependencies on an uncertain number of instructions that are used to generate an address. A simple example (IR segment): define void @foo() nounwind { entry: %a = alloca i32, align 4;

On 1/26/18 1:04 AM, Linhai Song via llvm-dev wrote: > > Hello everyone, > > > I am writing a pass to instrument program and count how many basic > block executed. What I have tried is to instrument a local counter > inside each function, add 1 to the local counter inside each basic > block, and save the counter value to a global counter. The current > runtime

Dear Chuck, I haven't read all of the details, but it seems that what you need to do is to clone defs before you clone any uses of the def. To do that, you want to iterate over the instructions in dominator-tree order. To do that, you first construct the dominator tree (there is an LLVM analysis pass that does that). Then, you iterate over the basic blocks in the dominator tree from