From edwintorok at gmail.com Fri May 1 01:44:36 2009 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Fri, 01 May 2009 09:44:36 +0300 Subject: [LLVMdev] Pulling line number/file/path information from DbgStopPointInst instructions In-Reply-To: <29AE4FAD-61F0-4C52-8AB9-AB911BEDC1AC@findatlantis.com> References: <2FCB30C2-7561-417A-876C-F752A44EF3E8@findatlantis.com> <16e5fdf90904291829t234a305dg2f8fff0457390b33@mail.gmail.com> <29AE4FAD-61F0-4C52-8AB9-AB911BEDC1AC@findatlantis.com> Message-ID: <49FA9A54.2010307@gmail.com> On 2009-04-30 04:43, Sarah Thompson wrote: > Hmm... if I do a print() on the result of getFileName(), I get > > i8 * getelementptr ([9 x i8]* @.str, i32 0, i32 0) > > back, but if I try to dyn_cast this to GetElementPtrInst it fails > (returning null), so presumably I'm seeing a > GetElementPtrConstantExpr... so how can I get at that constant i8 > array without casting to a GetElementPtrInst, and with > GetElementPtrConstantExpr being inaccessible to user code? > Look at lib/Analysis/DbgInfoPrinter.cpp in trunk: void PrintDbgInfo::printStopPoint(const DbgStopPointInst *DSI) { if (PrintDirectory) { std::string dir; GetConstantStringInfo(DSI->getDirectory(), dir); Out << dir << "/"; } std::string file; GetConstantStringInfo(DSI->getFileName(), file); Out << file << ":" << DSI->getLine(); if (unsigned Col = DSI->getColumn()) { Out << ":" << Col; } } There are also some helpers for finding the stoppoints in the same class. Best regards, ---Edwin From jay.foad at gmail.com Fri May 1 03:04:26 2009 From: jay.foad at gmail.com (Jay Foad) Date: Fri, 1 May 2009 09:04:26 +0100 Subject: [LLVMdev] support for division by constant in APInt In-Reply-To: <06DEFDFD-5C37-44C6-883A-370D739FF92A@apple.com> References: <06DEFDFD-5C37-44C6-883A-370D739FF92A@apple.com> Message-ID: > The patch looks fine to me, does it pass regression tests etc? ?If so, > please apply, or contact me off list if you don't yet have commit > access. ?Thanks Jay! Committed here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090427/076916.html Thanks! Jay. From nicolas at capens.net Fri May 1 05:32:37 2009 From: nicolas at capens.net (Nicolas Capens) Date: Fri, 1 May 2009 12:32:37 +0200 Subject: [LLVMdev] PointerIntPair causing trouble Message-ID: <000301c9ca48$25fec740$71fc55c0$@net> Hi all, I've located a regression that causes my project to crash. It's in revision 67979, where PointerIntPair is changed from storing the integer in the upper bits instead of the lower bits. My project is an experimental JIT-compiler in Windows. So I was wondering if anyone had any clue why the new PointerIntPair implementation might fail. It doesn't seem very safe to me to store other data into a pointer to begin with, but surely the lower bits must be a safer location than the upper bits? The actual crash I'm seeing is preceded by an assert in X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing backward, I'm seeing a MachineInstr with opcode MOV32rm and NumOperands equal to 6 (which is 5 in earlier revisions). I'm not sure if this actually helps explain the bug but it's one of the weird things that happen with revision 67979 and subsequent revisions. All help appreciated. Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/3875d3cb/attachment.html From stefanus.dutoit at rapidmind.com Fri May 1 08:09:03 2009 From: stefanus.dutoit at rapidmind.com (Stefanus Du Toit) Date: Fri, 1 May 2009 09:09:03 -0400 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <000301c9ca48$25fec740$71fc55c0$@net> References: <000301c9ca48$25fec740$71fc55c0$@net> Message-ID: Hi Nicolas, On 1-May-09, at 6:32 AM, Nicolas Capens wrote: > I?ve located a regression that causes my project to crash. It?s in > revision 67979, where PointerIntPair is changed from storing the > integer in the upper bits instead of the lower bits. My project is > an experimental JIT-compiler in Windows. We're looking into a similar bug right now. We see the problem elsewhere (early on in optimization, during the first instcombine pass) but it sounds like the same issue. We'll let you know when we know more. > So I was wondering if anyone had any clue why the new PointerIntPair > implementation might fail. It doesn?t seem very safe to me to store > other data into a pointer to begin with, but surely the lower bits > must be a safer location than the upper bits? Just to be clear, PointerIntPair doesn't (AFAIK) store the integer in the "high bits" of the pointer. It just uses the "higher parts" of the "low available bits" of the pointer. So, if a pointer is always aligned such that it always has 4 bits clear on the low side, and you only need to store one bit, it'll be stored in bit 3 (counting from the LSB towards the MSB). It may be that the alignment assumptions being made are simply wrong on Windows. So far we've been trying to track down whether this is actually the cause or if something's wrong with the Module coming into InstCombine, but given that you're seeing a similar problem elsewhere, it's not unlikely that this is the real cause. > The actual crash I?m seeing is preceded by an assert in > X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing > backward, I?m seeing a MachineInstr with opcode MOV32rm and > NumOperands equal to 6 (which is 5 in earlier revisions). I?m not > sure if this actually helps explain the bug but it?s one of the > weird things that happen with revision 67979 and subsequent revisions? -- Stefanus Du Toit RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/82133c08/attachment.html From stefanus.dutoit at rapidmind.com Fri May 1 08:33:21 2009 From: stefanus.dutoit at rapidmind.com (Stefanus Du Toit) Date: Fri, 1 May 2009 09:33:21 -0400 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: References: <000301c9ca48$25fec740$71fc55c0$@net> Message-ID: <090ED33B-1D59-4343-B29F-1281BFC52910@rapidmind.com> On 1-May-09, at 9:09 AM, Stefanus Du Toit wrote: > It may be that the alignment assumptions being made are simply wrong > on Windows. After quickly rereading the code for PointerIntPair this actually seems extremely unlikely, since there are nice asserts in the proper places. Stefanus -- Stefanus Du Toit RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 From czoccolo at gmail.com Fri May 1 08:37:01 2009 From: czoccolo at gmail.com (Corrado Zoccolo) Date: Fri, 1 May 2009 15:37:01 +0200 Subject: [LLVMdev] Stack alignment in JIT compiled code In-Reply-To: References: <1241126326.8030.27.camel@gnarf-laptop> Message-ID: <4e5e476b0905010637q72474e89p5b119ab81f33f3b@mail.gmail.com> On Linux x86_64, it is different. The x86-64 ABI says (http://www.x86-64.org/viewvc/trunk/x86-64-ABI/low-level-sys-info.tex?revision=84&content-type=text%2Fplain): >> The end of the input argument area shall be aligned on a 16 byte boundary. In other words, the value (%rsp - 8) is always a multiple of 16 when control is transferred to the function entry point. The stack pointer, %rsp, always points to the end of the latest allocated stack frame. << The libc itself assumes it in that way, and does no stack realignment. You can look for example at snprintf disassembly, that dumps SSE registers on the stack: 0x00002b4b13522b60 : sub $0xd8,%rsp 0x00002b4b13522b67 : mov %rcx,0x38(%rsp) 0x00002b4b13522b6c : movzbl %al,%ecx 0x00002b4b13522b6f : mov %r8,0x40(%rsp) 0x00002b4b13522b74 : lea 0x0(,%rcx,4),%rax 0x00002b4b13522b7c : lea 50(%rip),%rcx # 0x2b4b13522bb5 0x00002b4b13522b83 : mov %r9,0x48(%rsp) 0x00002b4b13522b88 : sub %rax,%rcx 0x00002b4b13522b8b : lea 0xcf(%rsp),%rax 0x00002b4b13522b93 : jmpq *%rcx 0x00002b4b13522b95 : movaps %xmm7,0xfffffffffffffff1(%rax) 0x00002b4b13522b99 : movaps %xmm6,0xffffffffffffffe1(%rax) 0x00002b4b13522b9d : movaps %xmm5,0xffffffffffffffd1(%rax) 0x00002b4b13522ba1 : movaps %xmm4,0xffffffffffffffc1(%rax) 0x00002b4b13522ba5 : movaps %xmm3,0xffffffffffffffb1(%rax) 0x00002b4b13522ba9 : movaps %xmm2,0xffffffffffffffa1(%rax) 0x00002b4b13522bad : movaps %xmm1,0xffffffffffffff91(%rax) 0x00002b4b13522bb1 : movaps %xmm0,0xffffffffffffff81(%rax) 0x00002b4b13522bb5 : lea 0xe0(%rsp),%rax 0x00002b4b13522bbd : mov %rsp,%rcx 0x00002b4b13522bc0 : movl $0x18,(%rsp) 0x00002b4b13522bc7 : movl $0x30,0x4(%rsp) 0x00002b4b13522bcf : mov %rax,0x8(%rsp) 0x00002b4b13522bd4 : lea 0x20(%rsp),%rax 0x00002b4b13522bd9 : mov %rax,0x10(%rsp) 0x00002b4b13522bde : callq 0x2b4b1353eb60 0x00002b4b13522be3 : add $0xd8,%rsp 0x00002b4b13522bea : retq Corrado On Fri, May 1, 2009 at 12:48 AM, Anton Korobeynikov wrote: > Hello, Simon > >> So far, i found no way to denote calls to the host function as aligned >> or maintain stack alignment throughout the stack frame of the jit >> compiled function. Further, the gcc front end (llvm-g++ (GCC) 4.2.1) >> seems to ignore directives such as -mpreferred-stack-boundary. > Mike is right. It depends on your subtarget: > > 1. If you're running stuff on Darwin, which has 16-byte aligned stack, > then this is JIT bug > 2. If you're running stuff on Linux/Windows which has 4 bytes aligned > stack, then it is a bug in your host code. It should not assume any > particular "extra" stack alignment as defined in platform ABI. And if > it does require such extra alignment it should do stack realignment by > itself (for example, LLVM itself does so if function is doing some > vector math which requires SSE2 code). > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:czoccolo at gmail.com PhD - Department of Computer Science - University of Pisa, Italy -------------------------------------------------------------------------- From aph at redhat.com Fri May 1 09:27:58 2009 From: aph at redhat.com (Andrew Haley) Date: Fri, 01 May 2009 15:27:58 +0100 Subject: [LLVMdev] Stack alignment in JIT compiled code In-Reply-To: <4e5e476b0905010637q72474e89p5b119ab81f33f3b@mail.gmail.com> References: <1241126326.8030.27.camel@gnarf-laptop> <4e5e476b0905010637q72474e89p5b119ab81f33f3b@mail.gmail.com> Message-ID: <49FB06EE.5020008@redhat.com> Corrado Zoccolo wrote: > On Linux x86_64, it is different. The x86-64 ABI says > (http://www.x86-64.org/viewvc/trunk/x86-64-ABI/low-level-sys-info.tex?revision=84&content-type=text%2Fplain): > > The end of the input argument area shall be aligned on a 16 byte boundary. > In other words, the value (%rsp - 8) is always a multiple of 16 when control is > transferred to the function entry point. The stack pointer, %rsp, > always points to > the end of the latest allocated stack frame. > << > > The libc itself assumes it in that way, and does no stack realignment. That's right. If you want to be able to call any code produced by gcc, you have to preserve 16-alignment. gcc-generated code does not realign the stack pointer. Andrew. From anton at korobeynikov.info Fri May 1 09:43:35 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Fri, 1 May 2009 18:43:35 +0400 Subject: [LLVMdev] Stack alignment in JIT compiled code In-Reply-To: <4e5e476b0905010637q72474e89p5b119ab81f33f3b@mail.gmail.com> References: <1241126326.8030.27.camel@gnarf-laptop> <4e5e476b0905010637q72474e89p5b119ab81f33f3b@mail.gmail.com> Message-ID: Hello, Corrado > The end of the input argument area shall be aligned on a 16 byte boundary. > In other words, the value (%rsp - 8) is always a multiple of 16 when control is > transferred to the function entry point. The stack pointer, %rsp, > always points to > the end of the latest allocated stack frame. That's correct. x86-64/linux has stack alignment specified as 16 in ABI. That's why no stack realignment is needed at all. As was already mentioned - without extra information about particular subtarget it's hard to say something definite here. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From anton at korobeynikov.info Fri May 1 10:04:03 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Fri, 1 May 2009 19:04:03 +0400 Subject: [LLVMdev] Stack alignment in JIT compiled code In-Reply-To: <49FB06EE.5020008@redhat.com> References: <1241126326.8030.27.camel@gnarf-laptop> <4e5e476b0905010637q72474e89p5b119ab81f33f3b@mail.gmail.com> <49FB06EE.5020008@redhat.com> Message-ID: Hello, Andrew > That's right. ?If you want to be able to call any code produced by gcc, > you have to preserve 16-alignment. ?gcc-generated code does not realign > the stack pointer. This was for gcc < 4.4, where stack alignment handling was really messy. stack-realignment branch was merged afair into gcc 4.4 and allows automatic realignment of stack, when necessary. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From vargaz at gmail.com Fri May 1 10:40:01 2009 From: vargaz at gmail.com (Zoltan Varga) Date: Fri, 1 May 2009 17:40:01 +0200 Subject: [LLVMdev] [PATH] Fixes for the amd64 JIT code Message-ID: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> Hi, The attached patch contains the following changes: * X86InstrInfo.cpp: Synchronize a few places with the code in X86CodeEmitter.cpp * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it is not neeed. Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/fe30fbd0/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.diff Type: text/x-diff Size: 3431 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/fe30fbd0/attachment-0001.bin From clattner at apple.com Fri May 1 11:04:49 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 1 May 2009 09:04:49 -0700 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: References: <000301c9ca48$25fec740$71fc55c0$@net> Message-ID: On May 1, 2009, at 6:09 AM, Stefanus Du Toit wrote: > Hi Nicolas, > > On 1-May-09, at 6:32 AM, Nicolas Capens wrote: >> I?ve located a regression that causes my project to crash. It?s in >> revision 67979, where PointerIntPair is changed from storing the >> integer in the upper bits instead of the lower bits. My project is >> an experimental JIT-compiler in Windows. > > We're looking into a similar bug right now. We see the problem > elsewhere (early on in optimization, during the first instcombine > pass) but it sounds like the same issue. We'll let you know when we > know more. > >> So I was wondering if anyone had any clue why the new >> PointerIntPair implementation might fail. It doesn?t seem very safe >> to me to store other data into a pointer to begin with, but surely >> the lower bits must be a safer location than the upper bits? > > Just to be clear, PointerIntPair doesn't (AFAIK) store the integer > in the "high bits" of the pointer. It just uses the "higher parts" > of the "low available bits" of the pointer. So, if a pointer is > always aligned such that it always has 4 bits clear on the low side, > and you only need to store one bit, it'll be stored in bit 3 > (counting from the LSB towards the MSB). FWIW, the reason it does this is to allow composable pointerintpairs, for example, PointerIntPair< PointerIntPair, 2> can use the low 3 bits as two different bitfields. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/3af56906/attachment.html From clattner at apple.com Fri May 1 11:44:39 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 1 May 2009 09:44:39 -0700 Subject: [LLVMdev] DominatorTrees, DominanceFrontiers, interfaces and cloning In-Reply-To: References: Message-ID: <3F02FBF0-C8C6-4F78-9A85-CEF1AF3C58A7@apple.com> On Apr 30, 2009, at 5:28 PM, Nick Johnson wrote: > Hello, > > I have a transform that, given a function F, will produce a new > function G such that the basic blocks of G are (copies of) a subset of > the basic blocks of F, and such that control flow is connected as you > would expect. Given DominatorTree and DominanceFrontier of F, I would > also like to efficiently compute DominatorTrees and DominanceFrontiers > of G. I understand how to do this mathematically, but I'm having some > problems with the llvm codebase. > > I have two questions: > > (1) Is there any way to clone a DominatorTree or DominanceFrontier > object, so that I can modify the cloned copy? It looks like Pass > makes the copy constructor private... The passes aren't designed to be used like this, but you could extend them if you want. > (2) Is there any reason why functions (such as PromoteMemToReg) accept > parameters of types DominatorTree and DominanceFrontier instead of > types DominatorTreeBase and DominanceFrontierBase? It seems to me > that they should accept the abstract interface instead of the > implementation (and avoid the extra baggage of a pass). DomintatorTree (and friends) isn't designed to be an abstract interface. There is supposed to be exactly two subclasses of DominatorTreeBase: one for forward and one for reverse dominators. PromoteMemToReg doesn't take the base class, because it doesn't make sense for it to work on reverse dominators. -Chris From natebegeman at me.com Fri May 1 12:25:41 2009 From: natebegeman at me.com (mon p wang) Date: Fri, 01 May 2009 10:25:41 -0700 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <200904301759.12384.dag@cray.com> References: <200904301759.12384.dag@cray.com> Message-ID: <8692DD47-EA92-4E34-A2F1-DA7C7CF48985@me.com> On Apr 30, 2009, at 3:59 PM, David Greene wrote: > Here's the big RFC. > > > Of course we would not transition away from X86InstrSSE.td until > X86InstrSIMD.td is proven to cover all current uses of SSE correctly. > > The pros of the scheme: > > * Unify all "important" x86 SIMD instructions into one framework and > provide > consistency While almost all of this sounds pretty great to me, since I'm also in the process of cleaning up how x86 vector shuffles and shifts are implemented, I'm a little worried by what "important" means. Aren't *all* the instructions important? Was the goal to convert 50% of the instructions over to the new class hierarchy and leave 50% as they currently are? > * Specify patterns and asm strings *once* per instruction type / > family > rather than the current scheme of multiple patterns for essentially > the > same instruction Sounds great; you'll probably need some kind of custom lowering to go with this to make sure instructions end up in whatever canonicalized form you've chosen. > * Bugfixes / optimizations / new patterns instantly apply to all SSE > levels > and AVX > > The cons: > > * Transition from X86InstrSSE.td What's the timeline look like for this? Nate From dag at cray.com Fri May 1 12:39:15 2009 From: dag at cray.com (David Greene) Date: Fri, 1 May 2009 12:39:15 -0500 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <8692DD47-EA92-4E34-A2F1-DA7C7CF48985@me.com> References: <200904301759.12384.dag@cray.com> <8692DD47-EA92-4E34-A2F1-DA7C7CF48985@me.com> Message-ID: <200905011239.15965.dag@cray.com> On Friday 01 May 2009 12:25, mon p wang wrote: > > * Unify all "important" x86 SIMD instructions into one framework and > > provide > > consistency > > While almost all of this sounds pretty great to me, since I'm also in > the process of cleaning up how x86 vector shuffles and shifts are > implemented, I'm a little worried by what "important" means. Aren't > *all* the instructions important? Was the goal to convert 50% of the > instructions over to the new class hierarchy and leave 50% as they > currently are? "Important" in this context means all SSE instructions. I'm excluding MMX and 3dNow. I suppose we could add them but I just don't see much point. One could also imagine moving the scalar patterns into this but frankly, the scalar instruction set isn't changing much. The vector instruction set is more likely to be extended which is why I put the focus there. I'm trying to set us up better for the future. > > * Specify patterns and asm strings *once* per instruction type / > > family > > rather than the current scheme of multiple patterns for essentially > > the > > same instruction > > Sounds great; you'll probably need some kind of custom lowering to go > with this to make sure instructions end up in whatever canonicalized > form you've chosen. Maybe. More likely we will need some more pattern fragments. At least that's what I've run into so far. > > * Bugfixes / optimizations / new patterns instantly apply to all SSE > > levels > > and AVX > > > > The cons: > > > > * Transition from X86InstrSSE.td > > What's the timeline look like for this? Good question. What I hope to do is add AVX stuff incrementally. Basic arithmetic works now. But I want to vet this proposal fully before I start adding things to the repository. So the timeline really depends on that process. Once people are comfortable with moving forward, I'll start checking things in as they become available. Moving SSE over is a longer timeline. I would expect that wouldn't be done until 2.7 at the very earliest and probably more like 2.8. -Dave From clattner at apple.com Fri May 1 13:46:10 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 1 May 2009 11:46:10 -0700 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <200904301759.12384.dag@cray.com> References: <200904301759.12384.dag@cray.com> Message-ID: <9F20A521-BB17-4995-86A3-436C7E853613@apple.com> On Apr 30, 2009, at 3:59 PM, David Greene wrote: > Here's the big RFC. > > A I've gone through and designed patterns for AVX, I quickly > realized that the > existing SSE pattern specification, while functional, is less than > ideal in > terms of maintenance. In particular, a number of nearly-identical > patterns > are specified all over for nearly-identical instructions. For > example: Right. A lot of the X86 backend was written before the current set of tblgen features was available. In particular, multiclasses only got retrofitted in later to avoid some of the duplicated code. Where they are used, they aren't used as well as they could be. > Moreover, the various SSE levels were implemented at different times > and do > things subtly differently. For example: > > Note the use of xor vs. vnot and the different placement of the bc* > fragments > and use of type specifiers. I wonder if we even match both of these. Right, we have the same problem within the GPR operations. Ideally we'd have a multiclass for most arithmetic operations that expands out into 8/16/32/64-bit operations, perhaps even handling reg/reg, reg/ imm, and reg/mem versions all at the same time. Similar things should probably be done for SSE1/2 since it adds double versions of all the float operations that SSE1 has. > For AVX we would need a different set of format classes because > while AVX > could reuse the existing XS class (it's recoded as part of the VEX > prefix so > we still need the information XS provides), "Requires<[HasSSE1]>" is > certainly inappropriate. Initially I started factoring things out > to separate > XS and other prefix classes from Requires<> but that didn't solve > the pattern > problems I mentioned above. Right, a lot of these problems can be solved by some nice refactoring stuff. I'm also hoping that some of the complexity in defining shuffle matching code can be helped by making the definition of the shuffle patterns more declarative within the td file. It would be really nice to say that "this shuffle does a "1,0,3,2 shuffle and has cost 42" and have tblgen generate all the required matching code. > All of this complication gets multipled with AVX because AVX recodes > all of > the legacy SSE instructions using VEX to provide three-address > forms. So if > we were to follow the existing sceheme, we would duplicate *all* of > X86InstrSSE.td and edit patterns to match three-address modes and > then add the > 256-bit patterns on top of that, effectively duplicating > X86InstrSSE.td a > second time. > > This is not scalable. I agree, I think it is unfortunate that AVX decided to do this at an architectural level :). > So what I've done is a little experiment to see if I can unify all > SSE and AVX > SIMD instructions under one framework. I'll leave MMX and 3dNow > alone since > they're oddballs and hardly anyone uses them. Ok. I agree that the similarity being factored here is across SSE1/2/ AVX. > Essentially I've created a set of base pattern classes that are very > generic. > These contain the basic asm string templates and dag patterns we > want to > match. These classes are parameterized by things like register class, > operand type, ModRM format and "memory access operation." I've also > created > patterns that take a fully specified asm string and/or dag pattern > to provide > flexibility for "oddball" instructions. Ok. > The point of all of this is to write patterns and asm strings *once* > for each > kind of instruction (binary arithmetic, convert, shuffle, etc.) and > then use > multiclasses to generate all of the concrete patterns for SSE and AVX. Very nice. > So for example, an ADD would be specified like this: > > // Arithmetic ops with intrinsics and scalar equivalents > defm ADD : > sse1_sse2_avx_binary_scalar_xs_xd_vector_tb_ostb_node_intrinsic_rm_rrm > < > 0x58, // Opcode > "add", // asm base opcode name > fadd, // SDNode name > "add", // Intrinsic base name (we pre-concat int_x86_sse*/avx and > // post-contact ps/pd, etc.) > 1 // Commutative >> ; > > Now the multiclass name is rather unwieldy, I know. That can be > changed so > don't worry too much about it. I'm more concerned about the overall > scheme > and that it make sense to you all. This does look very nice. > I have a Perl script that auto-generates the necessary mutliclass > combinations > as well as the needed base classes depending on what's in the top- > level .td > file. For now, I've named that top-level file X86InstrSIMD.td. > > The Perl script would only be need to run as X86InstrSIMD.td > changes. Thus > its use would be similar to how we use autoconf today. We only run > autoconf / > automake when we update the .ac files, not as part of the build > process. While I agree that we want to refactor this, I really don't think that we should autogenerate .td files from perl. This has a number of significant logistical problems. What is it that perl gives you that we can't enhance tblgen to do directly? > Initially, X86InstrSIMD.td would define only AVX instructions so it > would not > impact existing SSE clients. My intent is that X86InstrSIMD.td > essentially > become the canonical description of all SSE and AVX instructions and > X86InstrSSE.td would go away completely. Instead of slowly building it up and then cutting over, I'd prefer to incrementally move patterns into it, removing them from the other .td files at the same time. This should be a nice clean and continuous refactoring that makes the code monotonically better (smaller). > The pros of the scheme: > > * Unify all "important" x86 SIMD instructions into one framework and > provide > consistency Yay! > * Specify patterns and asm strings *once* per instruction type / > family > rather than the current scheme of multiple patterns for essentially > the > same instruction Yay! > * Bugfixes / optimizations / new patterns instantly apply to all SSE > levels > and AVX Yay! > The cons: > * Transition from X86InstrSSE.td > * A more complex class hierarchy I'm not worried about these. > * A class-generating tool / indirection I really don't like this :). If there is something higher level that you need, I think it would be very interesting to carefully consider what the root problem is and whether there is a good solution that we can directly implement in tblgen. It is pretty clear that we can *improve* the current situation with no tblgen enhancements, but I agree that AVX is a nice forcing function that will greatly benefit from a *much improved* target description. -Chris From evan.cheng at apple.com Fri May 1 13:51:51 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 1 May 2009 11:51:51 -0700 Subject: [LLVMdev] [PATH] Fixes for the amd64 JIT code In-Reply-To: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> References: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> Message-ID: <01051155-8E3D-4D6B-BDAE-C6ADA590192B@apple.com> Looks good. Thanks. Evan On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: > Hi, > > The attached patch contains the following changes: > > * X86InstrInfo.cpp: Synchronize a few places with the code in > X86CodeEmitter.cpp > * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it > is not neeed. > > Zoltan > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Fri May 1 13:55:47 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 1 May 2009 11:55:47 -0700 Subject: [LLVMdev] Calling-convention lowering proposal In-Reply-To: <49F9ED8C.6020403@redhat.com> References: <80875B80-C6E0-4362-9D68-95165C06E40E@apple.com> <200904291039.44274.dag@cray.com> <200904301138.24966.dag@cray.com> <49F9ED8C.6020403@redhat.com> Message-ID: <4F8A6A1A-9A65-4C90-B687-F858266A07B7@apple.com> On Apr 30, 2009, at 11:27 AM, Andrew Haley wrote: > Chris Lattner wrote: >> On Apr 30, 2009, at 9:38 AM, David Greene wrote: >>> On Wednesday 29 April 2009 19:22, Chris Lattner wrote: >>>> On Apr 29, 2009, at 8:39 AM, David Greene wrote: >>>>> This patch changes the LLVM API. We should have a process for >>>>> deprecating >>>>> obsolete interfaces before removing them entirely. It's a >>>>> significant >>>>> maintenance headache to pull down a new release and fix all of the >>>>> API >>>>> issues along with tracking down new bugs introduced. >>>> No, we make no attempt at being API compatible across revs of LLVM. >>> That's a huge mistake going forward if we want to grow the >>> community. >> >> Perhaps. However, I greatly prefer to make life easier for people >> who >> contribute code (by preventing them from having to worry about >> deprecation etc) than for those who don't. Reducing the barrier to >> contributing code is a good way (IMO) to encourage contributions and >> new developers. > > Perhaps, but it's a barrier for those who actually want to use > LLVM's JIT. > We'd love to keep up with the latest versions of LLVM, but stuff > just keeps > breaking and sometimes features are just deleted. For example, it > used > to be possible easily to turn on and off asm dumping, but it isn't > any more. That's not true. It's just the option name was changed. The option was added initially to facilitate debugging, but people somehow treats it as a feature. That's fine. That just encourage users to get involved with the community. Evan > > Andrew. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From aph at redhat.com Fri May 1 13:58:21 2009 From: aph at redhat.com (Andrew Haley) Date: Fri, 01 May 2009 19:58:21 +0100 Subject: [LLVMdev] Stack alignment in JIT compiled code In-Reply-To: References: <1241126326.8030.27.camel@gnarf-laptop> <4e5e476b0905010637q72474e89p5b119ab81f33f3b@mail.gmail.com> <49FB06EE.5020008@redhat.com> Message-ID: <49FB464D.8050508@redhat.com> Anton Korobeynikov wrote: >> That's right. If you want to be able to call any code produced by gcc, >> you have to preserve 16-alignment. gcc-generated code does not realign >> the stack pointer. > This was for gcc < 4.4, where stack alignment handling was really > messy. stack-realignment branch was merged afair into gcc 4.4 and > allows automatic realignment of stack, when necessary. I don't think that matters. gcc 4.4.0 has been released for all of ten days. gcc < 4.4 is going to be in use for many years, so you have to be able to cope with it. Andrew. From stefanus.dutoit at rapidmind.com Fri May 1 15:05:57 2009 From: stefanus.dutoit at rapidmind.com (Stefanus Du Toit) Date: Fri, 1 May 2009 16:05:57 -0400 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <200904301759.12384.dag@cray.com> References: <200904301759.12384.dag@cray.com> Message-ID: <9AEB32A5-2C6E-4C0E-93EF-1ED5415699C2@rapidmind.com> Hi David, On 30-Apr-09, at 6:59 PM, David Greene wrote: > This is not scalable. > > So what I've done is a little experiment to see if I can unify all > SSE and AVX > SIMD instructions under one framework. I'll leave MMX and 3dNow > alone since > they're oddballs and hardly anyone uses them. I don't want to unnecessarily expand your scope, but while you're doing this, it might make sense to keep in mind the new Larrabee instructions as well. They operate on 512-bit registers, and there's a (slightly indirect) reference available here: http://software.intel.com/en-us/articles/prototype-primitives-guide/ I'm not suggesting adding these now, just that they might be interesting to keep in mind while you're doing this work. Stefanus -- Stefanus Du Toit RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 From aph at redhat.com Fri May 1 15:15:55 2009 From: aph at redhat.com (Andrew Haley) Date: Fri, 01 May 2009 21:15:55 +0100 Subject: [LLVMdev] Calling-convention lowering proposal In-Reply-To: <4F8A6A1A-9A65-4C90-B687-F858266A07B7@apple.com> References: <80875B80-C6E0-4362-9D68-95165C06E40E@apple.com> <200904291039.44274.dag@cray.com> <200904301138.24966.dag@cray.com> <49F9ED8C.6020403@redhat.com> <4F8A6A1A-9A65-4C90-B687-F858266A07B7@apple.com> Message-ID: <49FB587B.1030100@redhat.com> Evan Cheng wrote: > On Apr 30, 2009, at 11:27 AM, Andrew Haley wrote: > >> Chris Lattner wrote: >>> On Apr 30, 2009, at 9:38 AM, David Greene wrote: >>>> On Wednesday 29 April 2009 19:22, Chris Lattner wrote: >>>>> On Apr 29, 2009, at 8:39 AM, David Greene wrote: >>>>>> This patch changes the LLVM API. We should have a process for >>>>>> deprecating >>>>>> obsolete interfaces before removing them entirely. It's a >>>>>> significant >>>>>> maintenance headache to pull down a new release and fix all of the >>>>>> API >>>>>> issues along with tracking down new bugs introduced. >>>>> No, we make no attempt at being API compatible across revs of LLVM. >>>> That's a huge mistake going forward if we want to grow the >>>> community. >>> Perhaps. However, I greatly prefer to make life easier for people >>> who >>> contribute code (by preventing them from having to worry about >>> deprecation etc) than for those who don't. Reducing the barrier to >>> contributing code is a good way (IMO) to encourage contributions and >>> new developers. >> Perhaps, but it's a barrier for those who actually want to use >> LLVM's JIT. >> We'd love to keep up with the latest versions of LLVM, but stuff just keeps >> breaking and sometimes features are just deleted. For example, it used >> to be possible easily to turn on and off asm dumping, but it isn't >> any more. > > That's not true. It's just the option name was changed. You can turn it on once, but you can never turn it off again. That is, unless there is some way to do it other than by passing command line options to cl::ParseCommandLineOptions. The last time I looked the problem was that DebugOnly was defined as cl::ValueRequired rather than cl::OneOrMore, so the CLI would reject any subsequent setting. If there is some way around this, I'd be delighted to know. Andrew. From basile at starynkevitch.net Fri May 1 15:27:29 2009 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Fri, 01 May 2009 22:27:29 +0200 Subject: [LLVMdev] open source multithreaded garbage collector suitable for LLVM applications? Message-ID: <49FB5B31.2080606@starynkevitch.net> Hello All Does any know about some opensource multithread-compatible (or concurrent) garbage collector library, if possible suitable for LLVM? (I mean that I want several mutator threads; the collector can be stoptheworld or concurrent ....) H.Boehm's conservative GC is multithread compatible, but seems quite slow (allocation is about the time of a C malloc). And it is well known that coding concurrent GC is quite hard, much harder than coding a single-threaded GC. And with LLVM, adapting to the constraints of the GC is easier. Are there people using LLVM in multi-threaded applications with some other GC than Boehm's? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From sricketts at maxentric.com Fri May 1 16:14:51 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Fri, 1 May 2009 14:14:51 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end Message-ID: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> I am attempting to install llvm on CentOS 5.3, which uses gcc-4.1.2 as its system compiler. Since this compiler has reported to behave poorly with llvm, I built gcc-4.2.4 in an insulated directory for use with my llvm installation. However, I am not sure I am configuring properly. The gcc-4.2.4 installation is in /pkg/bin/gcc-4.2.4. Here is my config line: ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ CC=/pkg/bin/gcc-4.2.4/bin/gcc CXX=/pkg/bin/gcc-4.2.4/bin/g++ CXXCPP=/pkg/bin/gcc-4.2.4/bin/cpp LDFLAGS=-L /pkg/bin/gcc-4.2.4/lib64/ CXXFLAGS=-I/pkg/bin/gcc-4.2.4/include/c++/4.2.4/ CPPFLAGS=-I/pkg/bin/gcc-4.2.4/include/ I am trying to specify all the appropriate environment variables for using the non-default gcc. However, it is likely that I have made an error or are ommitting some important variable(s). Then I do "gmake tools-only" (because I have yet to build the llvm-gcc front end). Here is the error: gmake[1]: Entering directory `/pkg/build/llvm/llvm-obj/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td /pkg/build/llvm/llvm-obj/Release/bin/tblgen: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /pkg/build/llvm/llvm-obj/Release/bin/tblgen) gmake[1]: *** [/pkg/build/llvm/llvm-obj/lib/VMCore/Release/Intrinsics.gen.tmp] Error 1 gmake[1]: Leaving directory `/pkg/build/llvm/llvm-obj/lib/VMCore' gmake: *** [all] Error 1 So it is looking in /usr/lib64/ for libstdc++.so.6, when in fact I want it to look in /pkg//bin/gcc-4.2.4/lib64/ (which I thought I had specified with the configuration). Any help would be appreciated. Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/157c6981/attachment.html From dag at cray.com Fri May 1 16:47:12 2009 From: dag at cray.com (David Greene) Date: Fri, 1 May 2009 16:47:12 -0500 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <9F20A521-BB17-4995-86A3-436C7E853613@apple.com> References: <200904301759.12384.dag@cray.com> <9F20A521-BB17-4995-86A3-436C7E853613@apple.com> Message-ID: <200905011647.13167.dag@cray.com> On Friday 01 May 2009 13:46, Chris Lattner wrote: > Right, a lot of these problems can be solved by some nice refactoring > stuff. I'm also hoping that some of the complexity in defining > shuffle matching code can be helped by making the definition of the > shuffle patterns more declarative within the td file. It would be > really nice to say that "this shuffle does a "1,0,3,2 shuffle and has > cost 42" and have tblgen generate all the required matching code. That would be nice. Any ideas how this would work? > I agree, I think it is unfortunate that AVX decided to do this at an > architectural level :). I'm not sure what else would be done. > > So what I've done is a little experiment to see if I can unify all > > SSE and AVX > > SIMD instructions under one framework. I'll leave MMX and 3dNow > > alone since > > they're oddballs and hardly anyone uses them. > > Ok. I agree that the similarity being factored here is across SSE1/2/ > AVX. And SSE3/4. > > I have a Perl script that auto-generates the necessary mutliclass > > combinations > > as well as the needed base classes depending on what's in the top- > > level .td > > file. For now, I've named that top-level file X86InstrSIMD.td. > > > > The Perl script would only be need to run as X86InstrSIMD.td > > changes. Thus > > its use would be similar to how we use autoconf today. We only run > > autoconf / > > automake when we update the .ac files, not as part of the build > > process. > > While I agree that we want to refactor this, I really don't think that > we should autogenerate .td files from perl. This has a number of > significant logistical problems. What is it that perl gives you that > we can't enhance tblgen to do directly? Well, mainly it's because we don't have whatever tblgen enhancements we need. I'll have to think on this some and see if I can come up with some tblgen features that could help. I was writing a lot of these base classes by hand at first, but there are a lot of them (they tend to be very small) and writing them is very mechanical. So we probably can enhance tblgen somehow. I'm just not sure what that looks like right now. > > Initially, X86InstrSIMD.td would define only AVX instructions so it > > would not > > impact existing SSE clients. My intent is that X86InstrSIMD.td > > essentially > > become the canonical description of all SSE and AVX instructions and > > X86InstrSSE.td would go away completely. > > Instead of slowly building it up and then cutting over, I'd prefer to > incrementally move patterns into it, removing them from the other .td > files at the same time. This should be a nice clean and continuous > refactoring that makes the code monotonically better (smaller). Ok, that sounds like a pretty good idea. > > The cons: > > * Transition from X86InstrSSE.td > > * A more complex class hierarchy > > I'm not worried about these. Ok. > > * A class-generating tool / indirection > > I really don't like this :). If there is something higher level that > you need, I think it would be very interesting to carefully consider > what the root problem is and whether there is a good solution that we > can directly implement in tblgen. It is pretty clear that we can > *improve* the current situation with no tblgen enhancements, but I > agree that AVX is a nice forcing function that will greatly benefit > from a *much improved* target description. Your point is well taken. Let me think on this a bit. -Dave From dag at cray.com Fri May 1 16:59:20 2009 From: dag at cray.com (David Greene) Date: Fri, 1 May 2009 16:59:20 -0500 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <9AEB32A5-2C6E-4C0E-93EF-1ED5415699C2@rapidmind.com> References: <200904301759.12384.dag@cray.com> <9AEB32A5-2C6E-4C0E-93EF-1ED5415699C2@rapidmind.com> Message-ID: <200905011659.21445.dag@cray.com> On Friday 01 May 2009 15:05, Stefanus Du Toit wrote: > Hi David, > > On 30-Apr-09, at 6:59 PM, David Greene wrote: > > This is not scalable. > > > > So what I've done is a little experiment to see if I can unify all > > SSE and AVX > > SIMD instructions under one framework. I'll leave MMX and 3dNow > > alone since > > they're oddballs and hardly anyone uses them. > > I don't want to unnecessarily expand your scope, but while you're > doing this, it might make sense to keep in mind the new Larrabee > instructions as well. They operate on 512-bit registers, and there's a > (slightly indirect) reference available here: > > http://software.intel.com/en-us/articles/prototype-primitives-guide/ > > I'm not suggesting adding these now, just that they might be > interesting to keep in mind while you're doing this work. Oh, I'm definitely keeping Larrabee in mind. I've looked at the primitives library and also the Dr. Dobb's article on LRBni: http://www.ddj.com/hpc-high-performance-computing/216402188 I'm designing all of this so it should be relatively easy to plug-in the non-mask/swizzle variants of the Larrabee instructions. Masks and swizzles will require new patterns. I haven't seen a Larrabee ISA manual yet. My hope is that the opcodes and formats for SSE-like instructions will be the same (e.g. a 512-bit ADD will still be 0x58). I think that's a safe assumption. But who knows? Maybe their graphics guys don't talk to their CPU guys. If things are radically different, we won't be able to re-use as much. But it should still be better than what we have now. Also, Larrabee is a great motivator for direct mask/predicate support in LLVM. Anyone want to re-engage in that discussion? -Dave From dag at cray.com Fri May 1 17:01:47 2009 From: dag at cray.com (David Greene) Date: Fri, 1 May 2009 17:01:47 -0500 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <200905011647.13167.dag@cray.com> References: <200904301759.12384.dag@cray.com> <9F20A521-BB17-4995-86A3-436C7E853613@apple.com> <200905011647.13167.dag@cray.com> Message-ID: <200905011701.47316.dag@cray.com> On Friday 01 May 2009 16:47, David Greene wrote: > > Ok. I agree that the similarity being factored here is across SSE1/2/ > > AVX. > > And SSE3/4. What I really meant was SSE3/AVX, SSSE3/AVX and SSE4/AVX. SSS?E3 and SSE4 don't have too much in common with each other. -Dave From clattner at apple.com Fri May 1 17:27:12 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 1 May 2009 15:27:12 -0700 Subject: [LLVMdev] open source multithreaded garbage collector suitable for LLVM applications? In-Reply-To: <49FB5B31.2080606@starynkevitch.net> References: <49FB5B31.2080606@starynkevitch.net> Message-ID: <1D3F23D2-7CC2-40A1-8F15-7CFACD05BBB1@apple.com> On May 1, 2009, at 1:27 PM, Basile STARYNKEVITCH wrote: > Hello All > > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? In fact, yes! http://code.google.com/p/scarcity/ -Chris From clattner at apple.com Fri May 1 17:33:18 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 1 May 2009 15:33:18 -0700 Subject: [LLVMdev] open source multithreaded garbage collector suitable for LLVM applications? In-Reply-To: <1D3F23D2-7CC2-40A1-8F15-7CFACD05BBB1@apple.com> References: <49FB5B31.2080606@starynkevitch.net> <1D3F23D2-7CC2-40A1-8F15-7CFACD05BBB1@apple.com> Message-ID: On May 1, 2009, at 3:27 PM, Chris Lattner wrote: > > On May 1, 2009, at 1:27 PM, Basile STARYNKEVITCH wrote: > >> Hello All >> >> Does any know about some opensource multithread-compatible (or >> concurrent) garbage collector library, if possible suitable for LLVM? > > In fact, yes! > http://code.google.com/p/scarcity/ More information here: http://code.google.com/p/scarcity/wiki/ProjectPlan and an example here: http://code.google.com/p/scarcity/wiki/FreeListHeap -Chris From stefanus.dutoit at rapidmind.com Fri May 1 17:40:54 2009 From: stefanus.dutoit at rapidmind.com (Stefanus Du Toit) Date: Fri, 1 May 2009 18:40:54 -0400 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <000301c9ca48$25fec740$71fc55c0$@net> References: <000301c9ca48$25fec740$71fc55c0$@net> Message-ID: <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> Hi Nicolas, Looks like Preston and I have found the cause of the problem. The issue is with PointerLikeTypeTraits::NumLowBitsAvailable. This is set to 3, which basically assumes that unless the traits are specialized for a particular pointer type, objects of that type are allocated with malloc() and aligned to 8 bytes. While PointerLikeTypeTraits is overloaded for Use*, it is not overloaded for User*. lib/VMCore/Use.cpp uses a PointerIntPair, and things go bad. Users are typically allocated in an array after a bunch of Uses, which are 12 bytes in size, so they may actually only be aligned to 4 bytes. The attached patch (which I don't intend to commit, it's just a workaround) works around this simply by dropping this down to 2 bits, which gets us past our problem on Windows. I would appreciate if you could verify that this works for you as well. To actually solve this properly I see two main options: (1) we could specialize PointerLikeTypeTraits for User*, and leave the default value of NumLowBitsAvailable at 3. (2) we could drop the default NumLowBitsAvailable to 2 (or even use _alignof and similar compiler-specific extensions to determine it), and allow classes that assert that they are only ever allocated through malloc to relax it back up to 3. My preference would be for option (2), due to the difficulty of tracking this bug down, and the risk of future similar bugs happening. However, I'd appreciate some feedback from the LLVM developer community on this. Please let me know what you think, and I'll be happy to prepare a patch. I'm still wondering why this wasn't an issue on other platforms. One possibility is that Use is being bumped up to 16 bytes in size, and thus Users never get placed at less than an 8-byte boundary. However, in that case, the whole point of the "use diet" optimization is lost! I'll investigate and try to find out. I'm also still not sure why the assertion in PointerIntPair::setPointer() did not get triggered by the User::allocHungOffUses() implementation in Use.cpp. Perhaps the assertion is wrong (it looks reasonable, though) or perhaps there is something else going on I haven't seen yet. I'll look into this some more as well. Let me know if the workaround works for you, and I'd appreciate feedback from anyone (Chris? Gabor?) as to how best to proceed. Thanks! Stefanus On 1-May-09, at 6:32 AM, Nicolas Capens wrote: > Hi all, > > I?ve located a regression that causes my project to crash. It?s in > revision 67979, where PointerIntPair is changed from storing the > integer in the upper bits instead of the lower bits. My project is > an experimental JIT-compiler in Windows. > > So I was wondering if anyone had any clue why the new PointerIntPair > implementation might fail. It doesn?t seem very safe to me to store > other data into a pointer to begin with, but surely the lower bits > must be a safer location than the upper bits? > > The actual crash I?m seeing is preceded by an assert in > X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing > backward, I?m seeing a MachineInstr with opcode MOV32rm and > NumOperands equal to 6 (which is 5 in earlier revisions). I?m not > sure if this actually helps explain the bug but it?s one of the > weird things that happen with revision 67979 and subsequent revisions? > > All help appreciated. > > Nicolas > -- Stefanus Du Toit RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/a021811f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: pointer_traits_workaround.diff Type: application/octet-stream Size: 979 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/a021811f/attachment.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/a021811f/attachment-0001.html From clattner at apple.com Fri May 1 17:50:05 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 1 May 2009 15:50:05 -0700 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <200905011647.13167.dag@cray.com> References: <200904301759.12384.dag@cray.com> <9F20A521-BB17-4995-86A3-436C7E853613@apple.com> <200905011647.13167.dag@cray.com> Message-ID: <469F019E-7E04-41BC-BB11-12570A4BED0F@apple.com> On May 1, 2009, at 2:47 PM, David Greene wrote: > On Friday 01 May 2009 13:46, Chris Lattner wrote: >> Right, a lot of these problems can be solved by some nice refactoring >> stuff. I'm also hoping that some of the complexity in defining >> shuffle matching code can be helped by making the definition of the >> shuffle patterns more declarative within the td file. It would be >> really nice to say that "this shuffle does a "1,0,3,2 shuffle and >> has >> cost 42" and have tblgen generate all the required matching code. > > That would be nice. Any ideas how this would work? Nate is currently working on refactoring a bunch of shuffle related logic, which includes changing the X86 backend to canonicalize shuffles more like the ppc/altivec backend does. Once that is done, I think it would make sense for tblgen to generate some C++ code that looks like this: // MatchVectorShuffle - Matches a shuffle node against the available instructions, // returning the lowest cost one as well as the actual cost of it. unsigned MatchVectorShuffle(VectorShuffleSDNode *N) { unsigned LowestCost = ~0; if (N can be matched by movddup) { unsigned movddupcost = ... // can be either constant, or callback into subtarget info if (LowestCost > movddupcost) LowestCost = movddupcost; operands = [whatever] opcode = X86::MOVDDUP; } } if (N can be matched by movhlps) { unsigned movhlpscost = ... if (LowestCost > movhlpscost) LowestCost = movhlpscost; operands = [whatever] opcode = X86::MOVHLPS; } } ... } The advantage of doing this is that it moves the current heuristics for match ordering (which is a poor way to model costs) into a declarative form in the .td file. This is particularly important because different chips have different costs! This generated function could then be called by the actual isel pass itself as well as from DAGCombine. We'd like dagcombine to be able to merge two shuffles into one, but it should only do this when the cost of the resultant shuffle is less than the two original ones (a simple greedy algorithm). This is vague and hand wavy, but hopefully the idea comes across. We have this in the .td files right now: ;; we already have this def MOVDDUPrr : S3DI<0x12, MRMSrcReg, (outs VR128:$dst), (ins VR128:$src), "movddup\t{$src, $dst|$dst, $src}", [(set VR128:$dst,(v2f64 (movddup VR128:$src, (undef))))]>; def movddup : PatFrag<(ops node:$lhs, node:$rhs), (vector_shuffle node:$lhs, node:$rhs), [{ return X86::isMOVDDUPMask(cast(N)); }]>; The goal is to replace the pattern fragment and the C++ code for X86::isMOVDDUPMask with something like: def movddup : PatFrag<(ops node:$lhs, node:$rhs), (vector_shuffle node:$lhs, node:$rhs, 0, 1, 0, 1, Cost<42>) Alternatively, the cost could be put on the instructions etc, whatever makes the most sense. incidentally, I'm not sure why movddup is currently defined to take a LHS/RHS: the RHS should always be undef so it should be coded into the movddup def. Another possible syntax would be to add a special kind of shuffle node to give more natural and clean syntax. This is probably the better solution: def movddup : Shuffle4, Cost<42>; >> While I agree that we want to refactor this, I really don't think >> that >> we should autogenerate .td files from perl. This has a number of >> significant logistical problems. What is it that perl gives you that >> we can't enhance tblgen to do directly? > > Well, mainly it's because we don't have whatever tblgen enhancements > we need. > I'll have to think on this some and see if I can come up with some > tblgen > features that could help. > > I was writing a lot of these base classes by hand at first, but > there are a > lot of them (they tend to be very small) and writing them is very > mechanical. > So we probably can enhance tblgen somehow. I'm just not sure what > that looks > like right now. Ok. > Your point is well taken. Let me think on this a bit. Thanks Dave! I really appreciate you working in this area, -Chris From clattner at apple.com Fri May 1 19:35:45 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 1 May 2009 17:35:45 -0700 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> Message-ID: On May 1, 2009, at 3:40 PM, Stefanus Du Toit wrote: > Hi Nicolas, > > Looks like Preston and I have found the cause of the problem. The > issue is with PointerLikeTypeTraits::NumLowBitsAvailable. This > is set to 3, which basically assumes that unless the traits are > specialized for a particular pointer type, objects of that type are > allocated with malloc() and aligned to 8 bytes. I still don't understand why this is a problem, but I decreased the default to 2 bits. Please verify that this helps, -Chris From gordonhenriksen at me.com Fri May 1 19:39:41 2009 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Fri, 01 May 2009 20:39:41 -0400 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> Message-ID: On 2009-05-01, at 18:40, Stefanus Du Toit wrote: > Hi Nicolas, > > Looks like Preston and I have found the cause of the problem. The > issue is with PointerLikeTypeTraits::NumLowBitsAvailable. This > is set to 3, which basically assumes that unless the traits are > specialized for a particular pointer type, objects of that type are > allocated with malloc() and aligned to 8 bytes. > > While PointerLikeTypeTraits is overloaded for Use*, it is not > overloaded for User*. lib/VMCore/Use.cpp uses a > PointerIntPair, and things go bad. Users are > typically allocated in an array after a bunch of Uses, which are 12 > bytes in size, so they may actually only be aligned to 4 bytes. > > The attached patch (which I don't intend to commit, it's just a > workaround) works around this simply by dropping this down to 2 > bits, which gets us past our problem on Windows. I would appreciate > if you could verify that this works for you as well. > > To actually solve this properly I see two main options: > > (1) we could specialize PointerLikeTypeTraits for User*, and leave > the default value of NumLowBitsAvailable at 3. > (2) we could drop the default NumLowBitsAvailable to 2 (or even use > _alignof and similar compiler-specific extensions to determine it), > and allow classes that assert that they are only ever allocated > through malloc to relax it back up to 3. > Something like this device should suffice; no need for extensions. template class alignment_of { struct test { char a; T b; }; public: enum { value = sizeof(test) - sizeof(T) }; }; // usage: alignment_of::value TR1's type_traits header is now available on many platforms now, too. > My preference would be for option (2), due to the difficulty of > tracking this bug down, and the risk of future similar bugs > happening. However, I'd appreciate some feedback from the LLVM > developer community on this. Please let me know what you think, and > I'll be happy to prepare a patch. > > I'm still wondering why this wasn't an issue on other platforms. One > possibility is that Use is being bumped up to 16 bytes in size, and > thus Users never get placed at less than an 8-byte boundary. > However, in that case, the whole point of the "use diet" > optimization is lost! I'll investigate and try to find out. > > I'm also still not sure why the assertion in > PointerIntPair::setPointer() did not get triggered by the > User::allocHungOffUses() implementation in Use.cpp. Perhaps the > assertion is wrong (it looks reasonable, though) or perhaps there is > something else going on I haven't seen yet. I'll look into this some > more as well. > > Let me know if the workaround works for you, and I'd appreciate > feedback from anyone (Chris? Gabor?) as to how best to proceed. > > Thanks! > > Stefanus > > > > > On 1-May-09, at 6:32 AM, Nicolas Capens wrote: > >> Hi all, >> >> I?ve located a regression that causes my project to crash. It?s in >> revision 67979, where PointerIntPair is changed from storing the >> integer in the upper bits instead of the lower bits. My project is >> an experimental JIT-compiler in Windows. >> >> So I was wondering if anyone had any clue why the new >> PointerIntPair implementation might fail. It doesn?t seem very safe >> to me to store other data into a pointer to begin with, but surely >> the lower bits must be a safer location than the upper bits? >> >> The actual crash I?m seeing is preceded by an assert in >> X86InstrInfo::sizeOfImm: "Immediate size not set!". Tracing >> backward, I?m seeing a MachineInstr with opcode MOV32rm and >> NumOperands equal to 6 (which is 5 in earlier revisions). I?m not >> sure if this actually helps explain the bug but it?s one of the >> weird things that happen with revision 67979 and subsequent >> revisions? >> >> All help appreciated. >> >> Nicolas >> > > -- > Stefanus Du Toit > RapidMind Inc. > phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/c0b03dee/attachment-0001.html From clattner at apple.com Fri May 1 19:45:05 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 1 May 2009 17:45:05 -0700 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> Message-ID: <4E36F1E1-BD0F-4525-9F41-A7B13DA9B90A@apple.com> On May 1, 2009, at 5:39 PM, Gordon Henriksen wrote: >> (1) we could specialize PointerLikeTypeTraits for User*, and leave >> the default value of NumLowBitsAvailable at 3. >> (2) we could drop the default NumLowBitsAvailable to 2 (or even use >> _alignof and similar compiler-specific extensions to determine it), >> and allow classes that assert that they are only ever allocated >> through malloc to relax it back up to 3. >> > > Something like this device should suffice; no need for extensions. That's already in llvm/Support/AlignOf.h. -Chris From sricketts at maxentric.com Fri May 1 20:20:07 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Fri, 1 May 2009 18:20:07 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> Message-ID: <6d9073030905011820r41710abex31af8167bac20c2c@mail.gmail.com> Ah, nevermind... just needed to make clean to clear out some of the junk I compiled with gcc-4.1.2. The build completed without error. On Fri, May 1, 2009 at 2:14 PM, Scott Ricketts wrote: > I am attempting to install llvm on CentOS 5.3, which uses gcc-4.1.2 as its > system compiler. Since this compiler has reported to behave poorly with > llvm, I built gcc-4.2.4 in an insulated directory for use with my llvm > installation. > > However, I am not sure I am configuring properly. The gcc-4.2.4 > installation is in /pkg/bin/gcc-4.2.4. Here is my config line: > > ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ CC=/pkg/bin/gcc-4.2.4/bin/gcc > CXX=/pkg/bin/gcc-4.2.4/bin/g++ CXXCPP=/pkg/bin/gcc-4.2.4/bin/cpp LDFLAGS=-L > /pkg/bin/gcc-4.2.4/lib64/ CXXFLAGS=-I/pkg/bin/gcc-4.2.4/include/c++/4.2.4/ > CPPFLAGS=-I/pkg/bin/gcc-4.2.4/include/ > > I am trying to specify all the appropriate environment variables for using > the non-default gcc. However, it is likely that I have made an error or are > ommitting some important variable(s). > > Then I do "gmake tools-only" (because I have yet to build the llvm-gcc > front end). Here is the error: > > gmake[1]: Entering directory `/pkg/build/llvm/llvm-obj/lib/VMCore' > llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td > /pkg/build/llvm/llvm-obj/Release/bin/tblgen: /usr/lib64/libstdc++.so.6: > version `GLIBCXX_3.4.9' not found (required by > /pkg/build/llvm/llvm-obj/Release/bin/tblgen) > gmake[1]: *** > [/pkg/build/llvm/llvm-obj/lib/VMCore/Release/Intrinsics.gen.tmp] Error 1 > gmake[1]: Leaving directory `/pkg/build/llvm/llvm-obj/lib/VMCore' > gmake: *** [all] Error 1 > > > So it is looking in /usr/lib64/ for libstdc++.so.6, when in fact I want it > to look in /pkg//bin/gcc-4.2.4/lib64/ (which I thought I had specified with > the configuration). > > Any help would be appreciated. > > Thanks, > Scott > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090501/181ad5eb/attachment.html From viridia at gmail.com Sat May 2 03:05:35 2009 From: viridia at gmail.com (Talin) Date: Sat, 02 May 2009 01:05:35 -0700 Subject: [LLVMdev] open source multithreaded garbage collector suitable for LLVM applications? In-Reply-To: <1D3F23D2-7CC2-40A1-8F15-7CFACD05BBB1@apple.com> References: <49FB5B31.2080606@starynkevitch.net> <1D3F23D2-7CC2-40A1-8F15-7CFACD05BBB1@apple.com> Message-ID: <49FBFECF.2060008@gmail.com> Chris Lattner wrote: > On May 1, 2009, at 1:27 PM, Basile STARYNKEVITCH wrote: >> Hello All >> >> Does any know about some opensource multithread-compatible (or >> concurrent) garbage collector library, if possible suitable for LLVM? > In fact, yes! > http://code.google.com/p/scarcity/ Note that this is still a work in progress, and not quite ready for use in real programs. But yes, the goal is to create a concurrent garbage collector (or actually, several different collectors) for LLVM projects. The project philosophy is based around the "building blocks" idea that was discussed earlier in this list. By Using C++ policy-based design, Scarcity intends to provide essential components for building garbage collectors. The policy-based approach allows any aspect of the system to easily be replaced - so for example you can replace all of the threading primitives with ones that are specific to your runtime environment. Policies also allow the collector to be adapted to different object memory layouts without requiring the overhead of virtual method calls. The ConcurrentCollector class supports both "stop the world" and "sliding window" collection algorithms via subclassing - it provides a framework for synchronization between mutator threads and the collector, and it's up to the subclass to determine exactly what happens at each sync point. This means that there is room for a lot of different multithreaded collector algorithms to be implemented within this framework. Anyway, there is lots to be done still. I have not even begun to work on the integration with LLVM proper. -- Talin From aph at redhat.com Sat May 2 03:33:30 2009 From: aph at redhat.com (Andrew Haley) Date: Sat, 02 May 2009 09:33:30 +0100 Subject: [LLVMdev] open source multithreaded garbage collector suitable for LLVM applications? In-Reply-To: <49FB5B31.2080606@starynkevitch.net> References: <49FB5B31.2080606@starynkevitch.net> Message-ID: <49FC055A.60609@redhat.com> Basile STARYNKEVITCH wrote: > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? > > (I mean that I want several mutator threads; the collector can be > stoptheworld or concurrent ....) > > H.Boehm's conservative GC is multithread compatible, but seems quite > slow (allocation is about the time of a C malloc). It's true that the allocation path in the Boehm GC isn't as fast as some, but overall I don't think that the collector itself performs badly. It's been carefully tuned over many years on a wide range of systems, and I think it's extremely unlikely that a much simpler approach will in generally result in better performance. It's ferociously hard to benchmark things like this, because it all depends critically on the allocation pattern of your application. A tuned precise copying collector such as those used in the HotSpot VM might do better than a more general-purpose tool, as you'd expect, but it will need accurate type information to do so. Andrew. From basile at starynkevitch.net Sat May 2 05:48:36 2009 From: basile at starynkevitch.net (Basile STARYNKEVITCH) Date: Sat, 02 May 2009 12:48:36 +0200 Subject: [LLVMdev] open source multithreaded garbage collector suitable for LLVM applications? In-Reply-To: <49FC055A.60609@redhat.com> References: <49FB5B31.2080606@starynkevitch.net> <49FC055A.60609@redhat.com> Message-ID: <49FC2504.7050100@starynkevitch.net> Andrew Haley wrote: > Basile STARYNKEVITCH wrote: > > >> Does any know about some opensource multithread-compatible (or >> concurrent) garbage collector library, if possible suitable for LLVM? >> >> (I mean that I want several mutator threads; the collector can be >> stoptheworld or concurrent ....) >> >> H.Boehm's conservative GC is multithread compatible, but seems quite >> slow (allocation is about the time of a C malloc). >> > > It's true that the allocation path in the Boehm GC isn't as fast as > some, but overall I don't think that the collector itself performs > badly. It's been carefully tuned over many years on a wide range > of systems, and I think it's extremely unlikely that a much simpler > approach will in generally result in better performance. > > It's ferociously hard to benchmark things like this, because it all > depends critically on the allocation pattern of your application. > A tuned precise copying collector such as those used in the HotSpot > VM might do better than a more general-purpose tool, as you'd expect, > but it will need accurate type information to do so. I agree, but any LLVM user, since he is generating code, is able to provide the accurate type info you are mentionning. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** From nicolas at capens.net Sat May 2 09:24:58 2009 From: nicolas at capens.net (Nicolas Capens) Date: Sat, 2 May 2009 16:24:58 +0200 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> Message-ID: <000601c9cb31$c5c0c230$51424690$@net> Hi Stefanus, I had actually tried that already, but my project kept crashing. However, after giving it a second try I noticed that the crash was happening elsewhere this time. After disabling the GVN optimization pass everything worked fine. Somewhere between revision 67979 and 67996 the bug that was causing GVN to fail was fixed. So thanks for tracking this down! I agree that option (2) is a good solution for now. But in my humble opinion the whole idea of storing other information in pointers is not very robust. One alternative would be to have a global store of all Value objects. They can then be identified with just an index instead of a pointer. This index can be stored in a bitfield that is smaller than 32-bit, leaving bits available for additional data. Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit Sent: zaterdag 2 mei 2009 0:41 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] PointerIntPair causing trouble Hi Nicolas, Looks like Preston and I have found the cause of the problem. The issue is with PointerLikeTypeTraits::NumLowBitsAvailable. This is set to 3, which basically assumes that unless the traits are specialized for a particular pointer type, objects of that type are allocated with malloc() and aligned to 8 bytes. While PointerLikeTypeTraits is overloaded for Use*, it is not overloaded for User*. lib/VMCore/Use.cpp uses a PointerIntPair, and things go bad. Users are typically allocated in an array after a bunch of Uses, which are 12 bytes in size, so they may actually only be aligned to 4 bytes. The attached patch (which I don't intend to commit, it's just a workaround) works around this simply by dropping this down to 2 bits, which gets us past our problem on Windows. I would appreciate if you could verify that this works for you as well. To actually solve this properly I see two main options: (1) we could specialize PointerLikeTypeTraits for User*, and leave the default value of NumLowBitsAvailable at 3. (2) we could drop the default NumLowBitsAvailable to 2 (or even use _alignof and similar compiler-specific extensions to determine it), and allow classes that assert that they are only ever allocated through malloc to relax it back up to 3. My preference would be for option (2), due to the difficulty of tracking this bug down, and the risk of future similar bugs happening. However, I'd appreciate some feedback from the LLVM developer community on this. Please let me know what you think, and I'll be happy to prepare a patch. I'm still wondering why this wasn't an issue on other platforms. One possibility is that Use is being bumped up to 16 bytes in size, and thus Users never get placed at less than an 8-byte boundary. However, in that case, the whole point of the "use diet" optimization is lost! I'll investigate and try to find out. I'm also still not sure why the assertion in PointerIntPair::setPointer() did not get triggered by the User::allocHungOffUses() implementation in Use.cpp. Perhaps the assertion is wrong (it looks reasonable, though) or perhaps there is something else going on I haven't seen yet. I'll look into this some more as well. Let me know if the workaround works for you, and I'd appreciate feedback from anyone (Chris? Gabor?) as to how best to proceed. Thanks! Stefanus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090502/5ae048ed/attachment.html From thomas.gatzweiler at googlemail.com Sat May 2 13:47:30 2009 From: thomas.gatzweiler at googlemail.com (Thomas Gatzweiler) Date: Sat, 2 May 2009 20:47:30 +0200 Subject: [LLVMdev] Dynamic typing Message-ID: Hello, I've spent many time trying to find a solution but I have no idea how to create a dynamically typed scripting language like Python and Ruby with LLVM. Is there any way to realize this? Best Regards, Thomas Gatzweiler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090502/21d308f0/attachment.html From cmh at me.com Sat May 2 13:51:14 2009 From: cmh at me.com (Chris Hanson) Date: Sat, 02 May 2009 11:51:14 -0700 Subject: [LLVMdev] open source multithreaded garbage collector suitable for LLVM applications? In-Reply-To: <49FB5B31.2080606@starynkevitch.net> References: <49FB5B31.2080606@starynkevitch.net> Message-ID: Apple's autozone is a concurrent non-copying collector written in C++ that should be adaptable to your needs. You could even take a look at clang to see how to generate code for it; autozone is the collector used by Objective-C garbage collection. It's under an Apache license and downloadable from the Darwin open source repository. Google should point you to it. -- Chris -- sent from my iPhone On May 1, 2009, at 1:27 PM, Basile STARYNKEVITCH wrote: > Hello All > > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? > > (I mean that I want several mutator threads; the collector can be > stoptheworld or concurrent ....) > > H.Boehm's conservative GC is multithread compatible, but seems quite > slow (allocation is about the time of a C malloc). > > And it is well known that coding concurrent GC is quite hard, much > harder than coding a single-threaded GC. > > And with LLVM, adapting to the constraints of the GC is easier. > > Are there people using LLVM in multi-threaded applications with some > other GC than Boehm's? > > Regards. > > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basilestarynkevitchnet mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mines, sont seulement les miennes} *** > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From aaronngray.lists at googlemail.com Sat May 2 14:12:38 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Sat, 2 May 2009 20:12:38 +0100 Subject: [LLVMdev] Dynamic typing References: Message-ID: Just as you would with any other CPU or C language primatives. ----- Original Message ----- From: Thomas Gatzweiler To: llvmdev at cs.uiuc.edu Sent: Saturday, May 02, 2009 7:47 PM Subject: [LLVMdev] Dynamic typing Hello, I've spent many time trying to find a solution but I have no idea how to create a dynamically typed scripting language like Python and Ruby with LLVM. Is there any way to realize this? Best Regards, Thomas Gatzweiler ------------------------------------------------------------------------------ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090502/e26c5cb3/attachment.html From me22.ca at gmail.com Sat May 2 14:14:33 2009 From: me22.ca at gmail.com (me22) Date: Sat, 2 May 2009 15:14:33 -0400 Subject: [LLVMdev] Dynamic typing In-Reply-To: References: Message-ID: On Sat, May 2, 2009 at 14:47, Thomas Gatzweiler wrote: > > I've spent many time trying to find a solution but I have no idea how to > create a dynamically typed scripting language like Python and Ruby with > LLVM. > Is there any way to realize this? > Well "dynamically typed" really just means "trivially statically typed", where everything has type variant, so presumably you'd have functions that do the double dispatch and do the right thing. Then you would likely write some analysis that would tell you what types are possible from the various expressions, and then optimize the dispatch accordingly. (I suppose if you were lucky, constant propagation, folding, inlining, and DCE would do much of that for you.) ~ Scott From jon at ffconsultancy.com Sat May 2 19:12:55 2009 From: jon at ffconsultancy.com (Jon Harrop) Date: Sun, 3 May 2009 01:12:55 +0100 Subject: [LLVMdev] Dynamic typing In-Reply-To: References: Message-ID: <200905030112.55373.jon@ffconsultancy.com> On Saturday 02 May 2009 19:47:30 Thomas Gatzweiler wrote: > Hello, > > I've spent many time trying to find a solution but I have no idea how to > create a dynamically typed scripting language like Python and Ruby with > LLVM. > Is there any way to realize this? Sure. Just box all values and put run-time type tests everywhere when they are unboxed. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e From npjohnso at cs.princeton.edu Sun May 3 09:18:23 2009 From: npjohnso at cs.princeton.edu (Nick Johnson) Date: Sun, 3 May 2009 10:18:23 -0400 Subject: [LLVMdev] L1, L2 Cache line sizes in TargetData? Message-ID: Hello, Is there any way for a pass to determine the L1 or L2 cacheline size of the target before the IR is lowered to machine instructions? Thanks, -- Nick Johnson From gohman at apple.com Sun May 3 10:16:14 2009 From: gohman at apple.com (Dan Gohman) Date: Sun, 3 May 2009 08:16:14 -0700 Subject: [LLVMdev] L1, L2 Cache line sizes in TargetData? In-Reply-To: References: Message-ID: On May 3, 2009, at 7:18 AM, Nick Johnson wrote: > Hello, > > Is there any way for a pass to determine the L1 or L2 cacheline size > of the target before the IR is lowered to machine instructions? LLVM doesn't currently have any target-specific memory hierarchy information, so the way to do it would be to design an interface for this information, perhaps named something like TargetMemoryInfo, and initially populate it with things that you need. Dan From ndug at cs.man.ac.uk Sun May 3 09:25:52 2009 From: ndug at cs.man.ac.uk (Geoffrey Tochukwu Ndu) Date: 03 May 2009 15:25:52 +0100 Subject: [LLVMdev] lli on ARM simulator Message-ID: Hello, I am new to LLVM and complier development, am more comfortable with logic gates. However, I am part of a research project that intends to develop a co-designed virtual machine reconfigurable computing, the virtual machine controls a reconfigurable fabric in addition to a microprocessor. The microprocessor may be an ARM and the system should employ a JIT to generate code for the processor and the fabric. We are thinking of leveraging the LLVM infrastructure for this project. It has most of the stuff we need, a front-end, an extensible low level IR and a JIT. I am currently looking at LLVM's JIT and would like to build an lli tool for an ARM simulator such as simple scalar. I would be grateful if someone could point me in the right direction. geoffrey From aaronngray.lists at googlemail.com Sun May 3 11:38:29 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Sun, 3 May 2009 17:38:29 +0100 Subject: [LLVMdev] Dynamic typing References: Message-ID: <63AF88D00CBE40C684E571A7DF603651@HPLAPTOP> You may want to do a double JIT, JIT'ing your dynamic code to LLVM code then JIT'ing that. Aaron ----- Original Message ----- From: Thomas Gatzweiler To: llvmdev at cs.uiuc.edu Sent: Saturday, May 02, 2009 7:47 PM Subject: [LLVMdev] Dynamic typing Hello, I've spent many time trying to find a solution but I have no idea how to create a dynamically typed scripting language like Python and Ruby with LLVM. Is there any way to realize this? Best Regards, Thomas Gatzweiler ------------------------------------------------------------------------------ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090503/a2e494c0/attachment.html From stefanus.dutoit at rapidmind.com Sun May 3 11:56:47 2009 From: stefanus.dutoit at rapidmind.com (Stefanus Du Toit) Date: Sun, 3 May 2009 12:56:47 -0400 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> Message-ID: <91874256-2A2F-4ADC-BCD4-8E24889B4926@rapidmind.com> On 1-May-09, at 8:35 PM, Chris Lattner wrote: > I still don't understand why this is a problem, but I decreased the > default to 2 bits. Please verify that this helps, I think I've figured out what's going on, and why no assertions are caused by this. It doesn't necessarily have anything to do with User* pointer alignment per se (although I believe that could still cause trouble, though I would expect asserts to catch things in that case). Here's what I think is happening: Use::getUser() casts the last element of the Use array to an AugmentedUse, then pulls out the tagged pointer that AugmentedUse adds. However, in the case where the User is actually located at the end of the Use array, there's no tagged pointer there, just some "random" data corresponding to the first sizeof(User*) bits of a User instance. The code seems to assume that the relevant bit from the tagged pointer in AugmentedUse is going to be zero in that case -- if that bit is one, it considers the AugmentedUse reference valid and pulls out the pointer. Since Value (and therefore User) is polymorphic, there's (probably?) going to be a vtable pointer at the beginning of User. So this code seems to be assuming that the relevant bit of that vtable pointer is going to be zero. I'm guessing that virtual tables from MSVC happen to be less strictly aligned than those from GCC/Linux/OS X. Now I'm wondering what to do about this. If we know that the first sizeof(User*) bits of User are indeed always a virtual table pointer, and that the vtables are aligned to at least 4 bytes, then the current solution (setting the alignment of User* to 4 bytes) will continue work. There's the question of whether we really want to rely on this though. If we don't want to rely on this, we need to distinguish between indirectly referred Users and at-end-of-Use-array Users differently somehow. Of course we could just always store a User* and set it to null if the User is at the end of the array, but that would increase the size of most Users by sizeof(User*). Maybe we could encode this information somehow into the tag bits of the Uses, but I can't see an easy way to do this. I'd appreciate your thoughts. In the meantime I will probably commit some additional comments for Use.cpp to make the code a bit easier to understand, as well as putting an assert in place to catch this earlier. Stefanus -- Stefanus Du Toit RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 From evan.cheng at apple.com Sun May 3 14:44:47 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 3 May 2009 12:44:47 -0700 Subject: [LLVMdev] Calling-convention lowering proposal In-Reply-To: <49FB587B.1030100@redhat.com> References: <80875B80-C6E0-4362-9D68-95165C06E40E@apple.com> <200904291039.44274.dag@cray.com> <200904301138.24966.dag@cray.com> <49F9ED8C.6020403@redhat.com> <4F8A6A1A-9A65-4C90-B687-F858266A07B7@apple.com> <49FB587B.1030100@redhat.com> Message-ID: On May 1, 2009, at 1:15 PM, Andrew Haley wrote: > Evan Cheng wrote: >> On Apr 30, 2009, at 11:27 AM, Andrew Haley wrote: >> >>> Chris Lattner wrote: >>>> On Apr 30, 2009, at 9:38 AM, David Greene wrote: >>>>> On Wednesday 29 April 2009 19:22, Chris Lattner wrote: >>>>>> On Apr 29, 2009, at 8:39 AM, David Greene wrote: >>>>>>> This patch changes the LLVM API. We should have a process for >>>>>>> deprecating >>>>>>> obsolete interfaces before removing them entirely. It's a >>>>>>> significant >>>>>>> maintenance headache to pull down a new release and fix all of >>>>>>> the >>>>>>> API >>>>>>> issues along with tracking down new bugs introduced. >>>>>> No, we make no attempt at being API compatible across revs of >>>>>> LLVM. >>>>> That's a huge mistake going forward if we want to grow the >>>>> community. >>>> Perhaps. However, I greatly prefer to make life easier for people >>>> who >>>> contribute code (by preventing them from having to worry about >>>> deprecation etc) than for those who don't. Reducing the barrier to >>>> contributing code is a good way (IMO) to encourage contributions >>>> and >>>> new developers. > >>> Perhaps, but it's a barrier for those who actually want to use >>> LLVM's JIT. > >>> We'd love to keep up with the latest versions of LLVM, but stuff >>> just keeps >>> breaking and sometimes features are just deleted. For example, it >>> used >>> to be possible easily to turn on and off asm dumping, but it isn't >>> any more. >> >> That's not true. It's just the option name was changed. > > You can turn it on once, but you can never turn it off again. That's not different from before. > That is, unless there is some way to do it other than by passing > command line options to cl::ParseCommandLineOptions. The last > time I looked the problem was that DebugOnly was defined as > cl::ValueRequired rather than cl::OneOrMore, so the CLI would > reject any subsequent setting. > > If there is some way around this, I'd be delighted to know. This will require modifying code. Patches welcome. Evan > > Andrew. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ggreif at gmail.com Sun May 3 15:57:15 2009 From: ggreif at gmail.com (Gabor Greif) Date: Sun, 3 May 2009 13:57:15 -0700 (PDT) Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <91874256-2A2F-4ADC-BCD4-8E24889B4926@rapidmind.com> References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> <91874256-2A2F-4ADC-BCD4-8E24889B4926@rapidmind.com> Message-ID: <2f4f3caa-ef17-42e6-b219-4947f37f3eea@v17g2000vbb.googlegroups.com> On 3 Mai, 18:56, Stefanus Du Toit wrote: > On 1-May-09, at 8:35 PM, Chris Lattner wrote: > > > I still don't understand why this is a problem, but I decreased the > > default to 2 bits. ?Please verify that this helps, > > I think I've figured out what's going on, and why no assertions are ? > caused by this. It doesn't necessarily have anything to do with User* ? > pointer alignment per se (although I believe that could still cause ? > trouble, though I would expect asserts to catch things in that case). > > Here's what I think is happening: > > Use::getUser() casts the last element of the Use array to an ? > AugmentedUse, then pulls out the tagged pointer that AugmentedUse adds. > > However, in the case where the User is actually located at the end of ? > the Use array, there's no tagged pointer there, just some "random" ? > data corresponding to the first sizeof(User*) bits of a User instance. Hi Stefanus! Your analysis is perfectly correct. I Was AFK for the last two days, so I couldn't tell you this same story. The algorithm relies on the fact that the LSBit of the first "pointer" in User is zero. This is normally the case with VPtrs, which are "normally" placed there by ABIs. Originally, I just checked that bit verbatim, and later by means of PointerIntPair. The problem arose when PointerIntPair's layout changed. I think we could switch back without a loss. Btw. the alignment of pointers in a 32 bit machine is 4, so I do not understand how the traits define 3 free bits for them. Maybe sabre can explain that change which caused the breakage. Is there any acute breakage left? I assume that there will be problems with layouts on compilers with non-standard ABIs that place the Vptr in a different location, or use other means of dispatch. I am happy to work on this if you now a serious platform that breaks my assumption. Cheers, Gabor > > The code seems to assume that the relevant bit from the tagged pointer ? > in AugmentedUse is going to be zero in that case -- if that bit is ? > one, it considers the AugmentedUse reference valid and pulls out the ? > pointer. > > Since Value (and therefore User) is polymorphic, there's (probably?) ? > going to be a vtable pointer at the beginning of User. So this code ? > seems to be assuming that the relevant bit of that vtable pointer is ? > going to be zero. I'm guessing that virtual tables from MSVC happen to ? > be less strictly aligned than those from GCC/Linux/OS X. > > Now I'm wondering what to do about this. If we know that the first ? > sizeof(User*) bits of User are indeed always a virtual table pointer, ? > and that the vtables are aligned to at least 4 bytes, then the current ? > solution (setting the alignment of User* to 4 bytes) will continue ? > work. There's the question of whether we really want to rely on this ? > though. > > If we don't want to rely on this, we need to distinguish between ? > indirectly referred Users and at-end-of-Use-array Users differently ? > somehow. Of course we could just always store a User* and set it to ? > null if the User is at the end of the array, but that would increase ? > the size of most Users by sizeof(User*). Maybe we could encode this ? > information somehow into the tag bits of the Uses, but I can't see an ? > easy way to do this. > > I'd appreciate your thoughts. In the meantime I will probably commit ? > some additional comments for Use.cpp to make the code a bit easier to ? > understand, as well as putting an assert in place to catch this earlier. > > Stefanus > > -- > Stefanus Du Toit > ? ?RapidMind Inc. > ? ?phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 > > _______________________________________________ > LLVM Developers mailing list > LLVM... at cs.uiuc.edu ? ? ? ?http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From aaronngray.lists at googlemail.com Sun May 3 17:41:32 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Sun, 3 May 2009 23:41:32 +0100 Subject: [LLVMdev] Origin of DEBUG and EH label values Message-ID: <16A62A187FD14180AD1A537F21E5311A@HPLAPTOP> Where do DEBUG and EH label values originate from ? Where's their allocator ? I am looking at some code in X86CodeEmitter.cpp line 574, where a labels value is extraced from an operand. But dont know where to look in the frontend or middle end to find the LabelID allocator. If some kind person could point me in the right direction. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090503/878e948d/attachment.html From bios.bob.frankel at gmail.com Sun May 3 20:19:53 2009 From: bios.bob.frankel at gmail.com (Bob Frankel) Date: Sun, 03 May 2009 18:19:53 -0700 Subject: [LLVMdev] leveraging back-end C compiler features in the gcc-based front-end Message-ID: <49FE42B9.3070105@gmail.com> An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090503/8b014684/attachment.html From eli.friedman at gmail.com Sun May 3 20:40:54 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Sun, 3 May 2009 18:40:54 -0700 Subject: [LLVMdev] leveraging back-end C compiler features in the gcc-based front-end In-Reply-To: <49FE42B9.3070105@gmail.com> References: <49FE42B9.3070105@gmail.com> Message-ID: On Sun, May 3, 2009 at 6:19 PM, Bob Frankel wrote: > i'm looking into using llvm with TI's MSP430 Ah, you're in luck then: an MSP430 backend was checked in to SVN today :) I don't think it's mature enough for general use yet, though. > is there a way to leverage these (non-gcc) intrinsics in the llvm gcc-based > frontend -- perhaps flagging their use in such a way that they effectively > "pass through" the optimizer and are emitted "as is" in the generated C > code??? in some respects, you can think of this usage as not unlike dropping > inline asm code into the C sources. You could try just generating calls to the builtins in question; if you're lucky, it'll just work... if not, you can always use sed (or equivalent) to manipulate the C output into the correct form. -Eli From bios.bob.frankel at gmail.com Sun May 3 21:12:02 2009 From: bios.bob.frankel at gmail.com (Bob Frankel) Date: Sun, 03 May 2009 19:12:02 -0700 Subject: [LLVMdev] leveraging back-end C compiler features in the gcc-based front-end In-Reply-To: References: <49FE42B9.3070105@gmail.com> Message-ID: <49FE4EF2.4000501@gmail.com> An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090503/8243ccab/attachment.html From clattner at apple.com Sun May 3 21:29:01 2009 From: clattner at apple.com (Chris Lattner) Date: Sun, 3 May 2009 19:29:01 -0700 Subject: [LLVMdev] Strange loop unrolling problem (partially solved) In-Reply-To: <49F5A45A.9010000@tut.fi> References: <49EEE7FC.6070000@tut.fi> <49F5A45A.9010000@tut.fi> Message-ID: <74C45630-2B1C-4FB3-8217-B1F9E01B2D58@apple.com> On Apr 27, 2009, at 5:26 AM, Pertti Kellom?ki wrote: > A short while ago I wrote about the strange loop unrolling > behavior we encountered. The problem was that with -O3, > the following loop does not get unrolled if the ifdef'ed > dead code is not present. Hi Pertti, This is a major problem of the jump threading pass. I've fixed it in r70820, thanks for bringing this up! -Chris From eli.friedman at gmail.com Sun May 3 22:19:50 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Sun, 3 May 2009 20:19:50 -0700 Subject: [LLVMdev] leveraging back-end C compiler features in the gcc-based front-end In-Reply-To: <49FE4EF2.4000501@gmail.com> References: <49FE42B9.3070105@gmail.com> <49FE4EF2.4000501@gmail.com> Message-ID: On Sun, May 3, 2009 at 7:12 PM, Bob Frankel wrote: > wow!!!? i would be interested in trying this....? any helpful instructions > (for a novice like me) to get started using the msp430 backend would be > helpful.... If you've built clang (http://clang.llvm.org/), you can use a command like "clang -ccc-host-triple msp430-generic-generic -ccc-clang-archs msp430 -x c - -o - -S -O" and type in some C code, and it'll spit out msp430 assembly. (The -ccc-host-triple and -cc-clang-archs arguments are magic; besides that, clang takes the same arguments as gcc.) -Eli From vargaz at gmail.com Sun May 3 22:29:16 2009 From: vargaz at gmail.com (vargaz) Date: Sun, 3 May 2009 20:29:16 -0700 (PDT) Subject: [LLVMdev] [PATH] Fixes for the amd64 JIT code In-Reply-To: <01051155-8E3D-4D6B-BDAE-C6ADA590192B@apple.com> References: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> <01051155-8E3D-4D6B-BDAE-C6ADA590192B@apple.com> Message-ID: <23362528.post@talk.nabble.com> Hi, If this looks ok, could somebody check it in ? thanks Zoltan Evan Cheng-2 wrote: > > Looks good. Thanks. > > Evan > > On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: > >> Hi, >> >> The attached patch contains the following changes: >> >> * X86InstrInfo.cpp: Synchronize a few places with the code in >> X86CodeEmitter.cpp >> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it >> is not neeed. >> >> Zoltan >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- View this message in context: http://www.nabble.com/-PATH--Fixes-for-the-amd64-JIT-code-tp23335910p23362528.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From anton at korobeynikov.info Mon May 4 03:22:40 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 4 May 2009 12:22:40 +0400 Subject: [LLVMdev] leveraging back-end C compiler features in the gcc-based front-end In-Reply-To: <49FE42B9.3070105@gmail.com> References: <49FE42B9.3070105@gmail.com> Message-ID: Hello, Bob > supports a number of (processor-specific) intrinsics that expose much of the > underlying CPU architecture directly to the C programmer -- registers, > pseudo-functions for enabling/disabling interrupts and reading/writing > status bits, etc. Nothing special here. All this can be implemented either via inline assembler and/or via register-tied variables. I have no idea whether mspgcc supports this, but this certainly possible. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From anton at korobeynikov.info Mon May 4 03:24:14 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 4 May 2009 12:24:14 +0400 Subject: [LLVMdev] leveraging back-end C compiler features in the gcc-based front-end In-Reply-To: <49FE4EF2.4000501@gmail.com> References: <49FE42B9.3070105@gmail.com> <49FE4EF2.4000501@gmail.com> Message-ID: Hello, Bob > wow!!!? i would be interested in trying this....? any helpful instructions > (for a novice like me) to get started using the msp430 backend would be > helpful.... It depends what you want to do with it. It's definitely not mature enough, so... "patches are welcome" :) Please read readme.txt in the backend dir for some information & possible tasks if you're interested in it. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From anton at korobeynikov.info Mon May 4 05:22:01 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 04 May 2009 14:22:01 +0400 Subject: [LLVMdev] mingw build problems In-Reply-To: References: <058BA381-D53A-4C04-9159-A771CB5C7417@korobeynikov.info> Message-ID: <1241432521.18321.27.camel@aslstation> Hi, Jay > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525016 > > I've been using an ugly makefile hack (attached) to work around this > bug when cross-compiling for MinGW. Sounds like a proper workaround since we cannot assume that fixes from mainline gcc will ever be backported to "stable" versions. Applied, thanks! -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From kuba at gcc.gnu.org Mon May 4 09:54:15 2009 From: kuba at gcc.gnu.org (Jakub Staszak) Date: Mon, 4 May 2009 12:54:15 -0200 Subject: [LLVMdev] [PATCH] GVN improvement Message-ID: Hello, I've been analyzing GVN algorithm and I've found one place where it could be easily improved. Note that this is my first patch here. Please be tolerant ;) -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: gvn-load-pre.patch Type: application/octet-stream Size: 2236 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/d9177eef/attachment.obj From bios.bob.frankel at gmail.com Mon May 4 10:24:28 2009 From: bios.bob.frankel at gmail.com (Bob Frankel) Date: Mon, 04 May 2009 08:24:28 -0700 Subject: [LLVMdev] configure problems under msys Message-ID: <49FF08AC.7010005@gmail.com> An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/76553abc/attachment.html From anton at korobeynikov.info Mon May 4 10:59:18 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 4 May 2009 19:59:18 +0400 Subject: [LLVMdev] configure problems under msys In-Reply-To: <49FF08AC.7010005@gmail.com> References: <49FF08AC.7010005@gmail.com> Message-ID: Hello, Bob > download the latest from the head of the trunk, then ran 'configure' under > msys and received the following....? has anyone done this under msys on a > windows pc?? Msys works fine for me. What is the version of msys you're using? What is the version of bash? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From bios.bob.frankel at gmail.com Mon May 4 11:09:57 2009 From: bios.bob.frankel at gmail.com (Bob Frankel) Date: Mon, 04 May 2009 09:09:57 -0700 Subject: [LLVMdev] configure problems under msys In-Reply-To: References: <49FF08AC.7010005@gmail.com> Message-ID: <49FF1355.6080102@gmail.com> An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/7a3455fb/attachment.html From anton at korobeynikov.info Mon May 4 11:45:03 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 4 May 2009 20:45:03 +0400 Subject: [LLVMdev] configure problems under msys In-Reply-To: <49FF1355.6080102@gmail.com> References: <49FF08AC.7010005@gmail.com> <49FF1355.6080102@gmail.com> Message-ID: Hello, Bob > i running msys 1.0 it appears; the bash sh is 2.04.0(1) Hrm... This seems to be pretty ancient and buggy. :) Consider reading http://blogs.tedneward.com/2008/02/24/Building+LLVM+On+Windows+Using+MinGW32.aspx it can provide necessary sources of different tools requires. Some versions noted there might be already out-of-date, but otherwise the text looks good. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From grosbach at apple.com Mon May 4 11:56:11 2009 From: grosbach at apple.com (Jim Grosbach) Date: Mon, 4 May 2009 09:56:11 -0700 Subject: [LLVMdev] lli on ARM simulator In-Reply-To: References: Message-ID: On May 3, 2009, at 7:25 AM, Geoffrey Tochukwu Ndu wrote: > > I am currently looking at LLVM's JIT and would like to build an lli > tool > for an ARM simulator such as simple scalar. I would be grateful if > someone > could point me in the right direction. To run lli, you can build LLVM as a canadian cross compiler (i.e., such that the built tools run on a different architecture than the build machine). To do so, use the appropriate triples for the --build and --host configure options suited to your environment. Note that this assumes that you'll have an OS running on the simulated target suitable for launching a command line application like lli. If you have an arm-linux port for your target, you should be most of the way there (if not completely). If your environment is different, such as a custom OS of some sort, you'll have a bit more work to do, as you'll need to teach LLVM how to build for your target runtime in order to bootstrap up to having lli, and the LLVM libraries that the JIT uses, available. I would suggest having a look at the build infrastructure for LLVM and how the libraries are built then linked in to the lli application. That should give you an overview of which pieces you'll need to bring in for whatever custom JIT runtime you have in mind. Regards, Jim From korgulec at gmail.com Mon May 4 12:31:40 2009 From: korgulec at gmail.com (Michal) Date: Mon, 4 May 2009 17:31:40 +0000 Subject: [LLVMdev] Nested functions implementation Message-ID: Hi, I want to implement nested functions using llvm and I can't find much info on how to do this. Do I have to manually create frames, link them via static links and pass as an additional function argument or does llvm give some helper functions? Thanks in advance, Michal. From sricketts at maxentric.com Mon May 4 12:39:40 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Mon, 4 May 2009 10:39:40 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905011820r41710abex31af8167bac20c2c@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <6d9073030905011820r41710abex31af8167bac20c2c@mail.gmail.com> Message-ID: <6d9073030905041039o5dc5b6cfr58791c5b4b1fc36b@mail.gmail.com> I am still having problems getting everything installed. I realized that the successful build of llvm-2.5 had in fact been configured to use the system gcc (4.1.2). However, I was unable to sucessfully build llvm-gcc with gcc 4.1.2. I went back and attempted to build llvm-2.5 with gcc-4.2.4 (installed in a separate directory from system gcc). However, I got the same build error as before. Then I went back again to attempt to build llvm-2.5 with the system gcc, and was unable to reproduce a successful build. So something is wrong with my recollection of history. I think I am just configuring incorrectly. I would like to use the installation of gcc-4.2.4, which is located in /pkg/bin/gcc-4.2.4. Perhaps someone has done something similar and can provide me a working example? Details: *** llvm-2.5 configured to use gcc-4.2.4: $ ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ CC=/pkg/bin/gcc-4.2.4/bin/gcc CXX=/pkg/bin/gcc-4.2.4/bin/g++ CXXCPP=/pkg/bin/gcc-4.2.4/bin/cpp LDFLAGS=-L/pkg/bin/gcc-4.2.4/lib64/ CXXFLAGS=-I/pkg/bin/gcc-4.2.4/include/c++/4.2.4/ CPPFLAGS=-I/pkg/bin/gcc-4.2.4/include/ llvm-2.5 build: $ make tools-only error: make[1]: Entering directory `/pkg/build/llvm/llvm-obj/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td /pkg/build/llvm/llvm-obj/Release/bin/tblgen: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /pkg/build/llvm/llvm-obj/Release/bin/tblgen) make[1]: *** [/pkg/build/llvm/llvm-obj/lib/VMCore/Release/Intrinsics.gen.tmp] Error 1 make[1]: Leaving directory `/pkg/build/llvm/llvm-obj/lib/VMCore' make: *** [all] Error 1 *** llvm-2.5 configured to use default gcc (4.1.2): $ ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ llvm-2.5 build: $ make tools-only error (something like): X86ISelDAGToDAG.cpp internal compiler error: Segmentation fault On Fri, May 1, 2009 at 6:20 PM, Scott Ricketts wrote: > Ah, nevermind... just needed to make clean to clear out some of the junk I > compiled with gcc-4.1.2. The build completed without error. > > > On Fri, May 1, 2009 at 2:14 PM, Scott Ricketts wrote: > >> I am attempting to install llvm on CentOS 5.3, which uses gcc-4.1.2 as its >> system compiler. Since this compiler has reported to behave poorly with >> llvm, I built gcc-4.2.4 in an insulated directory for use with my llvm >> installation. >> >> However, I am not sure I am configuring properly. The gcc-4.2.4 >> installation is in /pkg/bin/gcc-4.2.4. Here is my config line: >> >> ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ >> CC=/pkg/bin/gcc-4.2.4/bin/gcc CXX=/pkg/bin/gcc-4.2.4/bin/g++ >> CXXCPP=/pkg/bin/gcc-4.2.4/bin/cpp LDFLAGS=-L /pkg/bin/gcc-4.2.4/lib64/ >> CXXFLAGS=-I/pkg/bin/gcc-4.2.4/include/c++/4.2.4/ >> CPPFLAGS=-I/pkg/bin/gcc-4.2.4/include/ >> >> I am trying to specify all the appropriate environment variables for using >> the non-default gcc. However, it is likely that I have made an error or are >> ommitting some important variable(s). >> >> Then I do "gmake tools-only" (because I have yet to build the llvm-gcc >> front end). Here is the error: >> >> gmake[1]: Entering directory `/pkg/build/llvm/llvm-obj/lib/VMCore' >> llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td >> /pkg/build/llvm/llvm-obj/Release/bin/tblgen: /usr/lib64/libstdc++.so.6: >> version `GLIBCXX_3.4.9' not found (required by >> /pkg/build/llvm/llvm-obj/Release/bin/tblgen) >> gmake[1]: *** >> [/pkg/build/llvm/llvm-obj/lib/VMCore/Release/Intrinsics.gen.tmp] Error 1 >> gmake[1]: Leaving directory `/pkg/build/llvm/llvm-obj/lib/VMCore' >> gmake: *** [all] Error 1 >> >> >> So it is looking in /usr/lib64/ for libstdc++.so.6, when in fact I want it >> to look in /pkg//bin/gcc-4.2.4/lib64/ (which I thought I had specified with >> the configuration). >> >> Any help would be appreciated. >> >> Thanks, >> Scott >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/f04486a6/attachment.html From eli.friedman at gmail.com Mon May 4 12:39:45 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 4 May 2009 10:39:45 -0700 Subject: [LLVMdev] Nested functions implementation In-Reply-To: References: Message-ID: On Mon, May 4, 2009 at 10:31 AM, Michal wrote: > Hi, > I want to implement nested functions using llvm and I can't find much > info on how to do this. > Do I have to manually create frames, link them via static links and > pass as an additional function > argument or does llvm give some helper functions? You have to do it by hand... the only help LLVM provides for nested functions is the trampoline intrinsic (http://llvm.org/docs/LangRef.html#int_trampoline), which lets you implement taking the address of a nested function. -Eli From evan.cheng at apple.com Mon May 4 12:42:24 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 4 May 2009 10:42:24 -0700 Subject: [LLVMdev] lli on ARM simulator In-Reply-To: References: Message-ID: <6FDD0477-64E7-48B6-9272-0646428B549E@apple.com> I think folks have had success with QEMU. I am not sure if the process if documented somewhere. Evan On May 3, 2009, at 7:25 AM, Geoffrey Tochukwu Ndu wrote: > Hello, > > I am new to LLVM and complier development, am more comfortable with > logic > gates. However, I am part of a research project that intends to > develop a > co-designed virtual machine reconfigurable computing, the virtual > machine > controls a reconfigurable fabric in addition to a microprocessor. The > microprocessor may be an ARM and the system should employ a JIT to > generate > code for the processor and the fabric. We are thinking of leveraging > the > LLVM infrastructure for this project. It has most of the stuff we > need, a > front-end, an extensible low level IR and a JIT. > > I am currently looking at LLVM's JIT and would like to build an lli > tool > for an ARM simulator such as simple scalar. I would be grateful if > someone > could point me in the right direction. > > > > geoffrey > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From bios.bob.frankel at gmail.com Mon May 4 12:55:43 2009 From: bios.bob.frankel at gmail.com (Bob Frankel) Date: Mon, 04 May 2009 10:55:43 -0700 Subject: [LLVMdev] configure problems under msys In-Reply-To: References: <49FF08AC.7010005@gmail.com> <49FF1355.6080102@gmail.com> Message-ID: <49FF2C1F.90004@gmail.com> An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/99855159/attachment.html From stefanus.dutoit at rapidmind.com Mon May 4 13:02:01 2009 From: stefanus.dutoit at rapidmind.com (Stefanus Du Toit) Date: Mon, 4 May 2009 14:02:01 -0400 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <2f4f3caa-ef17-42e6-b219-4947f37f3eea@v17g2000vbb.googlegroups.com> References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> <91874256-2A2F-4ADC-BCD4-8E24889B4926@rapidmind.com> <2f4f3caa-ef17-42e6-b219-4947f37f3eea@v17g2000vbb.googlegroups.com> Message-ID: <6ED3BB14-7EB6-4290-AD28-B6B8E5EAAEF3@rapidmind.com> Hi Gabor, On 3-May-09, at 4:57 PM, Gabor Greif wrote: > Your analysis is perfectly correct. I Was AFK for the last two days, > so I couldn't > tell you this same story. Thanks, glad I was on the right track :). > The algorithm relies on the fact that the LSBit of the first "pointer" > in User > is zero. This is normally the case with VPtrs, which are "normally" > placed there > by ABIs. Originally, I just checked that bit verbatim, and later by > means of > PointerIntPair. The problem arose when PointerIntPair's layout > changed. > I think we could switch back without a loss. > > Btw. the alignment of pointers in a 32 bit machine is 4, so I do not > understand > how the traits define 3 free bits for them. Maybe sabre can explain > that change > which caused the breakage. Well, that's actually been that way for a long time. What's changed recently is that the high available bits are actually used now, whereas before, if you only asked for one bit, only the LSB would be used. As the (now inconsistent) comments in the code explain, the traits class assumed that pointers (not the pointees, the pointers themselves!) got allocated by malloc unless otherwise specialized, and that malloc will return 8-byte-aligned pointers. Obviously this is not true in general; the trait should probably be using AlignOf anyways, since pointers might even be less aligned than that on say 16-bit systems. I'm planning to clean this up. > Is there any acute breakage left? I don't believe so, at least not under Windows. > I assume that there will be problems with layouts on compilers with > non-standard > ABIs that place the Vptr in a different location, or use other means > of dispatch. > > I am happy to work on this if you now a serious platform that breaks > my assumption. I don't know of any. Out of curiosity, do you have any reference that guarantees that MSVC will always place a pointer at the start of a User? As I mentioned I have a patch pending that I'll commit soon that adds a bunch of comments and will document this assumption in the code. I was also wondering if we could get rid of AugmentedUse. Is there any reason we don't just cast the actual end of the list (i.e. the result of getImpliedUser) to a PointerIntPair (or a void* passed to it) directly? Unless there's some specific reason why AugmentedUse exists, it seems to me like it only makes the code more confusing. If you're OK with this change I'll make it along with my comment changes. I wouldn't mind renaming getImpliedUser to getEndOfUses or something like that either... I also want to add an assert to catch having a non-zero bit in there directly when the User is constructed in the future. I'm just not sure where to put it yet. Stefanus -- Stefanus Du Toit RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 From anton at korobeynikov.info Mon May 4 13:31:22 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 04 May 2009 22:31:22 +0400 Subject: [LLVMdev] configure problems under msys In-Reply-To: <49FF2C1F.90004@gmail.com> References: <49FF08AC.7010005@gmail.com> <49FF1355.6080102@gmail.com> <49FF2C1F.90004@gmail.com> Message-ID: <1241461882.18321.29.camel@aslstation> Hello, Bob > i upgrade my bash, per instructions on the blog.... but the configure > script is still causing segmentations faults.... again, i'm running > configure with *no* arguments.... No idea then. Everything works perfectly here (even w/o any parameters to configure). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From overminddl1 at gmail.com Mon May 4 15:15:30 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 4 May 2009 14:15:30 -0600 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <6ED3BB14-7EB6-4290-AD28-B6B8E5EAAEF3@rapidmind.com> References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> <91874256-2A2F-4ADC-BCD4-8E24889B4926@rapidmind.com> <2f4f3caa-ef17-42e6-b219-4947f37f3eea@v17g2000vbb.googlegroups.com> <6ED3BB14-7EB6-4290-AD28-B6B8E5EAAEF3@rapidmind.com> Message-ID: <3f49a9f40905041315r3271a0b0ka690328246e1503@mail.gmail.com> On Mon, May 4, 2009 at 12:02 PM, Stefanus Du Toit wrote: > /* snip PointerIntPair bug */ I had made a toy language a month ago to catch back up to the latest svn LLVM api and for some reason anytime I used a compare operator (<, =, or > are all this toy language has) that was inside a function definition (a prime example is this code "(begin (define (fib n) (if (< n 3) 1 (+ (fib (- n 1)) (fib (- n 2))))) (fib (+ 1 3)))" of the toy language, even if reduced so all it does is return the (< n 3) part), then anytime I JITed the function and called it, when the JIT compiled it, it always crashed. I ran out of time to mess with it due to RL issues, but I tried to debug that one section of code for 3 days straight, tried every combination I could think of and so forth. When I debug into the JIT compiler and followed it, it always crashed when it got the Uses of the instruction that used the compare (which was always a zero-extend to 32-bit integer since every variable in this toy language is a 32-bit integer, but it also did it if I removed that instruction, changed it to something else, etc...) it went into the function, and ended up going through about 8 or so other functions that did not look like they did anything but route to other instructions (testing class type, removing references if necessary, so on and so forth, would not std::tr1::type_traits be *much* better for this stuff, just including Boost.Type_Traits would make it work on other platforms, and less code in your base to deal with), and the final instruction call returned a pointer to what should have been the compare, but it was always in some other random (non-allocated) memory. Although I cannot check right now (still real-life issues in the way, I could check in two weeks, maybe sooner if I get a free moment while at home), but from what I remember of the pointer value, I would bet real money that the bit pattern got shifted from what the Compare instruction pointer value was supposed to be. Hence, I bet the issue I was seeing and tried to fix for a couple of days before I ran out of time is this exact issue, and yes, I am using Visual Studio 2005. I have the toy language at my local home svn, if anyone wants access I can give you all the link so you can download and try it out (built with LLVM trunk SVN about a month or two ago, and Boost 1.40, hence, Boost trunk SVN) to confirm that this is the issue, or if you fix this issue in LLVM trunk, then I can resync and rebuild LLVM and see if that fixes the problem I have, the toy language code "(begin (define (tes n) (< n 1)))" reliably causes the bug I had been experiencing (as does the full Fibonacci function above). Actually, I am *very* curious if this is the bug. I can try to see if it is now that I know what to look for (or if you fix it in SVN then I will first make sure the bug still exists in mine, when it does then I will update LLVM to the latest trunk and test again, if it was fixed that I will be giving many thanks), but the earliest that I might be able to check will be this coming Thursday night. From stefanus.dutoit at rapidmind.com Mon May 4 15:33:11 2009 From: stefanus.dutoit at rapidmind.com (Stefanus Du Toit) Date: Mon, 4 May 2009 16:33:11 -0400 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <3f49a9f40905041315r3271a0b0ka690328246e1503@mail.gmail.com> References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> <91874256-2A2F-4ADC-BCD4-8E24889B4926@rapidmind.com> <2f4f3caa-ef17-42e6-b219-4947f37f3eea@v17g2000vbb.googlegroups.com> <6ED3BB14-7EB6-4290-AD28-B6B8E5EAAEF3@rapidmind.com> <3f49a9f40905041315r3271a0b0ka690328246e1503@mail.gmail.com> Message-ID: <848ADBFE-B828-4DC3-ABE5-E6BDA3EC0E30@rapidmind.com> On 4-May-09, at 4:15 PM, OvermindDL1 wrote: > Actually, I am *very* curious if this is the bug. I can try to see if > it is now that I know what to look for (or if you fix it in SVN then I > will first make sure the bug still exists in mine, when it does then I > will update LLVM to the latest trunk and test again, if it was fixed > that I will be giving many thanks), but the earliest that I might be > able to check will be this coming Thursday night. If it is the same problem (and it very much sounds like it is), it should be fixed in trunk now. Chris reduced the alignment assumption on pointers to 2 a few days ago. Sorry if that wasn't clear from the thread. The discussion since then has mostly been about whether we can improve on this, or if the status quo is OK. Stefanus -- Stefanus Du Toit RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 From jp-keyword-llvmdev.cff0a2 at jpbonn.com Mon May 4 15:39:10 2009 From: jp-keyword-llvmdev.cff0a2 at jpbonn.com (jpbonn) Date: Mon, 04 May 2009 13:39:10 -0700 Subject: [LLVMdev] testing a new target backend Message-ID: <49FF526E.3090902@jpbonn.com> I'd like to try running the LLVM test suite on a new backend. It appears the test suite only uses llvm-gcc and not clang. Is that correct? Can the test suite be configure to use clang? We haven't ported our target to llvm-gcc. From overminddl1 at gmail.com Mon May 4 15:39:55 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 4 May 2009 14:39:55 -0600 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <3f49a9f40905041315r3271a0b0ka690328246e1503@mail.gmail.com> References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> <91874256-2A2F-4ADC-BCD4-8E24889B4926@rapidmind.com> <2f4f3caa-ef17-42e6-b219-4947f37f3eea@v17g2000vbb.googlegroups.com> <6ED3BB14-7EB6-4290-AD28-B6B8E5EAAEF3@rapidmind.com> <3f49a9f40905041315r3271a0b0ka690328246e1503@mail.gmail.com> Message-ID: <3f49a9f40905041339o39c7c7a0m175fa4a36ea862f4@mail.gmail.com> On Mon, May 4, 2009 at 2:15 PM, OvermindDL1 wrote: > On Mon, May 4, 2009 at 12:02 PM, Stefanus Du Toit > wrote: >> /* snip PointerIntPair bug */ > > I had made a toy language a month ago to catch back up to the latest > svn LLVM api and for some reason anytime I used a compare operator (<, > =, or > are all this toy language has) that was inside a function > definition (a prime example is this code "(begin (define (fib n) (if > (< n 3) 1 (+ (fib (- n 1)) (fib (- n 2))))) (fib (+ 1 3)))" of the toy > language, even if reduced so all it does is return the (< n 3) part), > then anytime I JITed the function and called it, when the JIT compiled > it, it always crashed. ?I ran out of time to mess with it due to RL > issues, but I tried to debug that one section of code for 3 days > straight, tried every combination I could think of and so forth. ?When > I debug into the JIT compiler and followed it, it always crashed when > it got the Uses of the instruction that used the compare (which was > always a zero-extend to 32-bit integer since every variable in this > toy language is a 32-bit integer, but it also did it if I removed that > instruction, changed it to something else, etc...) it went into the > function, and ended up going through about 8 or so other functions > that did not look like they did anything but route to other > instructions (testing class type, removing references if necessary, so > on and so forth, would not std::tr1::type_traits be *much* better for > this stuff, just including Boost.Type_Traits would make it work on > other platforms, and less code in your base to deal with), and the > final instruction call returned a pointer to what should have been the > compare, but it was always in some other random (non-allocated) > memory. ?Although I cannot check right now (still real-life issues in > the way, I could check in two weeks, maybe sooner if I get a free > moment while at home), but from what I remember of the pointer value, > I would bet real money that the bit pattern got shifted from what the > Compare instruction pointer value was supposed to be. > > Hence, I bet the issue I was seeing and tried to fix for a couple of > days before I ran out of time is this exact issue, and yes, I am using > Visual Studio 2005. ?I have the toy language at my local home svn, if > anyone wants access I can give you all the link so you can download > and try it out (built with LLVM trunk SVN about a month or two ago, > and Boost 1.40, hence, Boost trunk SVN) to confirm that this is the > issue, or if you fix this issue in LLVM trunk, then I can resync and > rebuild LLVM and see if that fixes the problem I have, the toy > language code "(begin (define (tes n) (< n 1)))" reliably causes the > bug I had been experiencing (as does the full Fibonacci function > above). > > Actually, I am *very* curious if this is the bug. ?I can try to see if > it is now that I know what to look for (or if you fix it in SVN then I > will first make sure the bug still exists in mine, when it does then I > will update LLVM to the latest trunk and test again, if it was fixed > that I will be giving many thanks), but the earliest that I might be > able to check will be this coming Thursday night. > Also, it does not only happen with the JIT, but also some passes, for example, if I add this pass: m_FunctionPassManager->add(llvm::createPromoteMemoryToRegisterPass()); It happens inside that one as well, so it is not just a JIT occurrence. From vargaz at gmail.com Mon May 4 16:28:37 2009 From: vargaz at gmail.com (Zoltan Varga) Date: Mon, 4 May 2009 23:28:37 +0200 Subject: [LLVMdev] [PATCH] Add support for accessing the FS segment register on X86 Message-ID: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> Hi, The attached patch adds support for accessing the FS segment register using address space 255, similarly to the way the GS segment register can be accessed. This is useful for generating TLS access code on amd64 for example. Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/9b4c0165/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: fs.diff Type: text/x-diff Size: 6557 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/9b4c0165/attachment.bin From ssen at apple.com Mon May 4 16:36:54 2009 From: ssen at apple.com (Shantonu Sen) Date: Mon, 4 May 2009 14:36:54 -0700 Subject: [LLVMdev] [PATCH] Add support for accessing the FS segment register on X86 In-Reply-To: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> References: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> Message-ID: <8B4C8F94-7641-4B84-B404-B3E4AD6C3BFA@apple.com> Maybe 257 would be better (or other unused), because of r70197, which gives special behavior for <256 Shantonu Sen ssen at apple.com Sent from my Mac Pro On May 4, 2009, at 2:28 PM, Zoltan Varga wrote: > Hi, > > The attached patch adds support for accessing the FS segment > register using address space 255, similarly to the way the GS > segment register can be accessed. This is useful for generating TLS > access code on amd64 for example. > > Zoltan > -------------- next part -------------- A non-text attachment was scrubbed... Name: fs.diff Type: text/x-diff Size: 6558 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/9de81b32/attachment.bin -------------- next part -------------- > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From vargaz at gmail.com Mon May 4 16:59:56 2009 From: vargaz at gmail.com (Zoltan Varga) Date: Mon, 4 May 2009 23:59:56 +0200 Subject: [LLVMdev] [PATCH] Add support for accessing the FS segment register on X86 In-Reply-To: <8B4C8F94-7641-4B84-B404-B3E4AD6C3BFA@apple.com> References: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> <8B4C8F94-7641-4B84-B404-B3E4AD6C3BFA@apple.com> Message-ID: <295e750a0905041459t4bc3dbd8u962cfd1c51f2885e@mail.gmail.com> Hi, Here is an updated version of the patch using address space 257. Zoltan On Mon, May 4, 2009 at 11:36 PM, Shantonu Sen wrote: > Maybe 257 would be better (or other unused), because of r70197, which gives > special behavior for <256 > > Shantonu Sen > ssen at apple.com > > Sent from my Mac Pro > > > On May 4, 2009, at 2:28 PM, Zoltan Varga wrote: > > Hi, >> >> The attached patch adds support for accessing the FS segment register >> using address space 255, similarly to the way the GS segment register can be >> accessed. This is useful for generating TLS access code on amd64 for >> example. >> >> Zoltan >> >> > _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/78c348fb/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: fs.diff Type: text/x-diff Size: 3518 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090504/78c348fb/attachment.bin From gohman at apple.com Mon May 4 17:16:11 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 4 May 2009 15:16:11 -0700 Subject: [LLVMdev] [PATCH] Add support for accessing the FS segment register on X86 In-Reply-To: <295e750a0905041459t4bc3dbd8u962cfd1c51f2885e@mail.gmail.com> References: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> <8B4C8F94-7641-4B84-B404-B3E4AD6C3BFA@apple.com> <295e750a0905041459t4bc3dbd8u962cfd1c51f2885e@mail.gmail.com> Message-ID: Hello, The preferred way to do TLS is to use the thread_local keyword. There is x86-64 support for thread_local on ELF; if you need it for other targets, I recommend looking at adapting it. Dan On May 4, 2009, at 2:59 PM, Zoltan Varga wrote: > Hi, > > Here is an updated version of the patch using address space 257. > > Zoltan > > On Mon, May 4, 2009 at 11:36 PM, Shantonu Sen wrote: > Maybe 257 would be better (or other unused), because of r70197, > which gives special behavior for <256 > > Shantonu Sen > ssen at apple.com > > Sent from my Mac Pro > > > On May 4, 2009, at 2:28 PM, Zoltan Varga wrote: > > Hi, > > The attached patch adds support for accessing the FS segment > register using address space 255, similarly to the way the GS > segment register can be accessed. This is useful for generating TLS > access code on amd64 for example. > > Zoltan > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From clattner at apple.com Mon May 4 17:30:59 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 4 May 2009 15:30:59 -0700 Subject: [LLVMdev] [PATCH] Add support for accessing the FS segment register on X86 In-Reply-To: References: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> <8B4C8F94-7641-4B84-B404-B3E4AD6C3BFA@apple.com> <295e750a0905041459t4bc3dbd8u962cfd1c51f2885e@mail.gmail.com> Message-ID: <4DD95C46-5661-4B0B-9E35-5C36C0B4B7B7@apple.com> On May 4, 2009, at 3:16 PM, Dan Gohman wrote: > Hello, > > The preferred way to do TLS is to use the thread_local keyword. > There is x86-64 support for thread_local on ELF; if you need > it for other targets, I recommend looking at adapting it. That said, the X86 backend supporting access off FS is general goodness, right? -Chris From vargaz at gmail.com Mon May 4 17:37:16 2009 From: vargaz at gmail.com (Zoltan Varga) Date: Tue, 5 May 2009 00:37:16 +0200 Subject: [LLVMdev] [PATCH] Add support for accessing the FS segment register on X86 In-Reply-To: References: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> <8B4C8F94-7641-4B84-B404-B3E4AD6C3BFA@apple.com> <295e750a0905041459t4bc3dbd8u962cfd1c51f2885e@mail.gmail.com> Message-ID: <295e750a0905041537q2b20ba3fu6d3566857af1c586@mail.gmail.com> Hi, If I'm writing a JIT, and want to access the TLS variables of the app containing the JIT, I can't use thread_local since that only works for variables declared in LLVM IL and/or managed by the ExecutionEngine. While this patch allows a JIT to generate the TLS accesses itself, if it knows the tls offset of the variable in question. Zoltan On Tue, May 5, 2009 at 12:16 AM, Dan Gohman wrote: > Hello, > > The preferred way to do TLS is to use the thread_local keyword. > There is x86-64 support for thread_local on ELF; if you need > it for other targets, I recommend looking at adapting it. > > Dan > > On May 4, 2009, at 2:59 PM, Zoltan Varga wrote: > > > Hi, > > > > Here is an updated version of the patch using address space 257. > > > > Zoltan > > > > On Mon, May 4, 2009 at 11:36 PM, Shantonu Sen wrote: > > Maybe 257 would be better (or other unused), because of r70197, > > which gives special behavior for <256 > > > > Shantonu Sen > > ssen at apple.com > > > > Sent from my Mac Pro > > > > > > On May 4, 2009, at 2:28 PM, Zoltan Varga wrote: > > > > Hi, > > > > The attached patch adds support for accessing the FS segment > > register using address space 255, similarly to the way the GS > > segment register can be accessed. This is useful for generating TLS > > access code on amd64 for example. > > > > Zoltan > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/b81b4967/attachment.html From gohman at apple.com Mon May 4 17:42:52 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 4 May 2009 15:42:52 -0700 Subject: [LLVMdev] [PATCH] Add support for accessing the FS segment register on X86 In-Reply-To: <4DD95C46-5661-4B0B-9E35-5C36C0B4B7B7@apple.com> References: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> <8B4C8F94-7641-4B84-B404-B3E4AD6C3BFA@apple.com> <295e750a0905041459t4bc3dbd8u962cfd1c51f2885e@mail.gmail.com> <4DD95C46-5661-4B0B-9E35-5C36C0B4B7B7@apple.com> Message-ID: On May 4, 2009, at 3:30 PM, Chris Lattner wrote: > > On May 4, 2009, at 3:16 PM, Dan Gohman wrote: > >> Hello, >> >> The preferred way to do TLS is to use the thread_local keyword. >> There is x86-64 support for thread_local on ELF; if you need >> it for other targets, I recommend looking at adapting it. > > That said, the X86 backend supporting access off FS is general > goodness, right? Please consider changing clang to expose this functionality via names, rather than magic numbers. The fact that clang has chosen to expose x86 esoterica via LLVM-specific magic numbers is distasteful. Also, please add a note in clang's manual that address-spaces are not intended to be used for normal TLS. They don't actually work the same way, and this fact is non-obvious. Further, please document that address-space qualifiers on variables with static storage are not actually handled specially. So something like "address_space(256) int x; address_space(256) int *y = &x" does not actually result in y pointing at x. Actually, please change the front-end to outright disallow this. Do all of those things, and I may agree :-). Dan From evan.cheng at apple.com Mon May 4 17:49:33 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 4 May 2009 15:49:33 -0700 Subject: [LLVMdev] [PATH] Fixes for the amd64 JIT code In-Reply-To: <23362528.post@talk.nabble.com> References: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> <01051155-8E3D-4D6B-BDAE-C6ADA590192B@apple.com> <23362528.post@talk.nabble.com> Message-ID: <98A26E3E-2CD5-47B7-A36D-E73C3A262DAF@apple.com> Committed as revision 70929. Thanks. Evan On May 3, 2009, at 8:29 PM, vargaz wrote: > > Hi, > > If this looks ok, could somebody check it in ? > > thanks > > Zoltan > > > Evan Cheng-2 wrote: >> >> Looks good. Thanks. >> >> Evan >> >> On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: >> >>> Hi, >>> >>> The attached patch contains the following changes: >>> >>> * X86InstrInfo.cpp: Synchronize a few places with the code in >>> X86CodeEmitter.cpp >>> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it >>> is not neeed. >>> >>> Zoltan >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > -- > View this message in context: http://www.nabble.com/-PATH--Fixes-for-the-amd64-JIT-code-tp23335910p23362528.html > Sent from the LLVM - Dev mailing list archive at Nabble.com. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From overminddl1 at gmail.com Mon May 4 17:54:27 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Mon, 4 May 2009 16:54:27 -0600 Subject: [LLVMdev] PointerIntPair causing trouble In-Reply-To: <848ADBFE-B828-4DC3-ABE5-E6BDA3EC0E30@rapidmind.com> References: <000301c9ca48$25fec740$71fc55c0$@net> <869F0034-E4F8-4C60-9D1E-94C7C541E0FB@rapidmind.com> <91874256-2A2F-4ADC-BCD4-8E24889B4926@rapidmind.com> <2f4f3caa-ef17-42e6-b219-4947f37f3eea@v17g2000vbb.googlegroups.com> <6ED3BB14-7EB6-4290-AD28-B6B8E5EAAEF3@rapidmind.com> <3f49a9f40905041315r3271a0b0ka690328246e1503@mail.gmail.com> <848ADBFE-B828-4DC3-ABE5-E6BDA3EC0E30@rapidmind.com> Message-ID: <3f49a9f40905041554s219c6b6bk7a8ecbfc0cc74fef@mail.gmail.com> On Mon, May 4, 2009 at 2:33 PM, Stefanus Du Toit wrote: > On 4-May-09, at 4:15 PM, OvermindDL1 wrote: >> Actually, I am *very* curious if this is the bug. ?I can try to see if >> it is now that I know what to look for (or if you fix it in SVN then I >> will first make sure the bug still exists in mine, when it does then I >> will update LLVM to the latest trunk and test again, if it was fixed >> that I will be giving many thanks), but the earliest that I might be >> able to check will be this coming Thursday night. > > If it is the same problem (and it very much sounds like it is), it > should be fixed in trunk now. Chris reduced the alignment assumption > on pointers to 2 a few days ago. Sorry if that wasn't clear from the > thread. The discussion since then has mostly been about whether we can > improve on this, or if the status quo is OK. Wonderful then, I will give it a try at my next available opportunity (probably this coming Thursday night, unless I decide to shirk a duty or two...). From dag at cray.com Mon May 4 18:47:52 2009 From: dag at cray.com (David Greene) Date: Mon, 4 May 2009 18:47:52 -0500 Subject: [LLVMdev] llvm-gcc-4.2 Build Problems Message-ID: <200905041847.52810.dag@cray.com> Still working on the validator buildbot as I can. Now I'm tackling what appears to be a configure problem for llvm-gcc-4.2. Here's the configure log: ../src/configure --prefix=/ptmp/dag/buildbot/slaves/llvm-validate/llvm-validate-release-kentsfield-linux/build/install --program-prefix=llvm- --enable-llvm=/ptmp/dag/buildbot/slaves/llvm-validate/llvm-validate-release-kentsfield-linux/build/llvm-initial/obj --enable-languages=c,c++ creating cache ./config.cache checking host system type... config.sub: missing argument Try `config.sub --help' for more information. checking target system type... config.sub: missing argument Try `config.sub --help' for more information. checking build system type... config.sub: missing argument Try `config.sub --help' for more information. checking for a BSD compatible install... /usr/bin/install -c checking whether ln works... yes [...] This eventually leads to a failure to find genmodes during boostrap so everything blows up. If I run this in the shell, it appears to work fine. More strangely, this only fails on release builds. A debug build buildbot finishes just fine. Anyone seen anything like this before? -Dave From nicolas at capens.net Tue May 5 00:52:08 2009 From: nicolas at capens.net (Nicolas Capens) Date: Tue, 5 May 2009 07:52:08 +0200 Subject: [LLVMdev] [PATH] Fixes for the amd64 JIT code In-Reply-To: <23362528.post@talk.nabble.com> References: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> <01051155-8E3D-4D6B-BDAE-C6ADA590192B@apple.com> <23362528.post@talk.nabble.com> Message-ID: <002d01c9cd45$a07b9160$e172b420$@net> Hi Zoltan, I reported a bug which appears to be a duplicate of what you've been working on: http://llvm.org/bugs/show_bug.cgi?id=4149 Could you maybe review my proposed patch? If it's completely fixed in revision 70929 I can close the bug report. Thanks! Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of vargaz Sent: maandag 4 mei 2009 5:29 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [PATH] Fixes for the amd64 JIT code Hi, If this looks ok, could somebody check it in ? thanks Zoltan Evan Cheng-2 wrote: > > Looks good. Thanks. > > Evan > > On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: > >> Hi, >> >> The attached patch contains the following changes: >> >> * X86InstrInfo.cpp: Synchronize a few places with the code in >> X86CodeEmitter.cpp >> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it >> is not neeed. >> >> Zoltan >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- View this message in context: http://www.nabble.com/-PATH--Fixes-for-the-amd64-JIT-code-tp23335910p2336252 8.html Sent from the LLVM - Dev mailing list archive at Nabble.com. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From evan.cheng at apple.com Tue May 5 01:02:25 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 4 May 2009 23:02:25 -0700 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <469F019E-7E04-41BC-BB11-12570A4BED0F@apple.com> References: <200904301759.12384.dag@cray.com> <9F20A521-BB17-4995-86A3-436C7E853613@apple.com> <200905011647.13167.dag@cray.com> <469F019E-7E04-41BC-BB11-12570A4BED0F@apple.com> Message-ID: On May 1, 2009, at 3:50 PM, Chris Lattner wrote: > > The goal is to replace the pattern fragment and the C++ code for > X86::isMOVDDUPMask with something like: > > def movddup : PatFrag<(ops node:$lhs, node:$rhs), > (vector_shuffle node:$lhs, node:$rhs, > 0, 1, 0, 1, Cost<42>) > > Alternatively, the cost could be put on the instructions etc, whatever > makes the most sense. incidentally, I'm not sure why movddup is > currently defined to take a LHS/RHS: the RHS should always be undef so > it should be coded into the movddup def. > > Another possible syntax would be to add a special kind of shuffle node > to give more natural and clean syntax. This is probably the better > solution: > > def movddup : Shuffle4, Cost<42>; What does "cost" mean here? Currently isel cost means complexity of the matched pattern. It's hard to compute this by hand so the current hack is to allow manual cost adjustments. I think it makes sense for isel to use HW cost (instruction latency, code size) as a late tie breaker. In that case, shouldn't cost be part of instruction itinerary? Evan From mikael.lepisto at tut.fi Tue May 5 01:03:46 2009 From: mikael.lepisto at tut.fi (=?ISO-8859-1?Q?Mikael_Lepist=F6?=) Date: Tue, 5 May 2009 09:03:46 +0300 Subject: [LLVMdev] Installing tbgen with llvm by default. Message-ID: <682D1598-44D2-4CE1-AD28-113F0B5B9F06@tut.fi> Hi, Would it be possible to set tbgen to be installed with llvm? For our project http://llvm.org/ProjectsWithLLVM/#tta-tce it would be very helpful, because our tools generate compiler backend plugins in the fly for each customized processor and plugin generation needs tbgen for handling td files. Because of tbgen not beeing distributed, our users cannot use llvm from their favorite distribution packages, but they have to have llvm sources as well to be able to use our tools. Basically we have workaround where we copy tbgen sources of each supported version of llvm to our project tree and write compile rules and install it with our project, which is a bit painful. Mikael Lepist? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/e49de0d1/attachment.html From Christian.Sayer at dibcom.fr Tue May 5 02:56:29 2009 From: Christian.Sayer at dibcom.fr (Christian Sayer) Date: Tue, 5 May 2009 09:56:29 +0200 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905041039o5dc5b6cfr58791c5b4b1fc36b@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <6d9073030905011820r41710abex31af8167bac20c2c@mail.gmail.com> <6d9073030905041039o5dc5b6cfr58791c5b4b1fc36b@mail.gmail.com> Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4AFA7EFF5E14@FRPAR1CL009.coe.adi.dibcom.com> Scott, did you try a simple $ ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ CC=/pkg/bin/gcc-4.2.4/bin/gcc CXX=/pkg/bin/gcc-4.2.4/bin/g++ This is how I use to configure for non-system gcc 4.3.2 and it works well. The right headers are included automatically from the correct directory, and besides that I think that none of the std libraries is linked statically I guess it would pick the right ones as well. Just make sure to load the right shared libs on runtime. Regards, Christian -- Christian SAYER ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Scott Ricketts Sent: Monday, May 04, 2009 7:40 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end I am still having problems getting everything installed. I realized that the successful build of llvm-2.5 had in fact been configured to use the system gcc (4.1.2). However, I was unable to sucessfully build llvm-gcc with gcc 4.1.2. I went back and attempted to build llvm-2.5 with gcc-4.2.4 (installed in a separate directory from system gcc). However, I got the same build error as before. Then I went back again to attempt to build llvm-2.5 with the system gcc, and was unable to reproduce a successful build. So something is wrong with my recollection of history. I think I am just configuring incorrectly. I would like to use the installation of gcc-4.2.4, which is located in /pkg/bin/gcc-4.2.4. Perhaps someone has done something similar and can provide me a working example? Details: *** llvm-2.5 configured to use gcc-4.2.4: $ ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ CC=/pkg/bin/gcc-4.2.4/bin/gcc CXX=/pkg/bin/gcc-4.2.4/bin/g++ CXXCPP=/pkg/bin/gcc-4.2.4/bin/cpp LDFLAGS=-L/pkg/bin/gcc-4.2.4/lib64/ CXXFLAGS=-I/pkg/bin/gcc-4.2.4/include/c++/4.2.4/ CPPFLAGS=-I/pkg/bin/gcc-4.2.4/include/ llvm-2.5 build: $ make tools-only error: make[1]: Entering directory `/pkg/build/llvm/llvm-obj/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td /pkg/build/llvm/llvm-obj/Release/bin/tblgen: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /pkg/build/llvm/llvm-obj/Release/bin/tblgen) make[1]: *** [/pkg/build/llvm/llvm-obj/lib/VMCore/Release/Intrinsics.gen.tmp] Error 1 make[1]: Leaving directory `/pkg/build/llvm/llvm-obj/lib/VMCore' make: *** [all] Error 1 *** llvm-2.5 configured to use default gcc (4.1.2): $ ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ llvm-2.5 build: $ make tools-only error (something like): X86ISelDAGToDAG.cpp internal compiler error: Segmentation fault On Fri, May 1, 2009 at 6:20 PM, Scott Ricketts > wrote: Ah, nevermind... just needed to make clean to clear out some of the junk I compiled with gcc-4.1.2. The build completed without error. On Fri, May 1, 2009 at 2:14 PM, Scott Ricketts > wrote: I am attempting to install llvm on CentOS 5.3, which uses gcc-4.1.2 as its system compiler. Since this compiler has reported to behave poorly with llvm, I built gcc-4.2.4 in an insulated directory for use with my llvm installation. However, I am not sure I am configuring properly. The gcc-4.2.4 installation is in /pkg/bin/gcc-4.2.4. Here is my config line: ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ CC=/pkg/bin/gcc-4.2.4/bin/gcc CXX=/pkg/bin/gcc-4.2.4/bin/g++ CXXCPP=/pkg/bin/gcc-4.2.4/bin/cpp LDFLAGS=-L /pkg/bin/gcc-4.2.4/lib64/ CXXFLAGS=-I/pkg/bin/gcc-4.2.4/include/c++/4.2.4/ CPPFLAGS=-I/pkg/bin/gcc-4.2.4/include/ I am trying to specify all the appropriate environment variables for using the non-default gcc. However, it is likely that I have made an error or are ommitting some important variable(s). Then I do "gmake tools-only" (because I have yet to build the llvm-gcc front end). Here is the error: gmake[1]: Entering directory `/pkg/build/llvm/llvm-obj/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td /pkg/build/llvm/llvm-obj/Release/bin/tblgen: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /pkg/build/llvm/llvm-obj/Release/bin/tblgen) gmake[1]: *** [/pkg/build/llvm/llvm-obj/lib/VMCore/Release/Intrinsics.gen.tmp] Error 1 gmake[1]: Leaving directory `/pkg/build/llvm/llvm-obj/lib/VMCore' gmake: *** [all] Error 1 So it is looking in /usr/lib64/ for libstdc++.so.6, when in fact I want it to look in /pkg//bin/gcc-4.2.4/lib64/ (which I thought I had specified with the configuration). Any help would be appreciated. Thanks, Scott ________________________________ CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/8335cbf3/attachment.html From baldrick at free.fr Tue May 5 03:02:04 2009 From: baldrick at free.fr (Duncan Sands) Date: Tue, 5 May 2009 10:02:04 +0200 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905041039o5dc5b6cfr58791c5b4b1fc36b@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <6d9073030905011820r41710abex31af8167bac20c2c@mail.gmail.com> <6d9073030905041039o5dc5b6cfr58791c5b4b1fc36b@mail.gmail.com> Message-ID: <200905051002.04335.baldrick@free.fr> Hi, > $ ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ > CC=/pkg/bin/gcc-4.2.4/bin/gcc CXX=/pkg/bin/gcc-4.2.4/bin/g++ > CXXCPP=/pkg/bin/gcc-4.2.4/bin/cpp LDFLAGS=-L/pkg/bin/gcc-4.2.4/lib64/ > CXXFLAGS=-I/pkg/bin/gcc-4.2.4/include/c++/4.2.4/ > CPPFLAGS=-I/pkg/bin/gcc-4.2.4/include/ how about: export PATH=/pkg/bin/:$PATH ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ instead? Ciao, Duncan. From aph at redhat.com Tue May 5 04:41:51 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 05 May 2009 10:41:51 +0100 Subject: [LLVMdev] Calling-convention lowering proposal In-Reply-To: References: <80875B80-C6E0-4362-9D68-95165C06E40E@apple.com> <200904291039.44274.dag@cray.com> <200904301138.24966.dag@cray.com> <49F9ED8C.6020403@redhat.com> <4F8A6A1A-9A65-4C90-B687-F858266A07B7@apple.com> <49FB587B.1030100@redhat.com> Message-ID: <4A0009DF.4030904@redhat.com> Evan Cheng wrote: > On May 1, 2009, at 1:15 PM, Andrew Haley wrote: > >> Evan Cheng wrote: >>> On Apr 30, 2009, at 11:27 AM, Andrew Haley wrote: >>> >>>> We'd love to keep up with the latest versions of LLVM, but stuff >>>> just keeps >>>> breaking and sometimes features are just deleted. For example, it >>>> used >>>> to be possible easily to turn on and off asm dumping, but it isn't >>>> any more. >>> That's not true. It's just the option name was changed. >> You can turn it on once, but you can never turn it off again. > > That's not different from before. It certainly was. See http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-January/019557.html >> That is, unless there is some way to do it other than by passing >> command line options to cl::ParseCommandLineOptions. The last >> time I looked the problem was that DebugOnly was defined as >> cl::ValueRequired rather than cl::OneOrMore, so the CLI would >> reject any subsequent setting. >> >> If there is some way around this, I'd be delighted to know. > > This will require modifying code. Patches welcome. Oh sorry, I thought you'd already seen it. It's at http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-January/019661.html Andrew. From zhangzhengjian at gmail.com Tue May 5 04:48:52 2009 From: zhangzhengjian at gmail.com (zhengjian zhang) Date: Tue, 5 May 2009 17:48:52 +0800 Subject: [LLVMdev] how to resolve llvm exception IR? In-Reply-To: <200904280816.17344.baldrick@free.fr> References: <8e3538210904271937k7247c5f8p13cd5995a338ccf2@mail.gmail.com> <200904280816.17344.baldrick@free.fr> Message-ID: <8e3538210905050248w78857a6bob7ba909c8295f3c0@mail.gmail.com> hi, I'm doing to make llvm backend support sjlj-eh! I have try to use the llvm-IR to generate the sjlj-eh code, but I'm totally despair ! my major problem is that llvm-ir , I mean exception instrinstics are enough for codegen the sjlj-eh code? May I need to modify the llvm-gcc ? or someone can give some advice about llvm-backend 's support sjlj-eh ? best regards zhangzw From suigintou_ at hotmail.com Tue May 5 09:00:12 2009 From: suigintou_ at hotmail.com (seventh moon) Date: Tue, 5 May 2009 22:00:12 +0800 Subject: [LLVMdev] A problem creating operands for a new IR instruction to the mailing list Message-ID: I have a question about inserting instructions into the LLVM IR. I can insert instructions, but my operands do not have the right type, so it fails an assertion at runtime. I am trying to insert an immediate load instructions, as a means of claiming a new register. Here is what I do: Builder.SetInsertPoint(LLVMBB, I); // The following line looks to me like it would have a chance of loading either // address 5, or else immediate value 5. Unfortunately, it does neither. It compiles // but crashes at runtime, that the type of the operand is incompatible Instruction *newI=Builder.CreateLoad(5,""); // I also tested this, just to do a little sanity check. It also compiles then // crashes, for the obvious reason that the operand is a register, but an address // or an immediate value is expected. //Instruction *newI=Builder.CreateLoad(I->getOperand(1),""); // also wrong So to say it simply, my question is, "How can I create a new Value*, which indicates an immediate value, such as immediate value 5?" Thank you for your assistance, Kao Chang _________________________________________________________________ ?????????????????B?v???B?????p?u???M???R?M???A?????q?X?A???v ?X Windows Live Spaces http://home.spaces.live.com/?showUnauth=1&lc=1028 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/1affa5a3/attachment.html From edwintorok at gmail.com Tue May 5 09:07:25 2009 From: edwintorok at gmail.com (=?Big5?B?VG8icm8iayBFZHdpbg==?=) Date: Tue, 05 May 2009 17:07:25 +0300 Subject: [LLVMdev] A problem creating operands for a new IR instruction to the mailing list In-Reply-To: References: Message-ID: <4A00481D.7090805@gmail.com> On 2009-05-05 17:00, seventh moon wrote: > I have a question about inserting instructions into the LLVM IR. I can > insert instructions, but my operands do not have the right type, so it > fails an assertion at runtime. > > I am trying to insert an immediate load instructions, as a means of > claiming a new register. > > Here is what I do: > Builder.SetInsertPoint(LLVMBB, I); > > // The following line looks to me like it would have a chance o! f > loading either > // address 5, or else immediate value 5. Unfortunately, it does > neither. It compiles > // but crashes at runtime, that the type of the operand is incompatible > Instruction *newI=Builder.CreateLoad(5,""); > > // I also tested this, just to do a little sanity check. It also > compiles then > // crashes, for the obvious reason that the operand is a register, but > an address > // or an immediate value is expected. > //Instruction *newI=Builder.CreateLoad(I->getOperand(1),""); // also > wrong > > So to say it simply, my question is, "How can I create a new Value*, > which indicates > an immediate value, such as immediate value 5?" You should use a constant instead of a load: Constant *C = ConstantInt::get(Type::Int32Ty, 5); Note that the constant is not an instruction, but it can be used like any other Value*. Best regards, --Edwin From meurant.olivier at gmail.com Tue May 5 09:07:33 2009 From: meurant.olivier at gmail.com (Olivier Meurant) Date: Tue, 5 May 2009 16:07:33 +0200 Subject: [LLVMdev] A problem creating operands for a new IR instruction to the mailing list In-Reply-To: References: Message-ID: <549cee610905050707v3f2b546ey5ede6980a3a81002@mail.gmail.com> If you want an immediate constant value, ConstantInt::get(APInt(32, 5, false)) will perhaps help you ? Olivier. 2009/5/5 seventh moon > I have a question about inserting instructions into the LLVM IR. I can > insert instructions, but my operands do not have the right type, so it fails > an assertion at runtime. > > I am trying to insert an immediate load instructions, as a means of > claiming a new register. > > Here is what I do: > Builder.SetInsertPoint(LLVMBB, I); > > // The following line looks to me like it would have a chance o! f loading > either > // address 5, or else immediate value 5. Unfortunately, it does neither. It > compiles > // but crashes at runtime, that the type of the operand is incompatible > Instruction *newI=Builder.CreateLoad(5,""); > > // I also tested this, just to do a little sanity check. It also compiles > then > // crashes, for the obvious reason that the operand is a register, but an > address > // or an immediate value is expected. > //Instruction *newI=Builder.CreateLoad(I->getOperand(1),""); // > also wrong > > So to say it simply, my question is, "How can I create a new Value*, which > indicates > an immediate value, such as immediate value 5?" > > Thank you for your assistance, > Kao Chang > ------------------------------ > ?????????????????B?v???B?????p?u???M???R?M???A?????q?X! ?A???v ?X Windows Live Spaces > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/ba9c9881/attachment.html From wurstgebaeck at googlemail.com Tue May 5 10:15:21 2009 From: wurstgebaeck at googlemail.com (Jan Rehders) Date: Tue, 5 May 2009 17:15:21 +0200 Subject: [LLVMdev] LLVM related jobs at mental images Message-ID: <73cfec680905050815w2467c763na31181072923356e@mail.gmail.com> Hello, mental images is looking for developers with LLVM experience to strengthen its MetaSL compiler backend team. MetaSL is a universal shader language designed to support shaders both for high quality offline rendering and GPUs. === Job Profile === Implementing and maintaining back-ends for the MetaSL compiler. === Required Skills and other Prerequisites === - Strong background in compiler-construction (code generation,optimization) - Previous experience with development of commercially-shipping compiler products - Solid knowledge of C and C++ - Basic knowledge of computer graphics - MS or Ph.D in Computer Science or equivalent experience - Self-disciplined use of work time - Capable to work in a team - Good written and verbal communication skills. - Experience with LLVM and/or ANTLR parser generator is a plus. For more information please visit http://www.mentalimages.com/company/careers.html http://www.mentalimages.com/company.html best regards, Jan Rehders From criswell at cs.uiuc.edu Tue May 5 10:26:31 2009 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 5 May 2009 10:26:31 -0500 Subject: [LLVMdev] LLVM related jobs at mental images In-Reply-To: <73cfec680905050815w2467c763na31181072923356e@mail.gmail.com> References: <73cfec680905050815w2467c763na31181072923356e@mail.gmail.com> Message-ID: <4A005AA7.9020900@cs.uiuc.edu> Dear Jan, I noticed that the MetaSL compiler is not listed on the LLVM Users page (http://llvm.cs.uiuc.edu/Users.html). Would you like it added to the list of industry users? -- John T. From clattner at apple.com Tue May 5 11:27:49 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 5 May 2009 09:27:49 -0700 Subject: [LLVMdev] Installing tbgen with llvm by default. In-Reply-To: <682D1598-44D2-4CE1-AD28-113F0B5B9F06@tut.fi> References: <682D1598-44D2-4CE1-AD28-113F0B5B9F06@tut.fi> Message-ID: <282C680B-D934-44E6-BA94-361B8DAAAF08@apple.com> On May 4, 2009, at 11:03 PM, Mikael Lepist? wrote: > Hi, > > Would it be possible to set tbgen to be installed with llvm? For our > project http://llvm.org/ProjectsWithLLVM/#tta-tce it would be very > helpful, because our tools generate compiler backend plugins in the > fly for each customized processor and plugin generation needs tbgen > for handling td files. Sure, would you care to prepare a patch? -Chris > > Because of tbgen not beeing distributed, our users cannot use llvm > from their favorite distribution packages, but they have to have > llvm sources as well to be able to use our tools. Basically we have > workaround where we copy tbgen sources of each supported version of > llvm to our project tree and write compile rules and install it with > our project, which is a bit painful. > > Mikael Lepist? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/dc34447f/attachment.html From dag at cray.com Tue May 5 11:31:03 2009 From: dag at cray.com (David Greene) Date: Tue, 5 May 2009 11:31:03 -0500 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: References: <200904301759.12384.dag@cray.com> <469F019E-7E04-41BC-BB11-12570A4BED0F@apple.com> Message-ID: <200905051131.04556.dag@cray.com> On Tuesday 05 May 2009 01:02, Evan Cheng wrote: > I think it makes sense for isel to use HW cost (instruction latency, > code size) as a late tie breaker. In that case, shouldn't cost be part > of instruction itinerary? What latency? Each implementation has its own quirks and LLVM must be flexible enough to handle them. So cost needs to be a function of the CPU type as well as the instruction. We do need a better cost/priority mechanism than AddedComplexity (the naming alone of that is very confusing). Perhaps we can have some base cost values per instruction and allow each CPU type to override them. -Dave From grosbach at apple.com Tue May 5 11:36:32 2009 From: grosbach at apple.com (Jim Grosbach) Date: Tue, 5 May 2009 09:36:32 -0700 Subject: [LLVMdev] how to resolve llvm exception IR? In-Reply-To: <8e3538210905050248w78857a6bob7ba909c8295f3c0@mail.gmail.com> References: <8e3538210904271937k7247c5f8p13cd5995a338ccf2@mail.gmail.com> <200904280816.17344.baldrick@free.fr> <8e3538210905050248w78857a6bob7ba909c8295f3c0@mail.gmail.com> Message-ID: <04A1E76E-3D0E-4313-92C4-4FB588DB2AA7@apple.com> On May 5, 2009, at 2:48 AM, zhengjian zhang wrote: > hi, > > I'm doing to make llvm backend support sjlj-eh! I have try to > use the llvm-IR to generate the sjlj-eh code, > but I'm totally despair ! > my major problem is that llvm-ir , I mean exception instrinstics > are enough for codegen the sjlj-eh code? May I need to modify the > llvm-gcc ? > or someone can give some advice about llvm-backend 's support sjlj- > eh ? > Hi, I'm working on getting SJLJ exception handling working for ARM. What sort of sjlj exception handling are you looking to do? There's a bit of subtlety to getting things working. For example, do you want to use the standard library setjmp/longjmp functions for flow control, or do you want to replicate the GCC approach of builtins to do that? To be compatible with GCC code, the latter approach is necessary, and is what I'm working on. There's definitely more to it than the current intrinsics, which are there to support dwarf. SJLJ exceptions rely on runtime library functions to register and unregister call frames which require unwinding, so we need to modify LLVM to handle generating those calls. Most of the landing pad organization should transfer over with only a bit of tweaking. The type checking and catch selection needs to be compatible with what's passed from GCC generated code, so there's a bit of work to do there as well. -Jim From criswell at cs.uiuc.edu Tue May 5 11:42:32 2009 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 5 May 2009 11:42:32 -0500 Subject: [LLVMdev] A problem creating operands for a new IR instruction to the mailing list In-Reply-To: References: Message-ID: <4A006C78.60105@cs.uiuc.edu> seventh moon wrote: > [snip] > > So to say it simply, my question is, "How can I create a new Value*, which indicates > an immediate value, such as immediate value 5?" > I don't know much about LLVM's code generators, but if all you need is to create a Value * for an immediate constant, you might try using the ConstantInt::get() method (http://llvm.org/doxygen/classllvm_1_1ConstantInt.html#77cd822480bc78732c84a9619e49e14a). A ConstantInt is a subclass of Value, and you can use it to create constant integer values in the LLVM IR. -- John T. From gohman at apple.com Tue May 5 13:11:46 2009 From: gohman at apple.com (Dan Gohman) Date: Tue, 5 May 2009 11:11:46 -0700 Subject: [LLVMdev] [PATCH] Add support for accessing the FS segment register on X86 In-Reply-To: <295e750a0905041537q2b20ba3fu6d3566857af1c586@mail.gmail.com> References: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> <8B4C8F94-7641-4B84-B404-B3E4AD6C3BFA@apple.com> <295e750a0905041459t4bc3dbd8u962cfd1c51f2885e@mail.gmail.com> <295e750a0905041537q2b20ba3fu6d3566857af1c586@mail.gmail.com> Message-ID: <7BD4865F-5A3A-428E-B716-410B98BA8F84@apple.com> I ultimately don't object to this patch. I see now that thread_local is not fully supported on x86-64 in the JIT. As a theoretical question however, would that not provide the needed functionality? The JIT can easily get the address for variables declared in the LLVM IR. Also, be aware of PR3966. Dan On May 4, 2009, at 3:37 PM, Zoltan Varga wrote: > > Hi, > > If I'm writing a JIT, and want to access the TLS variables of the > app containing the JIT, I can't > use thread_local since that only works for variables declared in > LLVM IL and/or managed by > the ExecutionEngine. While this patch allows a JIT to generate the > TLS accesses itself, if > it knows the tls offset of the variable in question. > > Zoltan > > On Tue, May 5, 2009 at 12:16 AM, Dan Gohman wrote: > Hello, > > The preferred way to do TLS is to use the thread_local keyword. > There is x86-64 support for thread_local on ELF; if you need > it for other targets, I recommend looking at adapting it. > > Dan > > On May 4, 2009, at 2:59 PM, Zoltan Varga wrote: > > > Hi, > > > > Here is an updated version of the patch using address space 257. > > > > Zoltan > > > > On Mon, May 4, 2009 at 11:36 PM, Shantonu Sen > wrote: > > Maybe 257 would be better (or other unused), because of r70197, > > which gives special behavior for <256 > > > > Shantonu Sen > > ssen at apple.com > > > > Sent from my Mac Pro > > > > > > On May 4, 2009, at 2:28 PM, Zoltan Varga wrote: > > > > Hi, > > > > The attached patch adds support for accessing the FS segment > > register using address space 255, similarly to the way the GS > > segment register can be accessed. This is useful for generating TLS > > access code on amd64 for example. > > > > Zoltan > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sricketts at maxentric.com Tue May 5 13:15:09 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Tue, 5 May 2009 11:15:09 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <200905051002.04335.baldrick@free.fr> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <6d9073030905011820r41710abex31af8167bac20c2c@mail.gmail.com> <6d9073030905041039o5dc5b6cfr58791c5b4b1fc36b@mail.gmail.com> <200905051002.04335.baldrick@free.fr> Message-ID: <6d9073030905051115o5f5354a4i9858899383819036@mail.gmail.com> Thanks for the suggestions. It looks like Duncan's suggestion got me a step closer, but I still can't build llvm-gcc... On Tue, May 5, 2009 at 12:56 AM, Christian Sayer wrote: > did you try a simple > > $ ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ > CC=/pkg/bin/gcc-4.2.4/bin/gcc CXX=/pkg/bin/gcc-4.2.4/bin/g++ Tried that, same error. 2009/5/5 Duncan Sands : > how about: > > export PATH=/pkg/bin/:$PATH > ../llvm-2.5/configure --prefix=/pkg/bin/llvm/ > > instead? I did that, and then "make tools-only" -- which resulted in a successful build of llvm-2.5. Then I went to build llvm-gcc: ../llvm-gcc4.2-2.5.source/configure --prefix=/pkg/build/llvm/llvm-gcc/install --program-prefix=llvm- --enable-llvm=/pkg/build/llvm/llvm-obj/ --enable-languages=c,c++ make LLVM_VERSION_INFO=2.5 and I get this error (which, according to http://www.mail-archive.com/llvmbugs at cs.uiuc.edu/msg02575.html might mean I am using a bad version of gcc)... /pkg/build/llvm/llvm-gcc/obj/./gcc/xgcc -B/pkg/build/llvm/llvm-gcc/obj/./gcc/ -B/pkg/build/llvm/llvm-gcc/install/x86_64-unknown-linux-gnu/bin/ -B/pkg/build/llvm/llvm-gcc/install/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/build/llvm/llvm-gcc/install/x86_64-unknown-linux-gnu/include -isystem /pkg/build/llvm/llvm-gcc/install/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../llvm-gcc4.2-2.5.source/gcc -I../../llvm-gcc4.2-2.5.source/gcc/. -I../../llvm-gcc4.2-2.5.source/gcc/../include -I../../llvm-gcc4.2-2.5.source/gcc/../libcpp/include -I../../llvm-gcc4.2-2.5.source/gcc/../libdecnumber -I../libdecnumber -I/pkg/build/llvm/llvm-obj//include -I/pkg/build/llvm/llvm-2.5/include -DL_gcov -c ../../llvm-gcc4.2-2.5.source/gcc/libgcov.c -o libgcc/./_gcov.o cc1: /pkg/build/llvm/llvm-2.5/include/llvm/Transforms/Utils/InlineCost.h:44: llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost exceeds InlineCost precision"' failed. ../../llvm-gcc4.2-2.5.source/gcc/libgcov.c:644: internal compiler error: Aborted So I tried this config for llvm-gcc: $ ../llvm-gcc4.2-2.5.source/configure --prefix=/pkg/build/llvm/llvm-gcc/install --program-prefix=llvm- --enable-llvm=/pkg/build/llvm/llvm-obj/ --enable-languages=c,c++ CC=/pkg/bin/gcc-4.2.4/bin/gcc CXX=/pkg/bin/gcc-4.2.4/bin/g++ but got: configure: warning: CC=/pkg/bin/gcc-4.2.4/bin/gcc: invalid host type configure: warning: CXX=/pkg/bin/gcc-4.2.4/bin/g++: invalid host type configure: error: can only configure for one host and one target at a time How do I tell llvm-gcc config to use the right version of gcc? /pkg/bin/ is in my path thanks to the suggestion from Duncan. $ echo $PATH /pkg/bin/:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/user_homes/sricketts/bin From evan.cheng at apple.com Tue May 5 13:18:51 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Tue, 5 May 2009 11:18:51 -0700 Subject: [LLVMdev] [PATH] Fixes for the amd64 JIT code In-Reply-To: <98A26E3E-2CD5-47B7-A36D-E73C3A262DAF@apple.com> References: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> <01051155-8E3D-4D6B-BDAE-C6ADA590192B@apple.com> <23362528.post@talk.nabble.com> <98A26E3E-2CD5-47B7-A36D-E73C3A262DAF@apple.com> Message-ID: <86439649-E5C6-4F48-AD3D-33A7D0B56523@apple.com> Hi Zoltan, The part that determines whether SIB byte is needed caused a lot of regressions last night (see Geryon-X86-64 etc.). I've reverted it for now. Please take a look. Thanks, Evan On May 4, 2009, at 3:49 PM, Evan Cheng wrote: > Committed as revision 70929. Thanks. > > Evan > > On May 3, 2009, at 8:29 PM, vargaz wrote: > >> >> Hi, >> >> If this looks ok, could somebody check it in ? >> >> thanks >> >> Zoltan >> >> >> Evan Cheng-2 wrote: >>> >>> Looks good. Thanks. >>> >>> Evan >>> >>> On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: >>> >>>> Hi, >>>> >>>> The attached patch contains the following changes: >>>> >>>> * X86InstrInfo.cpp: Synchronize a few places with the code in >>>> X86CodeEmitter.cpp >>>> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it >>>> is not neeed. >>>> >>>> Zoltan >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> >> -- >> View this message in context: http://www.nabble.com/-PATH--Fixes-for-the-amd64-JIT-code-tp23335910p23362528.html >> Sent from the LLVM - Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From clattner at apple.com Tue May 5 13:53:03 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 5 May 2009 11:53:03 -0700 Subject: [LLVMdev] [PATCH] Add support for accessing the FS segment register on X86 In-Reply-To: <295e750a0905041459t4bc3dbd8u962cfd1c51f2885e@mail.gmail.com> References: <295e750a0905041428h47872ca7qe67e6b1350409c99@mail.gmail.com> <8B4C8F94-7641-4B84-B404-B3E4AD6C3BFA@apple.com> <295e750a0905041459t4bc3dbd8u962cfd1c51f2885e@mail.gmail.com> Message-ID: <416A61CA-5BC9-4D91-B613-B811AB02924D@apple.com> On May 4, 2009, at 2:59 PM, Zoltan Varga wrote: > Hi, > Here is an updated version of the patch using address space 257. Applied, thanks! http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090504/077147.html -Chris From clattner at apple.com Tue May 5 13:57:48 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 5 May 2009 11:57:48 -0700 Subject: [LLVMdev] [PATCH] GVN improvement In-Reply-To: References: Message-ID: On May 4, 2009, at 7:54 AM, Jakub Staszak wrote: > Hello, > > I've been analyzing GVN algorithm and I've found one place where it > could be easily improved. > Note that this is my first patch here. Please be tolerant ;) Hi Jakub, This is a very interesting patch. Does it handle the case when a occurs in an (unreachable) infinite loop? In this case, you'd end up walking up the single predecessor infinitely. Have you tested this on llvm-test at all? -Chris From samuraileumas at yahoo.com Tue May 5 14:06:26 2009 From: samuraileumas at yahoo.com (samuraileumas at yahoo.com) Date: Tue, 5 May 2009 12:06:26 -0700 (PDT) Subject: [LLVMdev] Calling C++ from LLVM Asm via JIT Message-ID: <180680.18714.qm@web62005.mail.re1.yahoo.com> Hello, I'm helping to write a parser generator that uses LLVM bitcode as its destination type.? Unlike most parser generators, it's written in C++ and is interpreted.? The "actions" defined in it are to be written in LLVM Assembly. In order to support symbol table lookups, there is a function call to a C++ library, saved as bitcode and loaded to a module at startup, that must be JITed while the parser generator parses.? The signature of all of these immediately executed actions is a boolean output indicating whether the lookup failed or not.? All other information handled by the subroutine is done via a global stack defined in the startup code. Does the name-mangling scheme of LLVM-GCC affect global functions in my library and can they be called without a C binding? If not, how hard is it to write a C binding for a C++ function? --Samuel Crow From baldrick at free.fr Tue May 5 14:26:58 2009 From: baldrick at free.fr (Duncan Sands) Date: Tue, 5 May 2009 21:26:58 +0200 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905051115o5f5354a4i9858899383819036@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905051002.04335.baldrick@free.fr> <6d9073030905051115o5f5354a4i9858899383819036@mail.gmail.com> Message-ID: <200905052126.59153.baldrick@free.fr> Hi, > cc1: /pkg/build/llvm/llvm-2.5/include/llvm/Transforms/Utils/InlineCost.h:44: > llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost > exceeds InlineCost precision"' failed. > ../../llvm-gcc4.2-2.5.source/gcc/libgcov.c:644: internal compiler error: Aborted this is indeed a miscompilation by your system compiler. However so many compilers miscompiled this that a workaround was committed to svn. So you may want to check out llvm and llvm-gcc from svn. Alternatively, maybe the patch applies to llvm 2.5 too. I've attached it. Ciao, Duncan. -------------- next part -------------- A non-text attachment was scrubbed... Name: r69515.diff Type: text/x-patch Size: 2685 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/9bd657ee/attachment.bin From vgrover528 at gmail.com Tue May 5 15:08:57 2009 From: vgrover528 at gmail.com (V Grover) Date: Tue, 5 May 2009 12:08:57 -0800 Subject: [LLVMdev] unable to schedule pass message Message-ID: <35657f570905051308p94ff9depde90770aa3e8334@mail.gmail.com> Hi, Sorry for the spam, but perhaps someone has seen this before and can answer. I am trying to add a new register allocator to my target, and would like to use the Strong Phi Elimination pass. I am doing the following in my allocator virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequiredID(MachineDominatorsID); AU.addRequiredID(StrongPHIEliminationID); // Eliminate PHI nodes AU.addRequired(); AU.addPreserved(); AU.addRequired(); AU.addPreserved(); MachineFunctionPass::getAnalysisUsage(AU); } but I get the following error at runtime Unable to schedule 'MachineDominator Tree Construction' required by 'Eliminate PHI nodes for register allocation, intelligently' .../VMCore/PassManager.cpp:1077: virtual void llvm::PMDataManager::addLowerLevelRequiredPass(llvm::Pass*, llvm::Pass*): Assertion `0 && "Unable to schedule pass"' failed. I was wondering if anyone know what might be the issue? Thanks Vinod -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/f807ec13/attachment.html From clattner at apple.com Tue May 5 15:10:19 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 5 May 2009 13:10:19 -0700 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <200905051131.04556.dag@cray.com> References: <200904301759.12384.dag@cray.com> <469F019E-7E04-41BC-BB11-12570A4BED0F@apple.com> <200905051131.04556.dag@cray.com> Message-ID: On May 5, 2009, at 9:31 AM, David Greene wrote: > On Tuesday 05 May 2009 01:02, Evan Cheng wrote: > >> I think it makes sense for isel to use HW cost (instruction latency, >> code size) as a late tie breaker. In that case, shouldn't cost be >> part >> of instruction itinerary? > > What latency? Each implementation has its own quirks and LLVM must be > flexible enough to handle them. So cost needs to be a function of > the CPU type as well as the instruction. For shuffles, I don't have a strong opinion. I just want dag combiner to be able to say "if these two shuffles have greater or equal cost to the equivalent combined shuffle, then merge the shuffles into one". It doesn't matter what units these are in. The other use is to break ties between multiple instructions that can match the same shuffle pattern. For these, the precise units also don't matter. Looking further ahead to a world where we have vectorization, we will need very precise cost models for various vector operands, scalar operations etc. I don't think it necessarily makes sense to overconstraint a solution for shuffles in the short term though. -Chris From sricketts at maxentric.com Tue May 5 15:24:18 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Tue, 5 May 2009 13:24:18 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <200905052126.59153.baldrick@free.fr> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905051002.04335.baldrick@free.fr> <6d9073030905051115o5f5354a4i9858899383819036@mail.gmail.com> <200905052126.59153.baldrick@free.fr> Message-ID: <6d9073030905051324w3c2d7f83s792e6584e175906f@mail.gmail.com> On Tue, May 5, 2009 at 12:26 PM, Duncan Sands wrote: > this is indeed a miscompilation by your system compiler. ?However so many > compilers miscompiled this that a workaround was committed to svn. ?So you > may want to check out llvm and llvm-gcc from svn. ?Alternatively, maybe > the patch applies to llvm 2.5 too. ?I've attached it. I will try the latest from svn... but quick follow up question: If it looks like a miscompilation by my system compiler (gcc 4.1.2), why wasn't gcc-4.2.4 used? Did I make a mistake in configuration? Maybe I am misunderstanding the build process. Scott From mrs at apple.com Tue May 5 15:51:02 2009 From: mrs at apple.com (Mike Stump) Date: Tue, 5 May 2009 13:51:02 -0700 Subject: [LLVMdev] Calling C++ from LLVM Asm via JIT In-Reply-To: <180680.18714.qm@web62005.mail.re1.yahoo.com> References: <180680.18714.qm@web62005.mail.re1.yahoo.com> Message-ID: <648051AD-D179-470C-9E59-BCB88526925E@apple.com> On May 5, 2009, at 12:06 PM, samuraileumas at yahoo.com wrote: > Does the name-mangling scheme of LLVM-GCC affect global functions in > my library Yes. > and can they be called without a C binding? Yes, if you want to write non-portable code. > If not, how hard is it to write a C binding for a C++ function? One line per function. If you know python, awk or perl, you can even generating the bindings, if you had to. From vargaz at gmail.com Tue May 5 16:17:01 2009 From: vargaz at gmail.com (Zoltan Varga) Date: Tue, 5 May 2009 23:17:01 +0200 Subject: [LLVMdev] [PATH] Fixes for the amd64 JIT code In-Reply-To: <86439649-E5C6-4F48-AD3D-33A7D0B56523@apple.com> References: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> <01051155-8E3D-4D6B-BDAE-C6ADA590192B@apple.com> <23362528.post@talk.nabble.com> <98A26E3E-2CD5-47B7-A36D-E73C3A262DAF@apple.com> <86439649-E5C6-4F48-AD3D-33A7D0B56523@apple.com> Message-ID: <295e750a0905051417p6690df13r4ae656e9ad74dbc4@mail.gmail.com> Hi, I can't reproduce these failures on my linux machine. The test machine seems to be running darwin. I suspect that the problem might be with RIP relative addressing, or with the encoding of R12/R13, but the code seems to handle the latter, since it checks for ESP/EBP which is the same as R12/R13. Zoltan On Tue, May 5, 2009 at 8:18 PM, Evan Cheng wrote: > Hi Zoltan, > > The part that determines whether SIB byte is needed caused a lot of > regressions last night (see Geryon-X86-64 etc.). I've reverted it for > now. Please take a look. > > Thanks, > > Evan > > On May 4, 2009, at 3:49 PM, Evan Cheng wrote: > > > Committed as revision 70929. Thanks. > > > > Evan > > > > On May 3, 2009, at 8:29 PM, vargaz wrote: > > > >> > >> Hi, > >> > >> If this looks ok, could somebody check it in ? > >> > >> thanks > >> > >> Zoltan > >> > >> > >> Evan Cheng-2 wrote: > >>> > >>> Looks good. Thanks. > >>> > >>> Evan > >>> > >>> On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: > >>> > >>>> Hi, > >>>> > >>>> The attached patch contains the following changes: > >>>> > >>>> * X86InstrInfo.cpp: Synchronize a few places with the code in > >>>> X86CodeEmitter.cpp > >>>> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it > >>>> is not neeed. > >>>> > >>>> Zoltan > >>>> _______________________________________________ > >>>> LLVM Developers mailing list > >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >>> > >>> > >> > >> -- > >> View this message in context: > http://www.nabble.com/-PATH--Fixes-for-the-amd64-JIT-code-tp23335910p23362528.html > >> Sent from the LLVM - Dev mailing list archive at Nabble.com. > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/0585c93e/attachment.html From vargaz at gmail.com Tue May 5 17:19:57 2009 From: vargaz at gmail.com (Zoltan Varga) Date: Wed, 6 May 2009 00:19:57 +0200 Subject: [LLVMdev] [PATH] Fixes for the amd64 JIT code In-Reply-To: <295e750a0905051417p6690df13r4ae656e9ad74dbc4@mail.gmail.com> References: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> <01051155-8E3D-4D6B-BDAE-C6ADA590192B@apple.com> <23362528.post@talk.nabble.com> <98A26E3E-2CD5-47B7-A36D-E73C3A262DAF@apple.com> <86439649-E5C6-4F48-AD3D-33A7D0B56523@apple.com> <295e750a0905051417p6690df13r4ae656e9ad74dbc4@mail.gmail.com> Message-ID: <295e750a0905051519q23b2c6c3je437fc200e037fe8@mail.gmail.com> Hi, It looks like the problem was with the RIP relative addressing. The original patch mistakenly removed the || DispForReloc part because I tough that the RIP relative addressing was done by the SIB encodings, but it is actually done by the shorter ones. The attached patch seems to work for me on linux and when simulating darwin by forcing some variables in X86TargetMachine.cpp to their darwin values. Zoltan On Tue, May 5, 2009 at 11:17 PM, Zoltan Varga wrote: > Hi, > > I can't reproduce these failures on my linux machine. The test machine > seems to be > running darwin. I suspect that the problem might be with RIP relative > addressing, or with > the encoding of R12/R13, but the code seems to handle the latter, since it > checks for > ESP/EBP which is the same as R12/R13. > > Zoltan > > > On Tue, May 5, 2009 at 8:18 PM, Evan Cheng wrote: > >> Hi Zoltan, >> >> The part that determines whether SIB byte is needed caused a lot of >> regressions last night (see Geryon-X86-64 etc.). I've reverted it for >> now. Please take a look. >> >> Thanks, >> >> Evan >> >> On May 4, 2009, at 3:49 PM, Evan Cheng wrote: >> >> > Committed as revision 70929. Thanks. >> > >> > Evan >> > >> > On May 3, 2009, at 8:29 PM, vargaz wrote: >> > >> >> >> >> Hi, >> >> >> >> If this looks ok, could somebody check it in ? >> >> >> >> thanks >> >> >> >> Zoltan >> >> >> >> >> >> Evan Cheng-2 wrote: >> >>> >> >>> Looks good. Thanks. >> >>> >> >>> Evan >> >>> >> >>> On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> The attached patch contains the following changes: >> >>>> >> >>>> * X86InstrInfo.cpp: Synchronize a few places with the code in >> >>>> X86CodeEmitter.cpp >> >>>> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it >> >>>> is not neeed. >> >>>> >> >>>> Zoltan >> >>>> _______________________________________________ >> >>>> LLVM Developers mailing list >> >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >>> >> >>> _______________________________________________ >> >>> LLVM Developers mailing list >> >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >>> >> >>> >> >> >> >> -- >> >> View this message in context: >> http://www.nabble.com/-PATH--Fixes-for-the-amd64-JIT-code-tp23335910p23362528.html >> >> Sent from the LLVM - Dev mailing list archive at Nabble.com. >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090506/c4f8b6d1/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: sib.diff Type: text/x-diff Size: 611 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090506/c4f8b6d1/attachment.bin From Micah.Villmow at amd.com Tue May 5 17:48:23 2009 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Tue, 5 May 2009 15:48:23 -0700 Subject: [LLVMdev] Pass to remove unused functions Message-ID: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> In order to handle a large vector based math library I link in a fairly large bitcode file that might or might not be needed. The problem is that linking in this bitcode file drastically increases the amount of compile time required. Is there a way to remove all functions that are not used after this linking pass? Something similar to die but removes functions from the compilation unit instead of instructions. Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/a77ac08b/attachment.html From clattner at apple.com Tue May 5 17:53:01 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 5 May 2009 15:53:01 -0700 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> Message-ID: On May 5, 2009, at 3:48 PM, Villmow, Micah wrote: > In order to handle a large vector based math library I link in a > fairly large bitcode file that might or might not be needed. The > problem is that linking in this bitcode file drastically increases > the amount of compile time required. Is there a way to remove all > functions that are not used after this linking pass? Something > similar to die but removes functions from the compilation unit > instead of instructions. > The -globaldce pass will remove dead internal globals and functions. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/7ab53052/attachment.html From Micah.Villmow at amd.com Tue May 5 18:07:38 2009 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Tue, 5 May 2009 16:07:38 -0700 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> Message-ID: <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> I thought this pass would do it, but when I run it over my bc file the output file is the same as the input file. The issue I guess is a little different. When I link in the huge bc file with the tiny bc file, I only want the resulting bc file to have the function definitions that the tiny bc file requires and not every function in the huge bc file. Any idea's how to do this with the current llvm toolset? Thanks, Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, May 05, 2009 3:53 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Pass to remove unused functions On May 5, 2009, at 3:48 PM, Villmow, Micah wrote: In order to handle a large vector based math library I link in a fairly large bitcode file that might or might not be needed. The problem is that linking in this bitcode file drastically increases the amount of compile time required. Is there a way to remove all functions that are not used after this linking pass? Something similar to die but removes functions from the compilation unit instead of instructions. The -globaldce pass will remove dead internal globals and functions. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/8958fb71/attachment.html From clattner at apple.com Tue May 5 18:15:42 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 5 May 2009 16:15:42 -0700 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> Message-ID: On May 5, 2009, at 4:07 PM, Villmow, Micah wrote: > I thought this pass would do it, but when I run it over my bc file > the output file is the same as the input file. that's probably because your symbols are not internal. > > The issue I guess is a little different. When I link in the huge bc > file with the tiny bc file, I only want the resulting bc file to > have the function definitions that the tiny bc file requires and not > every function in the huge bc file. > > Any idea?s how to do this with the current llvm toolset? You have to roll your own using the lower level APIs. You can move functions between modules etc. Alternatively, you can link the two modules and mark the functions you don't want as internal, then use globaldce. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/720877dd/attachment-0001.html From Micah.Villmow at amd.com Tue May 5 18:50:22 2009 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Tue, 5 May 2009 16:50:22 -0700 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com><493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> Message-ID: <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> Is there a way to mark all functions as internal from source via some sort of attribute? Thanks for the tips, Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, May 05, 2009 4:16 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Pass to remove unused functions On May 5, 2009, at 4:07 PM, Villmow, Micah wrote: I thought this pass would do it, but when I run it over my bc file the output file is the same as the input file. that's probably because your symbols are not internal. The issue I guess is a little different. When I link in the huge bc file with the tiny bc file, I only want the resulting bc file to have the function definitions that the tiny bc file requires and not every function in the huge bc file. Any idea's how to do this with the current llvm toolset? You have to roll your own using the lower level APIs. You can move functions between modules etc. Alternatively, you can link the two modules and mark the functions you don't want as internal, then use globaldce. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/c213f6d6/attachment.html From zhangzhengjian at gmail.com Tue May 5 20:16:02 2009 From: zhangzhengjian at gmail.com (zhengjian zhang) Date: Wed, 6 May 2009 09:16:02 +0800 Subject: [LLVMdev] SJLJ EH Message-ID: <8e3538210905051816s2af750b4m2cd1ee88e3bf4aae@mail.gmail.com> Hi, >There's definitely more to it than the current intrinsics, which are >there to support dwarf. that's to say we need modify the llvm-gcc so the front end can generate the sjlj-style IR, >SJLJ exceptions rely on runtime library >functions to register and unregister call frames which require >unwinding, so we need to modify LLVM to handle generating those call my approach : when the user use the option, e.g -enable-sjlj-eh, I will build the register and unregister, and other handle sjlj-eh calls, at my target side. yeah, that's a ugly method, because I didn't touch the llvm-gcc >Most of the landing pad organization should transfer over with only a >bit of tweaking. The type checking and catch selection needs to be >compatible with what's passed from GCC generated code, so there's a >bit of work to do there as well. because of my above ugly approach! now that's very difficult for me to generate the right exception table! From clattner at apple.com Tue May 5 21:47:09 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 5 May 2009 19:47:09 -0700 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> Message-ID: On May 5, 2009, at 4:50 PM, Villmow, Micah wrote: > Is there a way to mark all functions as internal from source via > some sort of attribute? "static". However, if you do that, they won't make it into the bc file. -Chris > > Thanks for the tips, > Micah > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of Chris Lattner > Sent: Tuesday, May 05, 2009 4:16 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Pass to remove unused functions > > > On May 5, 2009, at 4:07 PM, Villmow, Micah wrote: > > > I thought this pass would do it, but when I run it over my bc file > the output file is the same as the input file. > > that's probably because your symbols are not internal. > > > > The issue I guess is a little different. When I link in the huge bc > file with the tiny bc file, I only want the resulting bc file to > have the function definitions that the tiny bc file requires and not > every function in the huge bc file. > > Any idea?s how to do this with the current llvm toolset? > > You have to roll your own using the lower level APIs. You can move > functions between modules etc. Alternatively, you can link the two > modules and mark the functions you don't want as internal, then use > globaldce. > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090505/c537b210/attachment.html From viridia at gmail.com Tue May 5 22:09:27 2009 From: viridia at gmail.com (Talin) Date: Tue, 05 May 2009 20:09:27 -0700 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> Message-ID: <4A00FF67.4090500@gmail.com> I wanted to mention, by the way, that my need/desire for this hasn't gone away :) And my wish list still includes support for something like uintptr_t - a primitive integer type that is defined to always be the same size as a pointer, however large or small that may be on different platforms. (So that the frontend doesn't need to know how big a pointer is and can generate the same IR that works on both 32-bit and 64-bit platforms.) -- Talin Chris Lattner wrote: > On Dec 30, 2008, at 12:41 PM, Talin wrote: > >> I've been thinking about how to represent unions or "disjoint types" >> in LLVM IR. At the moment, the only way I know to achieve this right >> now is to create a struct that is as large as the largest type in >> the union and then bitcast it to access the fields contained within. >> However, that requires that the frontend know the sizes of all of >> the various low-level types (the "size_t" problem, which has been >> discussed before), otherwise you get problems trying to mix pointer >> and non-pointer types. >> > > That's an interesting point. As others have pointed out, we've > resisted having a union type because it isn't strictly needed for the > current set of front-ends. If a front-end is trying to generate > target-independent IR though, I can see the utility. The "gep trick" > won't work for type generation. > > >> It seems to me that adding a union type to the IR would be a logical >> extension to the language. The syntax for declaring a union would be >> similar to that of declaring a struct. To access a union member, you >> would use GetElementPointer, just as if it were a struct. The only >> difference is that in this case, the GEP doesn't actually modify the >> address, it merely returns the input argument as a different type. >> In all other ways, unions would be treated like structs, except that >> the size of the union would always be the size of the largest >> member, and all of the fields within the union would be located >> located at relative offset zero. >> > > Yes, your proposal makes sense, for syntax, I'd suggest: u{ i32, float} > > >> Unions could of course be combined with other types: >> >> {{int|float}, bool} * >> n = getelementptr i32 0, i32 0, i32 1 >> >> So in the above example, the GEP returns a pointer to the float field. >> > > I don't have a specific problem with adding this. The cost of doing > so is that it adds (a small amount of) complexity to a lot of places > that walk the type graphs. The only pass that I predict will be > difficult to update to handle this is the BasicAA pass, which reasons > about symbolic (not concrete) offsets and should return mustalias in > the appropriate cases. Also, to validate this, I think llvm-gcc > should start generating this for C unions where possible. > > If you're interested in implementing this and seeing all the details > of the implementation through to the end, I don't see significant > problems. I think adding a simple union type would make more sense > than adding first-class support for a *discriminated* union. > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From clattner at apple.com Tue May 5 22:56:21 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 5 May 2009 20:56:21 -0700 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <4A00FF67.4090500@gmail.com> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> <4A00FF67.4090500@gmail.com> Message-ID: <0B6805BD-85B8-460F-B35C-8656D26C01A2@apple.com> On May 5, 2009, at 8:09 PM, Talin wrote: > I wanted to mention, by the way, that my need/desire for this hasn't > gone away :) > > And my wish list still includes support for something like uintptr_t > - a > primitive integer type that is defined to always be the same size as a > pointer, however large or small that may be on different platforms. > (So > that the frontend doesn't need to know how big a pointer is and can > generate the same IR that works on both 32-bit and 64-bit platforms.) Why not just use a pointer, such as i8*? -Chris > > > -- Talin > > Chris Lattner wrote: >> On Dec 30, 2008, at 12:41 PM, Talin wrote: >> >>> I've been thinking about how to represent unions or "disjoint types" >>> in LLVM IR. At the moment, the only way I know to achieve this right >>> now is to create a struct that is as large as the largest type in >>> the union and then bitcast it to access the fields contained within. >>> However, that requires that the frontend know the sizes of all of >>> the various low-level types (the "size_t" problem, which has been >>> discussed before), otherwise you get problems trying to mix pointer >>> and non-pointer types. >>> >> >> That's an interesting point. As others have pointed out, we've >> resisted having a union type because it isn't strictly needed for the >> current set of front-ends. If a front-end is trying to generate >> target-independent IR though, I can see the utility. The "gep trick" >> won't work for type generation. >> >> >>> It seems to me that adding a union type to the IR would be a logical >>> extension to the language. The syntax for declaring a union would be >>> similar to that of declaring a struct. To access a union member, you >>> would use GetElementPointer, just as if it were a struct. The only >>> difference is that in this case, the GEP doesn't actually modify the >>> address, it merely returns the input argument as a different type. >>> In all other ways, unions would be treated like structs, except that >>> the size of the union would always be the size of the largest >>> member, and all of the fields within the union would be located >>> located at relative offset zero. >>> >> >> Yes, your proposal makes sense, for syntax, I'd suggest: u{ i32, >> float} >> >> >>> Unions could of course be combined with other types: >>> >>> {{int|float}, bool} * >>> n = getelementptr i32 0, i32 0, i32 1 >>> >>> So in the above example, the GEP returns a pointer to the float >>> field. >>> >> >> I don't have a specific problem with adding this. The cost of doing >> so is that it adds (a small amount of) complexity to a lot of places >> that walk the type graphs. The only pass that I predict will be >> difficult to update to handle this is the BasicAA pass, which reasons >> about symbolic (not concrete) offsets and should return mustalias in >> the appropriate cases. Also, to validate this, I think llvm-gcc >> should start generating this for C unions where possible. >> >> If you're interested in implementing this and seeing all the details >> of the implementation through to the end, I don't see significant >> problems. I think adding a simple union type would make more sense >> than adding first-class support for a *discriminated* union. >> >> -Chris >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From suigintou_ at hotmail.com Tue May 5 22:59:11 2009 From: suigintou_ at hotmail.com (seventh moon) Date: Wed, 6 May 2009 11:59:11 +0800 Subject: [LLVMdev] A problem creating operands for a new IR instruction to the mailing list In-Reply-To: <549cee610905050707v3f2b546ey5ede6980a3a81002@mail.gmail.com> References: <549cee610905050707v3f2b546ey5ede6980a3a81002@mail.gmail.com> Message-ID: Thank you for your answer. But there is still a problem. You seem correct about how to define a constant operand. So I added it into my code, like so: Builder.SetInsertPoint(LLVMBB, I); Constant *C = ConstantInt::get(APInt(32, 5, false)); Instruction *newI=Builder.CreateLoad(C,""); It compiles. But it still aborts at runtime with a complaint that the type is not right. This leads me to think that immediate loads are not generated with the CreateLoad instruction? Another person's reply to my question indicated that a way to avoid inserting the immediate load entirely; but that is also not what I want, because my explicit purpose in inserting this load is to claim a register. Thank you, Kao Chang Date: Tue, 5 May 2009 16:07:33 +0200 From: meurant.olivier at gmail.com To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] A problem creating operands for a new IR instruction to the mailing list If you want an immediate constant value, ConstantInt::get(APInt(32, 5, false)) will perhaps help you ? Olivier. 2009/5/5 seventh moon I have a question about inserting instructions into the LLVM IR. I can insert instructions, but my operands do not have the right type, so it fails an assertion at runtime. I am trying to insert an immediate load instructions, as a means of claiming a new register. Here is what I do: Builder.SetInsertPoint(LLVMBB, I); // The following line looks to me like it would have a chance o! f loading either // address 5, or else immediate value 5. Unfortunately, it does neither. It compiles // but crashes at runtime, that the type of the operand is incompatible Instruction *newI=Builder.CreateLoad(5,""); // I also tested this, just to do a little sanity check. It also compiles then // crashes, for the obvious reason that the operand is a register, but an address // or an immediate value is expected. //Instruction *newI=Builder.CreateLoad(I->getOperand(1),""); // also wrong So to say it simply, my question is, "How can I create a new Value*, which indicates an immediate value, such as immediate value 5?" Thank you for your assistance, Kao Chang ?????????????????B?v???B?????p?u???M???R?M???A?????q?X! ?A???v ?X Windows Live Spaces _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev _________________________________________________________________ ?H???? Windows Live Messenger ?M Hotmail?A???????a?x?????T???b???? ?X Windows Live for Mobile http://3c.msn.com.tw/mobile/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090506/3a96d73d/attachment.html From jyasskin at google.com Tue May 5 23:18:05 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Tue, 5 May 2009 21:18:05 -0700 Subject: [LLVMdev] A problem creating operands for a new IR instruction to the mailing list In-Reply-To: References: <549cee610905050707v3f2b546ey5ede6980a3a81002@mail.gmail.com> Message-ID: 2009/5/5 seventh moon : > Thank you for your answer.? But there is still a problem. > > You seem correct about how to define a constant operand.? So I added it into > my code, like so: > ?? ? ? Builder.SetInsertPoint(LLVMBB, I); > ? ? ?? Constant *C = ConstantInt::get(APInt(32, 5, false)); > ??????? Instruction *newI=Builder.Create! Load(C,""); > > It compiles. But it still aborts at runtime with a complaint that the type > is not right. > This leads me to think that immediate loads are not generated with the > CreateLoad > instruction? Correct. Immediates are already Value*s in LLVM IR; you don't have to load them. You may want to read http://llvm.org/docs/LangRef.html for descriptions of the instructions and the arguments they take. And http://llvm.org/docs/ProgrammersManual.html#Value for a description of the Value class. > Another person's reply to my question indicated that a way to avoid > inserting the > immediate load entirely; but that is also not what I want, because my > explicit purpose > in inserting this load is to claim a register. I'd bet that's not actually your purpose. Why do you think you need to claim a register? Note that LLVM pseudo-registers (the things Instructions define) are not at all the same as machine registers. If you really want an Instruction, you can bitcast the constant to its original type. So: new BitCastInst(ConstantInt::get(Type::Int32Ty, 5), Type::Int32Ty, I); Don't use the IRBuilder to create the BitCast because it'll constant-fold it into a ConstantExpr, which isn't an Instruction. Jeffrey From jyasskin at google.com Tue May 5 23:34:20 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Tue, 5 May 2009 21:34:20 -0700 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> Message-ID: On Tue, May 5, 2009 at 7:47 PM, Chris Lattner wrote: > > On May 5, 2009, at 4:50 PM, Villmow, Micah wrote: > > > Is there a way to mark all functions as internal from source via some sort > > of attribute? > > "static". ?However, if you do that, they won't make it into the bc file. > -Chris A flag to force them into the .bc file would be a nice feature for clang. Unfortunately, I don't expect it to be urgent enough for me to submit a patch any time soon. From viridia at gmail.com Tue May 5 23:55:30 2009 From: viridia at gmail.com (Talin) Date: Tue, 05 May 2009 21:55:30 -0700 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <0B6805BD-85B8-460F-B35C-8656D26C01A2@apple.com> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> <4A00FF67.4090500@gmail.com> <0B6805BD-85B8-460F-B35C-8656D26C01A2@apple.com> Message-ID: <4A011842.3030702@gmail.com> Chris Lattner wrote: > On May 5, 2009, at 8:09 PM, Talin wrote: > > >> I wanted to mention, by the way, that my need/desire for this hasn't >> gone away :) >> >> And my wish list still includes support for something like uintptr_t >> - a >> primitive integer type that is defined to always be the same size as a >> pointer, however large or small that may be on different platforms. >> (So >> that the frontend doesn't need to know how big a pointer is and can >> generate the same IR that works on both 32-bit and 64-bit platforms.) >> > > Why not just use a pointer, such as i8*? > Suppose I have an STL-like container that has a 'begin' and 'end' pointer. Now I want to find the size() of the container. Since you cannot subtract pointers in LLVM IR, you have to cast them to an integer type first. But what integer type do you cast them to? I suppose you could simply always cast them to i64, and hope that the backend will generate efficient code for the subtraction, but I have no way of knowing this. Now, I'm going to anticipate what I think will be your next argument, which is that at some point I must know the size of the result since I am assigning the result of size() to some interger variable eventually. Which is true, however, if the size of that eventual variable is smaller than a pointer, then I want to check it for overflow before I do the assignment. I don't want to just do a blind bitcast and have the top bits be lopped off. The problem of checking for overflow when assigning from an integer of unknown size to an integer of known size is left as an exercise for the reader. > -Chris > From clattner at apple.com Wed May 6 00:17:03 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 5 May 2009 22:17:03 -0700 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> Message-ID: <02C6FA15-05D4-482A-92B8-00B6C126DA29@apple.com> On May 5, 2009, at 9:34 PM, Jeffrey Yasskin wrote: >> "static". However, if you do that, they won't make it into the bc >> file. >> -Chris > > A flag to force them into the .bc file would be a nice feature for > clang. Unfortunately, I don't expect it to be urgent enough for me to > submit a patch any time soon. You can get that by marking them attribute(used), but then globaldce won't strip them. Perhaps the best option is to use the internalize pass, which marks a set of functions internal. -Chris From keveman at gmail.com Wed May 6 00:23:13 2009 From: keveman at gmail.com (Manjunath Kudlur) Date: Tue, 5 May 2009 22:23:13 -0700 Subject: [LLVMdev] Question on tablegen Message-ID: <68c4c3e20905052223v3143f7b7u892de3e156f87f9c@mail.gmail.com> Hello, I am trying to create a machine instruction for "extractelement". I want to translate r <- extractelement v, 0 to mov r, v.x I was looking at the dag I can use and I found vector_extract. The inputs for this SDnode are a register and a iPtr constant. With that, I need to create 4 separate def's to extract element 0, 1, 2, and 3 and translate to v.x, v.y, v.z, and v.w. I was wondering if I can use the dag's 2nd input as an index into a list of strings and form the assembly instruction, something like !strconcat("mov $dst, v.", elemnames[$input]). I am still trying to learn the tablegen syntax and semantics, so how to do this is not clear to me. I will appreciate any suggestions on how to do this, or pointers to other places where similar things are done. Thanks, Manjunath From baldrick at free.fr Wed May 6 01:33:20 2009 From: baldrick at free.fr (Duncan Sands) Date: Wed, 6 May 2009 08:33:20 +0200 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905051324w3c2d7f83s792e6584e175906f@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905052126.59153.baldrick@free.fr> <6d9073030905051324w3c2d7f83s792e6584e175906f@mail.gmail.com> Message-ID: <200905060833.21433.baldrick@free.fr> Hi Scott, > On Tue, May 5, 2009 at 12:26 PM, Duncan Sands wrote: > > this is indeed a miscompilation by your system compiler. However so many > > compilers miscompiled this that a workaround was committed to svn. So you > > may want to check out llvm and llvm-gcc from svn. Alternatively, maybe > > the patch applies to llvm 2.5 too. I've attached it. > > I will try the latest from svn... but quick follow up question: If it > looks like a miscompilation by my system compiler (gcc 4.1.2), why > wasn't gcc-4.2.4 used? Did I make a mistake in configuration? Maybe I > am misunderstanding the build process. some versions of gcc 4.2 also miscompile this on 64 bit platforms... By the way, I attached the wrong patch. Try this new one instead! Ciao, Duncan. -------------- next part -------------- A non-text attachment was scrubbed... Name: r69597.diff Type: text/x-patch Size: 2384 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090506/08234f6a/attachment.bin From meurant.olivier at gmail.com Wed May 6 02:15:06 2009 From: meurant.olivier at gmail.com (Olivier Meurant) Date: Wed, 6 May 2009 09:15:06 +0200 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <4A011842.3030702@gmail.com> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> <4A00FF67.4090500@gmail.com> <0B6805BD-85B8-460F-B35C-8656D26C01A2@apple.com> <4A011842.3030702@gmail.com> Message-ID: <549cee610905060015s52a06af6me91c104cf461c4d7@mail.gmail.com> The TargetData class gives you the size of the pointer. (getPointerSize and getPointerSizeInBits). Can it help you ? On Wed, May 6, 2009 at 6:55 AM, Talin wrote: > Chris Lattner wrote: > > On May 5, 2009, at 8:09 PM, Talin wrote: > > > > > >> I wanted to mention, by the way, that my need/desire for this hasn't > >> gone away :) > >> > >> And my wish list still includes support for something like uintptr_t > >> - a > >> primitive integer type that is defined to always be the same size as a > >> pointer, however large or small that may be on different platforms. > >> (So > >> that the frontend doesn't need to know how big a pointer is and can > >> generate the same IR that works on both 32-bit and 64-bit platforms.) > >> > > > > Why not just use a pointer, such as i8*? > > > Suppose I have an STL-like container that has a 'begin' and 'end' > pointer. Now I want to find the size() of the container. Since you > cannot subtract pointers in LLVM IR, you have to cast them to an integer > type first. But what integer type do you cast them to? I suppose you > could simply always cast them to i64, and hope that the backend will > generate efficient code for the subtraction, but I have no way of > knowing this. > > Now, I'm going to anticipate what I think will be your next argument, > which is that at some point I must know the size of the result since I > am assigning the result of size() to some interger variable eventually. > Which is true, however, if the size of that eventual variable is smaller > than a pointer, then I want to check it for overflow before I do the > assignment. I don't want to just do a blind bitcast and have the top > bits be lopped off. > > The problem of checking for overflow when assigning from an integer of > unknown size to an integer of known size is left as an exercise for the > reader. > > -Chris > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090506/6db3c5cf/attachment.html From ChristophErhardt at gmx.de Wed May 6 03:58:06 2009 From: ChristophErhardt at gmx.de (Christoph Erhardt) Date: Wed, 06 May 2009 10:58:06 +0200 Subject: [LLVMdev] Pointer vs. integer: backend troubles Message-ID: <4A01511E.6060703@gmx.de> Hi everyone, I am currently working on a backend for the TriCore architecture. Unfortunately, I have hit an issue with LLVM's internal representation that's giving me a bit of a headache. The problem is that LLVM assumes that a pointer is equivalent to a machine-word sized integer. This implies that all pointer arithmetic takes place in the CPU's general-purpose registers and is done with the "regular" integer instructions. Unfortunately, this does not hold true for the TriCore architecture, which strictly differentiates between "normal" integer values and pointer values. The register set is split into two subsets: 16 general-purpose registers %d0..%d15 for 32-bit integers and floats, and 16 address registers %a0..%a15 for 32-bit pointers, with separate instructions. Moreover, the ABI requires that pointer arguments to (and pointer results from) functions be passed in address registers instead of general-purpose registers. As LLVM internally converts all pointers to integers (in my case i32), there is no way for a backend to tell whether an i32 operand is really an integer or actually a pointer. Thus neither the instruction selection nor the CallingConvention stuff works for me as expected. It does not seem possible to solve this problem without modifying at least some of the original LLVM source code. So what would be the easiest (and least invasive) way to achieve this? I have thought about adding a new ValueType (say, "p32") and overriding TargetLowering::getPointerTy() to return that new type instead of i32. Of course, this would probably be more of a dirty hack than an actual solution, but hopefully would do the trick - provided I'm not missing something... Comments and suggestions are highly welcome. Thank you for your time! Christoph From zhangzhengjian at gmail.com Wed May 6 05:02:53 2009 From: zhangzhengjian at gmail.com (zhengjian zhang) Date: Wed, 6 May 2009 18:02:53 +0800 Subject: [LLVMdev] SJLJ EH In-Reply-To: <8e3538210905051816s2af750b4m2cd1ee88e3bf4aae@mail.gmail.com> References: <8e3538210905051816s2af750b4m2cd1ee88e3bf4aae@mail.gmail.com> Message-ID: <8e3538210905060302v6681f0b3m3f7c07dadef48479@mail.gmail.com> Hi, >There's definitely more to it than the current intrinsics, which are >there to support dwarf. from the exist llvm-ir it seems there are some common info for sjlj-eh and dwarf-eh! are there possible use the exist llvm-ir to generate exception table for sjlj-eh ? zhangzw From anton at korobeynikov.info Wed May 6 06:46:06 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 6 May 2009 15:46:06 +0400 Subject: [LLVMdev] SJLJ EH In-Reply-To: <8e3538210905060302v6681f0b3m3f7c07dadef48479@mail.gmail.com> References: <8e3538210905051816s2af750b4m2cd1ee88e3bf4aae@mail.gmail.com> <8e3538210905060302v6681f0b3m3f7c07dadef48479@mail.gmail.com> Message-ID: Hello, > from the exist llvm-ir it seems there are some common info for sjlj-eh > and dwarf-eh! > are there possible use the exist llvm-ir to generate exception table > for sjlj-eh ? No. There should be support from llvm-gcc. sjlj eh and dwarf eh have different semantics -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From etherzhhb at gmail.com Wed May 6 07:25:29 2009 From: etherzhhb at gmail.com (ether zhhb) Date: Wed, 6 May 2009 20:25:29 +0800 Subject: [LLVMdev] Pointer vs. integer: backend troubles In-Reply-To: <4A01511E.6060703@gmx.de> References: <4A01511E.6060703@gmx.de> Message-ID: <5f72161f0905060525p64c0b938k74fdcf0cdb8fe7c7@mail.gmail.com> what about adding some annotations to the i32 Value which representing a pointer or annotate the "i32" type of that pointer? From jyasskin at google.com Wed May 6 10:18:35 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Wed, 6 May 2009 08:18:35 -0700 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <4A011842.3030702@gmail.com> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> <4A00FF67.4090500@gmail.com> <0B6805BD-85B8-460F-B35C-8656D26C01A2@apple.com> <4A011842.3030702@gmail.com> Message-ID: On Tue, May 5, 2009 at 9:55 PM, Talin wrote: > Chris Lattner wrote: >> On May 5, 2009, at 8:09 PM, Talin wrote: >> >> >>> I wanted to mention, by the way, that my need/desire for this hasn't >>> gone away :) >>> >>> And my wish list still includes support for something like uintptr_t >>> - a >>> primitive integer type that is defined to always be the same size as a >>> pointer, however large or small that may be on different platforms. >>> (So >>> that the frontend doesn't need to know how big a pointer is and can >>> generate the same IR that works on both 32-bit and 64-bit platforms.) >>> >> >> Why not just use a pointer, such as i8*? >> > Suppose I have an STL-like container that has a 'begin' and 'end' > pointer. Now I want to find the size() of the container. Since you > cannot subtract pointers in LLVM IR, you have to cast them to an integer > type first. But what integer type do you cast them to? I suppose you > could simply always cast them to i64, and hope that the backend will > generate efficient code for the subtraction, but I have no way of > knowing this. OT, and I don't have any deep insights, but: Nick and I recently added IRBuilder::CreatePtrDiff() to do this subtraction for you. It returns an i64. I believe the target-aware optimization passes keep track of which bits may be set in any integer, which would let them generate efficient code for the subtraction, but I don't know exactly which optimizations would do that. You can, of course, check an i64 for overflow when casting to i16, or whatever, and I'd hope the bit-aware optimizations would convert the overflow check to 'false' if you weren't actually truncating. > Now, I'm going to anticipate what I think will be your next argument, > which is that at some point I must know the size of the result since I > am assigning the result of size() to some interger variable eventually. > Which is true, however, if the size of that eventual variable is smaller > than a pointer, then I want to check it for overflow before I do the > assignment. I don't want to just do a blind bitcast and have the top > bits be lopped off. > > The problem of checking for overflow when assigning from an integer of > unknown size to an integer of known size is left as an exercise for the > reader. >> -Chris From gohman at apple.com Wed May 6 11:18:03 2009 From: gohman at apple.com (Dan Gohman) Date: Wed, 6 May 2009 09:18:03 -0700 Subject: [LLVMdev] Pointer vs. integer: backend troubles In-Reply-To: <4A01511E.6060703@gmx.de> References: <4A01511E.6060703@gmx.de> Message-ID: <9663FACB-5368-4459-B923-9A1EC241D163@apple.com> On May 6, 2009, at 1:58 AM, Christoph Erhardt wrote: > Hi everyone, > > I am currently working on a backend for the TriCore architecture. > Unfortunately, I have hit an issue with LLVM's internal representation > that's giving me a bit of a headache. > > The problem is that LLVM assumes that a pointer is equivalent to a > machine-word sized integer. This implies that all pointer arithmetic > takes place in the CPU's general-purpose registers and is done with > the > "regular" integer instructions. > Unfortunately, this does not hold true for the TriCore architecture, > which strictly differentiates between "normal" integer values and > pointer values. The register set is split into two subsets: 16 > general-purpose registers %d0..%d15 for 32-bit integers and floats, > and > 16 address registers %a0..%a15 for 32-bit pointers, with separate > instructions. Moreover, the ABI requires that pointer arguments to > (and > pointer results from) functions be passed in address registers instead > of general-purpose registers. > > As LLVM internally converts all pointers to integers (in my case i32), > there is no way for a backend to tell whether an i32 operand is really > an integer or actually a pointer. Thus neither the instruction > selection > nor the CallingConvention stuff works for me as expected. Your architecture poses some significant challenges for LLVM. Tackling them sounds possible, though it'll take some work. I'm working on a patch which changes the way function arguments and return values are lowered: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-April/021908.html (To everyone who gave me feedback, thanks! I'm working on an updated patch.) The current patch doesn't solve your problem immediately, but one of the suggestions I got was that the argument and return value records should carry information about what the original type of the value was. This is needed for example on targets where i64 is not a legal type, but it still needs to be passed differently from two i32 values. I was originally thinking of just including the original MVT type, but it could be changed to the LLVM IR Type*, to provide even more information. I hope to find time to post an updated version of this patch soon, though I don't know if it'll go into LLVM 2.6 or if it'll wait for 2.7. Beyond the ABI requirements, LLVM treats pointers and integers fairly interchangeably in the optimizer as well as codegen. This isn't specific to LLVM either; there are a lot of cases where integer arithmetic is used to perfom an index calculation, so the decision of which instructions to use depends on the context. I've seen other compilers make these decisions around register allocation time with a fair amount of success. This is an area which LLVM hasn't explored much, though I know there are a few people on this list who are working on targets with similar requirements. > > > It does not seem possible to solve this problem without modifying at > least some of the original LLVM source code. So what would be the > easiest (and least invasive) way to achieve this? FWIW, everyone I know working on backends that care about quality of generated code ends up needing to do work in target-independent code. Dan From gohman at apple.com Wed May 6 12:10:24 2009 From: gohman at apple.com (Dan Gohman) Date: Wed, 6 May 2009 10:10:24 -0700 Subject: [LLVMdev] Question on tablegen In-Reply-To: <68c4c3e20905052223v3143f7b7u892de3e156f87f9c@mail.gmail.com> References: <68c4c3e20905052223v3143f7b7u892de3e156f87f9c@mail.gmail.com> Message-ID: <14072311-B382-463F-92BB-73DDC8E57F0C@apple.com> One way to do this is to handle this in the AsmPrinter, with operand modifiers. For example, on x86 there are instructions with ${dst:call} in their asm string. The "call" part is interpreted as an operand modifier. The assembly printer looks for the "call" modifier on MachineOperand::MO_Immediate operands (in X86ATTAsmPrinter::printOperand), which lets it perform custom printing for that type of operand. You could use a modifier which tells the AsmPrinter to print an immediate as the appropriate letter. Dan On May 5, 2009, at 10:23 PM, Manjunath Kudlur wrote: > Hello, > > I am trying to create a machine instruction for "extractelement". I > want to translate > r <- extractelement v, 0 > to > mov r, v.x > > I was looking at the dag I can use and I found vector_extract. The > inputs for this SDnode are a register and a iPtr constant. With that, > I need to create 4 separate def's to extract element 0, 1, 2, and 3 > and translate to v.x, v.y, v.z, and v.w. I was wondering if I can use > the dag's 2nd input as an index into a list of strings and form the > assembly instruction, something like !strconcat("mov $dst, v.", > elemnames[$input]). I am still trying to learn the tablegen syntax and > semantics, so how to do this is not clear to me. I will appreciate any > suggestions on how to do this, or pointers to other places where > similar things are done. > > Thanks, > Manjunath > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From stoklund at 2pi.dk Wed May 6 12:47:26 2009 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Wed, 6 May 2009 19:47:26 +0200 Subject: [LLVMdev] Pointer vs. integer: backend troubles In-Reply-To: <4A01511E.6060703@gmx.de> References: <4A01511E.6060703@gmx.de> Message-ID: <4B0230DD-D011-42DE-AA0C-5482BE236140@2pi.dk> On 06/05/2009, at 10.58, Christoph Erhardt wrote: [...] > Unfortunately, this does not hold true for the TriCore architecture, > which strictly differentiates between "normal" integer values and > pointer values. The register set is split into two subsets: 16 > general-purpose registers %d0..%d15 for 32-bit integers and floats, > and > 16 address registers %a0..%a15 for 32-bit pointers, with separate > instructions. Hi Christoph, I am working on a back end for the blackfin DSP. It also has two register sets: data and pointers, so the architectures are similar. I am using a lot of register classes to represent the many instruction constraints. The code generator support for weird register classes has improved a lot recently. The instruction selector does not know about register classes - it only uses value types when pattern matching. That is probably a good idea; it can be hard to tell what is a pointer and what is an integer beforehand. After instruction selection is complete, each virtual register is assigned to a register class (A or D, say). Currently, the defining instruction determines the register class. Sometimes it is necessary to insert extra copy instructions before instructions that require an incompatible register class. Enabling -join-cross-class-copies will clean up a lot of these copies afterwards. I have a patch in my own tree that will do register class inference instead: It tries to choose a register class for a virtual register based on all interested instructions, rather than just the defining one. This causes less copies to be emitted only to be removed later. The end result is similar, so it is mostly an optimisation. There are some unsolved problems: 1. Virtual registers from PHI nodes are created before instruction selection, so there is no way of giving them a proper register class. Instead, TargetLowering::getRegClassFor() is used, fingers crossed. It may be that -join-cross-class-copies is able to clean up here too. I have not tested that. Ideally, I would like TargetLowering::getRegClassFor() to go away entirely. 2. There is no way of using alternative instructions with different operand classes. For instance, TriCore can subtract two D registers (SUB), or two A registers (SUB.A). You can only have one pattern for i32 subtraction, so the SUB.A instruction will not be used. We need a way of replacing SUB with SUB.A when it makes sense. Calculating when it makes sense is the hard part. You can produce correct code without solving these problems - you will just have some extra copies between A and D registers. > Moreover, the ABI requires that pointer arguments to (and > pointer results from) functions be passed in address registers instead > of general-purpose registers. You should treat this as a separate issue from register allocation. The ABI requirements must be followed exactly, and you need some kind of annotation as Dan described. For register allocation you can be less exact, and that can be an advantage. Pointer and integer arithmetic is sometimes mixed, and it can be an advantage to keep an integer in a pointer register and vice versa. HTH /jakob From Micah.Villmow at amd.com Wed May 6 12:53:42 2009 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Wed, 6 May 2009 10:53:42 -0700 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com><493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com><493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> Message-ID: <493720826E33B1459E7F5C253E6D4BB50FF9FC@ssanexmb2.amd.com> Yeah, I found that out, which is why I was hoping some kind of attribute existed that the compiler knew about. We might go the path of modifying llvm-link to only link in functions that are required as that seems to be the most optimal way of doing it. Thanks, Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, May 05, 2009 7:47 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Pass to remove unused functions On May 5, 2009, at 4:50 PM, Villmow, Micah wrote: Is there a way to mark all functions as internal from source via some sort of attribute? "static". However, if you do that, they won't make it into the bc file. -Chris Thanks for the tips, Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, May 05, 2009 4:16 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Pass to remove unused functions On May 5, 2009, at 4:07 PM, Villmow, Micah wrote: I thought this pass would do it, but when I run it over my bc file the output file is the same as the input file. that's probably because your symbols are not internal. The issue I guess is a little different. When I link in the huge bc file with the tiny bc file, I only want the resulting bc file to have the function definitions that the tiny bc file requires and not every function in the huge bc file. Any idea's how to do this with the current llvm toolset? You have to roll your own using the lower level APIs. You can move functions between modules etc. Alternatively, you can link the two modules and mark the functions you don't want as internal, then use globaldce. -Chris _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090506/40ece989/attachment.html From clattner at apple.com Wed May 6 13:27:41 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 6 May 2009 11:27:41 -0700 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: <493720826E33B1459E7F5C253E6D4BB50FF9FC@ssanexmb2.amd.com> References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF9FC@ssanexmb2.amd.com> Message-ID: <53EE724B-8ED5-4010-A077-F08F6BE4B563@apple.com> On May 6, 2009, at 10:53 AM, Villmow, Micah wrote: > Yeah, I found that out, which is why I was hoping some kind of > attribute existed that the compiler knew about. > We might go the path of modifying llvm-link to only link in > functions that are required as that seems to be the most optimal way > of doing it. If you care about performance, then you should consider a completely different approach. It is really inefficient to load a large volume of code and then delete it as dead. I strongly recommend watching Nate's talk at the last llvm developer meeting. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090506/0f1d590c/attachment.html From sricketts at maxentric.com Wed May 6 14:22:24 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Wed, 6 May 2009 12:22:24 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <200905060833.21433.baldrick@free.fr> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905052126.59153.baldrick@free.fr> <6d9073030905051324w3c2d7f83s792e6584e175906f@mail.gmail.com> <200905060833.21433.baldrick@free.fr> Message-ID: <6d9073030905061222k14ccfe9dlc90860bccc9e57d9@mail.gmail.com> On Tue, May 5, 2009 at 11:33 PM, Duncan Sands wrote: > Hi Scott, > >> On Tue, May 5, 2009 at 12:26 PM, Duncan Sands wrote: >> > this is indeed a miscompilation by your system compiler. ?However so many >> > compilers miscompiled this that a workaround was committed to svn. ?So you >> > may want to check out llvm and llvm-gcc from svn. ?Alternatively, maybe >> > the patch applies to llvm 2.5 too. ?I've attached it. >> >> I will try the latest from svn... but quick follow up question: If it >> looks like a miscompilation by my system compiler (gcc 4.1.2), why >> wasn't gcc-4.2.4 used? Did I make a mistake in configuration? Maybe I >> am misunderstanding the build process. > > some versions of gcc 4.2 also miscompile this on 64 bit platforms... > By the way, I attached the wrong patch. ?Try this new one instead! > > Ciao, > > Duncan. > Thanks, I am making some progress. The latest from svn (for llvm and llvm-gcc) built successfully. I built everything without adjusting the PATH, so I guess I used gcc 4.1.2. However, I then went back to attempt a build with ENABLE_OPTIMIZED=1 (this is just a test installation, once I get things working I will be installing on another machine with the same OS). The optimized build of llvm failed: make[1]: Entering directory `/pkg/build/llvm-svn2/llvm-obj/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td llvm[1]: Compiling AsmWriter.cpp for Release build llvm[1]: Compiling Attributes.cpp for Release build llvm[1]: Compiling AutoUpgrade.cpp for Release build llvm[1]: Compiling BasicBlock.cpp for Release build llvm[1]: Compiling ConstantFold.cpp for Release build llvm[1]: Compiling Constants.cpp for Release build llvm[1]: Compiling Core.cpp for Release build llvm[1]: Compiling Dominators.cpp for Release build llvm[1]: Compiling Function.cpp for Release build g++: Internal error: Segmentation fault (program cc1plus) So then I did make clean. No big deal, I can live without the optimized build. But originally I just built with "make tools-only" because I had not yet built llvm-gcc. But now I have a built version of llvm-gcc, so I re-configured with: ../llvm/configure --prefix=/pkg/bin/llvm --with-llvmgccdir=/pkg/build/llvm-svn2/install/ and then did "make" in the llvm-obj directory. But this build failed: make[2]: Entering directory `/pkg/build/llvm-svn2/llvm-obj/tools/bugpoint' llvm[2]: Compiling BugDriver.cpp for Debug build llvm[2]: Compiling CrashDebugger.cpp for Debug build llvm[2]: Compiling ExecutionDriver.cpp for Debug build llvm[2]: Compiling ExtractFunction.cpp for Debug build llvm[2]: Compiling FindBugs.cpp for Debug build /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/ostream.tcc: In member function ?std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(double)?: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/ostream.tcc:374: internal compiler error: Segmentation fault Now I am thoroughly confused. Can someone check my installation process? Here is what I think I am supposed to do: 1) configure llvm without pointing to llvm-gcc, "make tools-only" 2) configure llvm-gcc pointing to the llvm build from step (1) 3) re-configure llvm to point to llvm-gcc from step (2), "make" FYI, I tried the first patch Duncan sent (applied to llvm-2.5), which did not fix the problem. I have not yet tried the second patch. I am assuming that checking out the latest from svn is at least as good? Scott From llvm at assumetheposition.nl Wed May 6 14:54:30 2009 From: llvm at assumetheposition.nl (Paul Melis) Date: Wed, 06 May 2009 21:54:30 +0200 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: <53EE724B-8ED5-4010-A077-F08F6BE4B563@apple.com> References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF9FC@ssanexmb2.amd.com> <53EE724B-8ED5-4010-A077-F08F6BE4B563@apple.com> Message-ID: <4A01EAF6.90607@assumetheposition.nl> Hi, Chris Lattner wrote: > On May 6, 2009, at 10:53 AM, Villmow, Micah wrote: >> Yeah, I found that out, which is why I was hoping some kind of >> attribute existed that the compiler knew about. >> We might go the path of modifying llvm-link to only link in functions >> that are required as that seems to be the most optimal way of doing it. > > If you care about performance, then you should consider a completely > different approach. It is really inefficient to load a large volume > of code and then delete it as dead. I strongly recommend watching > Nate's talk at the last llvm developer meeting. Just chiming in here. Regarding the slides in .pdf of that talk, some pages seem to contain black text on a black->dark blue gradient background, making them really hard to read. Would it be possible to get an updated version? Thanks, Paul From anton at korobeynikov.info Wed May 6 14:51:13 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 06 May 2009 23:51:13 +0400 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905061222k14ccfe9dlc90860bccc9e57d9@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905052126.59153.baldrick@free.fr> <6d9073030905051324w3c2d7f83s792e6584e175906f@mail.gmail.com> <200905060833.21433.baldrick@free.fr> <6d9073030905061222k14ccfe9dlc90860bccc9e57d9@mail.gmail.com> Message-ID: <1241639473.18321.66.camel@aslstation> Hello, Scott > Thanks, I am making some progress. The latest from svn (for llvm and > llvm-gcc) built successfully. I built everything without adjusting the > PATH, so I guess I used gcc 4.1.2. Even if you'll succeed, most probably LLVM will be miscompiled. gcc 4.1.2 is known buggy: http://llvm.org/docs/GettingStarted.html#brokengcc --- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From samuraileumas at yahoo.com Wed May 6 15:24:38 2009 From: samuraileumas at yahoo.com (Samuel Crow) Date: Wed, 6 May 2009 13:24:38 -0700 (PDT) Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: <4A01EAF6.90607@assumetheposition.nl> References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF9FC@ssanexmb2.amd.com> <53EE724B-8ED5-4010-A077-F08F6BE4B563@apple.com> <4A01EAF6.90607@assumetheposition.nl> Message-ID: <542518.89825.qm@web62007.mail.re1.yahoo.com> Hello Paul, The one I downloaded from http://llvm.org/devmtg/2008-08/Begeman_EfficientJIT.pdf seemed to have been formatted with white text on a grey background. Maybe that's the version you need. --Sam ----- Original Message ---- > From: Paul Melis > To: LLVM Developers Mailing List > Sent: Wednesday, May 6, 2009 2:54:30 PM > Subject: Re: [LLVMdev] Pass to remove unused functions > > Hi, > > Just chiming in here. Regarding the slides in .pdf of that talk, some > pages seem to contain black text on a black->dark blue gradient > background, making them really hard to read. Would it be possible to get > an updated version? > > Thanks, > Paul > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From sricketts at maxentric.com Wed May 6 15:26:59 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Wed, 6 May 2009 13:26:59 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <1241639473.18321.66.camel@aslstation> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905052126.59153.baldrick@free.fr> <6d9073030905051324w3c2d7f83s792e6584e175906f@mail.gmail.com> <200905060833.21433.baldrick@free.fr> <6d9073030905061222k14ccfe9dlc90860bccc9e57d9@mail.gmail.com> <1241639473.18321.66.camel@aslstation> Message-ID: <6d9073030905061326u6443401bj8699bde90ada4347@mail.gmail.com> On Wed, May 6, 2009 at 12:51 PM, Anton Korobeynikov wrote: > Even if you'll succeed, most probably LLVM will be miscompiled. gcc > 4.1.2 is known buggy: http://llvm.org/docs/GettingStarted.html#brokengcc > Yes, so I have read -- which is why I initially installed gcc-4.2.4. My original post was looking for help on how to use gcc-4.2.4. Some suggestions were made, but I was not able to get everything built. It seems that despite attempting to configure with everything pointing to gcc-4.2.4 (and not the system gcc 4.1.2), at some point in the build, something would look for a file or use a file from the system gcc 4.1.2. I would love to get this built using gcc-4.2.4, but I think I could use some help. If someone could point me to the relevant config variables, I might be able to debug this. From llvm at assumetheposition.nl Wed May 6 15:27:45 2009 From: llvm at assumetheposition.nl (Paul Melis) Date: Wed, 06 May 2009 22:27:45 +0200 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: <542518.89825.qm@web62007.mail.re1.yahoo.com> References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF9FC@ssanexmb2.amd.com> <53EE724B-8ED5-4010-A077-F08F6BE4B563@apple.com> <4A01EAF6.90607@assumetheposition.nl> <542518.89825.qm@web62007.mail.re1.yahoo.com> Message-ID: <4A01F2C1.9000703@assumetheposition.nl> Samuel Crow wrote: > Hello Paul, > > The one I downloaded from http://llvm.org/devmtg/2008-08/Begeman_EfficientJIT.pdf seemed to have been formatted with white text on a grey background. Maybe that's the version you need. > With adobe reader 8.1.4 I still get black text, and I think it's the same one linked to in the development meeting list of presentations. What pdf reader are you using? Paul > > --Sam > > ----- Original Message ---- > >> From: Paul Melis >> To: LLVM Developers Mailing List >> Sent: Wednesday, May 6, 2009 2:54:30 PM >> Subject: Re: [LLVMdev] Pass to remove unused functions >> >> Hi, >> >> Just chiming in here. Regarding the slides in .pdf of that talk, some >> pages seem to contain black text on a black->dark blue gradient >> background, making them really hard to read. Would it be possible to get >> an updated version? >> >> Thanks, >> Paul >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From llvm at assumetheposition.nl Wed May 6 15:40:54 2009 From: llvm at assumetheposition.nl (Paul Melis) Date: Wed, 06 May 2009 22:40:54 +0200 Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: <4A01F2C1.9000703@assumetheposition.nl> References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF9FC@ssanexmb2.amd.com> <53EE724B-8ED5-4010-A077-F08F6BE4B563@apple.com> <4A01EAF6.90607@assumetheposition.nl> <542518.89825.qm@web62007.mail.re1.yahoo.com> <4A01F2C1.9000703@assumetheposition.nl> Message-ID: <4A01F5D6.2000502@assumetheposition.nl> Paul Melis wrote: > Samuel Crow wrote: > >> Hello Paul, >> >> The one I downloaded from http://llvm.org/devmtg/2008-08/Begeman_EfficientJIT.pdf seemed to have been formatted with white text on a grey background. Maybe that's the version you need. >> >> > With adobe reader 8.1.4 I still get black text, and I think it's the > same one linked to in the development meeting list of presentations. > What pdf reader are you using? > Alright, tried opening the file with evince and now I can indeed read the slides :) Paul From samuraileumas at yahoo.com Wed May 6 15:42:17 2009 From: samuraileumas at yahoo.com (Samuel Crow) Date: Wed, 6 May 2009 13:42:17 -0700 (PDT) Subject: [LLVMdev] Pass to remove unused functions In-Reply-To: <4A01F2C1.9000703@assumetheposition.nl> References: <493720826E33B1459E7F5C253E6D4BB50FF8C1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8D1@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF8FC@ssanexmb2.amd.com> <493720826E33B1459E7F5C253E6D4BB50FF9FC@ssanexmb2.amd.com> <53EE724B-8ED5-4010-A077-F08F6BE4B563@apple.com> <4A01EAF6.90607@assumetheposition.nl> <542518.89825.qm@web62007.mail.re1.yahoo.com> <4A01F2C1.9000703@assumetheposition.nl> Message-ID: <346400.6650.qm@web62005.mail.re1.yahoo.com> I'm using the version of Preview that came with MacOSX Leopard. > With adobe reader 8.1.4 I still get black text, and I think it's the > same one linked to in the development meeting list of presentations. > What pdf reader are you using? > > Paul From anton at korobeynikov.info Wed May 6 16:32:10 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 7 May 2009 01:32:10 +0400 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905061326u6443401bj8699bde90ada4347@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905052126.59153.baldrick@free.fr> <6d9073030905051324w3c2d7f83s792e6584e175906f@mail.gmail.com> <200905060833.21433.baldrick@free.fr> <6d9073030905061222k14ccfe9dlc90860bccc9e57d9@mail.gmail.com> <1241639473.18321.66.camel@aslstation> <6d9073030905061326u6443401bj8699bde90ada4347@mail.gmail.com> Message-ID: Hello, Scott > Yes, so I have read -- which is why I initially installed gcc-4.2.4. > My original post was looking for help on how to use gcc-4.2.4. Some > suggestions were made, but I was not able to get everything built. It > seems that despite attempting to configure with everything pointing to > gcc-4.2.4 (and not the system gcc 4.1.2), at some point in the build, > something would look for a file or use a file from the system gcc > 4.1.2. That's correct. Since you have everything linked as shared libraries system dynamic linker will pick the shared library installed in the default library location. Most probably you will need to edit /etc/ld.so.conf and put the gcc 4.2.4 library path there *before* system compiler one and rerun "ldconfig" (from root).... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From mikael.lepisto at tut.fi Thu May 7 01:28:29 2009 From: mikael.lepisto at tut.fi (=?ISO-8859-1?Q?Mikael_Lepist=F6?=) Date: Thu, 07 May 2009 09:28:29 +0300 Subject: [LLVMdev] Installing tbgen with llvm by default. In-Reply-To: <282C680B-D934-44E6-BA94-361B8DAAAF08@apple.com> References: <682D1598-44D2-4CE1-AD28-113F0B5B9F06@tut.fi> <282C680B-D934-44E6-BA94-361B8DAAAF08@apple.com> Message-ID: <4A027F8D.2020104@tut.fi> Chris Lattner wrote: > > On May 4, 2009, at 11:03 PM, Mikael Lepist? wrote: > >> Hi, >> >> Would it be possible to set tbgen to be installed with llvm? For our >> project http://llvm.org/ProjectsWithLLVM/#tta-tce it would be very >> helpful, because our tools generate compiler backend plugins in the >> fly for each customized processor and plugin generation needs tbgen >> for handling td files. > > Sure, would you care to prepare a patch? > > -Chris Great! Hope that this patch will do. I removed util dir from install filter-out list, added NO_INSTALL = 1 to googletest Makefile and removed NO_INSTALL define from tblgen. Mikael Lepist? -------------- next part -------------- A non-text attachment was scrubbed... Name: tblgen_install.patch Type: text/x-patch Size: 1192 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090507/67e9a39a/attachment.bin From zhangzhengjian at gmail.com Thu May 7 01:41:55 2009 From: zhangzhengjian at gmail.com (zhengjian zhang) Date: Thu, 7 May 2009 14:41:55 +0800 Subject: [LLVMdev] the different semantics between dwarf-eh and sjlj-eh Message-ID: <8e3538210905062341g1495284dkdaafe11c9992d174@mail.gmail.com> Hi, >> from the exist llvm-ir it seems there are some common info for sjlj-eh >> and dwarf-eh! >> are there possible use the exist llvm-ir to generate exception table > >for sjlj-eh ? >No. There should be support from llvm-gcc. sjlj eh and dwarf eh have >different semantics different semantics ? ! I think llvm-gcc generate the IR should not include the exception runtime lib info, so support dwarf-eh and sjlj-eh should be delay to the llvm back-end or target platform . and the specific target codegen the same IR to different exception style code ! From zhangzhengjian at gmail.com Thu May 7 02:19:35 2009 From: zhangzhengjian at gmail.com (zhengjian zhang) Date: Thu, 7 May 2009 15:19:35 +0800 Subject: [LLVMdev] llvm-gcc's sjlj-eh support Message-ID: <8e3538210905070019w1577749cyd80f32d979d7f2f8@mail.gmail.com> Hi, many people suggest that if we want llvm to support sjlj-eh, we should modify the llvm-gcc to generate sjlj-style IR. yeah, I'm digging into the llvm-gcc now. there are some functions, at the llvm-gcc e.g TreeToLLVM::CreateExceptionValues() , BasicBlock *TreeToLLVM::getPostPad(unsigned RegionNo), void TreeToLLVM::EmitLandingPads(), void TreeToLLVM::EmitPostPads() , void TreeToLLVM::EmitUnwindBlock() the above functions are relative for llvm-gcc generate the exception-IR, but for dwarf-style! so we should change these above functions to generate sjlj-style exception-IR, base on the different semantics between dwarf-eh and sjlj-eh. my problem is : what 's different semantics between dwarf-eh and sjlj-eh ? best regards zhangzw From johnhull2008 at gmail.com Thu May 7 07:17:21 2009 From: johnhull2008 at gmail.com (john hull) Date: Thu, 7 May 2009 05:17:21 -0700 Subject: [LLVMdev] Command Line Argument 'inline-threshold' Message-ID: <16f40f0905070517k1eb2e1a3k1d3af538e23c0dfa@mail.gmail.com> When I run a pass with opt, for example -view-cfg, I get the following error message: opt: CommandLine Error: Argument 'inline-threshold' defined more than once! It seems that it is complaining "inline-threshold" is defined in more than one pass. I checked the source files, and there are two places where it is defined. Transforms/Utils/BasicInliner.cpp Transforms/IPO/Inliner.cpp Has anyone encountered this error and is this caused by something I did wrong when I built LLVM? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090507/8404a231/attachment.html From anton at korobeynikov.info Thu May 7 07:24:14 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 7 May 2009 16:24:14 +0400 Subject: [LLVMdev] the different semantics between dwarf-eh and sjlj-eh In-Reply-To: <8e3538210905062341g1495284dkdaafe11c9992d174@mail.gmail.com> References: <8e3538210905062341g1495284dkdaafe11c9992d174@mail.gmail.com> Message-ID: Hello, > I think llvm-gcc generate the IR should not include the exception > runtime lib info, so support dwarf-eh and sjlj-eh should be > delay to the llvm back-end or target platform . and the specific > target codegen the same IR to different exception style code ! This is not possible, unfortunately. There *should* be support from frontend. Different styles of exceptions share some stuff, but still have differences. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From npjohnso at cs.princeton.edu Thu May 7 10:53:44 2009 From: npjohnso at cs.princeton.edu (Nick Johnson) Date: Thu, 7 May 2009 11:53:44 -0400 Subject: [LLVMdev] Set alignment of a structure? Message-ID: Hello, Is it possible to set the alignment of a StructType in llvm? Especially in the case that it may contain OpaqueTypes? Thanks, -- Nick Johnson From eli.friedman at gmail.com Thu May 7 11:02:18 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 7 May 2009 09:02:18 -0700 Subject: [LLVMdev] Set alignment of a structure? In-Reply-To: References: Message-ID: On Thu, May 7, 2009 at 8:53 AM, Nick Johnson wrote: > Is it possible to set the alignment of a StructType in llvm? Not directly; structs are either packed or not packed. You can model arbitrary alignment, though, by using a packed struct and making sure the alignment on allocations and loads is set explicitly. > Especially in the case that it may contain OpaqueTypes? IIRC, a struct can't directly contain an OpaqueType. -Eli From ksh.cseiitk at gmail.com Thu May 7 11:03:40 2009 From: ksh.cseiitk at gmail.com (Kshitiz Garg) Date: Thu, 7 May 2009 21:33:40 +0530 Subject: [LLVMdev] obtaining IR for CellBE code Message-ID: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com> Hello, I was trying to extract out the IR for some CELLBE code. However i was not able to compile with llvm-gcc. Has someone who has tried this shed some light on the changes required to use llvm-gcc instead of gcc or xlc. A simple replacement of gcc with llvm-gcc -emit-llvm -S or marking $CC as llvm-gcc in the makefile did not work for me. I am using the standard makefile format supplied with the example codes of CellSDK. Is there any alternate way / intrinsic which can be called to introduce calls to the Cell C intrinsic functions?? TIA, regards, Kshitiz -- Kshitiz Garg Graduate Student Department of Computer Science & Engineering IIT Kanpur http://home.iitk.ac.in/~kshitizg From eli.friedman at gmail.com Thu May 7 11:09:45 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 7 May 2009 09:09:45 -0700 Subject: [LLVMdev] obtaining IR for CellBE code In-Reply-To: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com> References: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com> Message-ID: On Thu, May 7, 2009 at 9:03 AM, Kshitiz Garg wrote: > ? ?I was trying to extract out the IR for some CELLBE code. However i > was not able to compile with llvm-gcc. Can you give a couple examples of error messages you're getting? -Eli From grosbach at apple.com Thu May 7 11:15:43 2009 From: grosbach at apple.com (Jim Grosbach) Date: Thu, 7 May 2009 09:15:43 -0700 Subject: [LLVMdev] the different semantics between dwarf-eh and sjlj-eh In-Reply-To: <8e3538210905062341g1495284dkdaafe11c9992d174@mail.gmail.com> References: <8e3538210905062341g1495284dkdaafe11c9992d174@mail.gmail.com> Message-ID: <9C6F8566-2879-4B47-84CA-780034BD706D@apple.com> On May 6, 2009, at 11:41 PM, zhengjian zhang wrote: >>> from the exist llvm-ir it seems there are some common info for >>> sjlj-eh >>> and dwarf-eh! >>> are there possible use the exist llvm-ir to generate exception table >>> for sjlj-eh ? > >> No. There should be support from llvm-gcc. sjlj eh and dwarf eh have >> different semantics > > different semantics ? ! > I think llvm-gcc generate the IR should not include the exception > runtime lib info, so support dwarf-eh and sjlj-eh should be > delay to the llvm back-end or target platform . and the specific > target codegen the same IR to different exception style code ! Exception handling should definitely be handled, as much as possible, in the non-target specific code. There is very little target information required, and what there is can be handled with a few careful hooks. On the other hand, it's not completely possible to separate it from the front end either since different languages can have different semantics. Ada, C++, Objective C, etc.. Sometimes these can be handled the same way under the hood, but it's dangerous for the compiler to assume that to be true. At least some knowledge needs to be in the front end code-gen. I should have some draft code ready soon (within a few days) that demonstrates some of this. I don't know if it will meet your needs, but if not, it should provide a starting point. -Jim From clattner at apple.com Thu May 7 11:19:03 2009 From: clattner at apple.com (Chris Lattner) Date: Thu, 7 May 2009 09:19:03 -0700 Subject: [LLVMdev] Set alignment of a structure? In-Reply-To: References: Message-ID: <0F5C6732-5968-4338-95FC-1EE72158301C@apple.com> On May 7, 2009, at 8:53 AM, Nick Johnson wrote: > Hello, > > Is it possible to set the alignment of a StructType in llvm? Nope. If this is for a global variable (For example), you build the ConstantStruct with a type that ensures that the elements get the right offsets, then you put the alignment on the GlobalVariable itself. -Chris From ksh.cseiitk at gmail.com Thu May 7 11:25:52 2009 From: ksh.cseiitk at gmail.com (Kshitiz Garg) Date: Thu, 7 May 2009 21:55:52 +0530 Subject: [LLVMdev] obtaining IR for CellBE code In-Reply-To: References: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com> Message-ID: <13da638f0905070925u5e2df32r862ffb400d357e87@mail.gmail.com> On Thu, May 7, 2009 at 9:39 PM, Eli Friedman wrote: > On Thu, May 7, 2009 at 9:03 AM, Kshitiz Garg wrote: >> ? ?I was trying to extract out the IR for some CELLBE code. However i >> was not able to compile with llvm-gcc. > > Can you give a couple examples of error messages you're getting? llvm-gcc -emit-llvm -S -W -Wall -Winline -Wno-main -I. -I /opt/cell/sysroot/usr/spu/include -I /opt/cell/sysroot/opt/cell/sdk/usr/spu/include -O3 -c simpleDMA_spu.c simpleDMA_spu.c:42:23: error: spu_mfcio.h: No such file or directory simpleDMA_spu.c: In function ?main?: simpleDMA_spu.c:60: warning: implicit declaration of function ?mfc_tag_reserve? simpleDMA_spu.c:60: error: ?MFC_TAG_INVALID? undeclared (first use in this function) simpleDMA_spu.c:60: error: (Each undeclared identifier is reported only once simpleDMA_spu.c:60: error: for each function it appears in.) simpleDMA_spu.c:74: warning: implicit declaration of function ?mfc_get? simpleDMA_spu.c:79: warning: implicit declaration of function ?mfc_write_tag_mask? simpleDMA_spu.c:83: warning: implicit declaration of function ?mfc_read_tag_status_all? what is happening is llvm-gcc is not able to view the header files even when the includes have been given Kshitiz From dag at cray.com Thu May 7 11:38:42 2009 From: dag at cray.com (David Greene) Date: Thu, 7 May 2009 11:38:42 -0500 Subject: [LLVMdev] RFC: AVX Pattern Specification [LONG] In-Reply-To: <200905011647.13167.dag@cray.com> References: <200904301759.12384.dag@cray.com> <9F20A521-BB17-4995-86A3-436C7E853613@apple.com> <200905011647.13167.dag@cray.com> Message-ID: <200905071138.43693.dag@cray.com> On Friday 01 May 2009 16:47, David Greene wrote: > > While I agree that we want to refactor this, I really don't think that > > we should autogenerate .td files from perl. This has a number of > > significant logistical problems. What is it that perl gives you that > > we can't enhance tblgen to do directly? > > Well, mainly it's because we don't have whatever tblgen enhancements we > need. I'll have to think on this some and see if I can come up with some > tblgen features that could help. > > I was writing a lot of these base classes by hand at first, but there are a > lot of them (they tend to be very small) and writing them is very > mechanical. So we probably can enhance tblgen somehow. I'm just not sure > what that looks like right now. So I've been thinking about this some more and the major obtacle here is that the Perl generator has a lot of X86-specific knowledge coded into it. For example, it knows: * "SS" instructions need to use ths XS encoding class, but only for SSE1 and AVX * "SD" instructions need to use the XD encoding class, but only for SSE2 and AVX * A vector instruction never uses XS or XD encoding * A scalar instruction never uses OpSize or TB * AVX uses rrm and mrr encoding, SSE uses rm and mr * rrm expands to rrr and rrm encoding, rm expands to rr and rm * mr only expands to mr, mrr only expands to mrr * and on and on... I'm not sure how to conveniently encapsulate all of that detailed knowledge in a set of TableGen classes and/or feature extensions. Basically, TableGen would need to look at defm ADD : sse1_sse2_avx_avx3_binary_scalar_xs_xd_vector_tb_ostb_node_intrinsic_rm_rrm< 0x58, "add", fadd, "add", 1 >; and understand all of the SS/PS/SD/PD/VEX/etc. combinations that implies. Or at least have support to conveniently express inheritance from multiclasses that provide the valid SS/PS, etc. combinations and (this is critical) a convenient way to transform class/multiclass arguments to specialize them for the various instruction sets/encodings. If we only want to specify patterns and arguments once, we need a way to specify transformations on them and pass the results down to base (multi)classes. That's what the intermediate classes generated by the Perl script do. They serve two functions: * Provide valid format combinations (e.g. SS/PS/SD/PD, SS/SD, PS/PD, etc.) * Provide argument transformation to specialize for various formats and encoding I've got a few ideas rolling in my head but I need to do some more thinking. Oh, and I guess I'll go ahead and add XOP support too: http://forums.amd.com/devblog/blogpost.cfm?threadid=112934&catid=208 -Dave From eli.friedman at gmail.com Thu May 7 11:42:21 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 7 May 2009 09:42:21 -0700 Subject: [LLVMdev] obtaining IR for CellBE code In-Reply-To: <13da638f0905070925u5e2df32r862ffb400d357e87@mail.gmail.com> References: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com> <13da638f0905070925u5e2df32r862ffb400d357e87@mail.gmail.com> Message-ID: On Thu, May 7, 2009 at 9:25 AM, Kshitiz Garg wrote: >> Can you give a couple examples of error messages you're getting? > ?llvm-gcc -emit-llvm -S ? ? ? ?-W -Wall -Winline -Wno-main ?-I. ?-I > /opt/cell/sysroot/usr/spu/include -I > /opt/cell/sysroot/opt/cell/sdk/usr/spu/include ?-O3 -c simpleDMA_spu.c > simpleDMA_spu.c:42:23: error: spu_mfcio.h: No such file or directory Sorry for the extremely low-level question, but did you compile llvm-gcc as a cross-compiler targeting Cell? Assuming you did, I'm not sure what the issue is; llvm-gcc should be providing that header. -Eli From mjr at cs.wisc.edu Thu May 7 11:54:49 2009 From: mjr at cs.wisc.edu (Matt Renzelmann) Date: Thu, 7 May 2009 11:54:49 -0500 Subject: [LLVMdev] Compiling user mode linux with LLVM Message-ID: <002d01c9cf34$8c20f930$a462eb90$@wisc.edu> Hello, I've recently started working on compiling UML with LLVM: the goal is to produce a bitcode version of vmlinux. With some tweaks to the build process, I can use: make ARCH=um CROSS_COMPILE=llvm- CFLAGS="-emit-llvm" to produce vmlinux bitcode. The question is with respect linker script support. Since llvm-ld does not support linker scripts--please correct me if I'm wrong--it's clear that some work is necessary to get things running. There was a thread on the mailing list last September about this question: ====================================== > Hi, > > I'm trying to compile linux kernel with llvm to generate llvm ir > (bitcode). It seems like llvm-ld doesn't accept any linker scripts. > How do I deal with vmlinux.lds in such a case? How did people who have > compiled linux kernel with llvm deal with this in the past? You need to add a bytecode linker stage before that. You still need the linker script for correctness, but you must use it in the final link stage after you have generated a native .o file from the bitcode. By the way, it you are still planning on jitting the kernel, you should be warned that the linker script creates globals and arrays that are referenced by the kernel code but otherwise will appear nowhere in your bitcode... You will have to rewrite the kernel's initialization infastructure or write a pass to fix up the bitcode or both. Andrew ====================================== As an experiment, I've tried using llc to convert the vmlinux.bc output into native assembly, then use "as" and "ld" to produce a native vmlinux, but the ld step fails with: ld: ./vmlinux_native.o: bad reloc symbol index (0x9c113c >= 0x4af6) for offset 0x18585 in section `.text' ./vmlinux_native.o: could not read symbols: Bad value I've not pursued this specific issue further since my goal is to run the bitcode directly, e.g. via lli. I'm also aware of the clever tricks the kernel uses that need to be addressed, mentioned in the second paragraph of Andrew's above reply. As an example, the symbol __initcall_start is defined in a linker script (vmlinux.lds) and is used in the kernel as part of the initialization. Has anyone successfully modified the kernel initialization code to get UML working with LLVM? If so, I'm interested in the approach taken so as to avoid wasting time. Thanks and regards, Matt Renzelmann From nicholas.paul.johnson at gmail.com Thu May 7 11:58:06 2009 From: nicholas.paul.johnson at gmail.com (Nick Johnson) Date: Thu, 7 May 2009 12:58:06 -0400 Subject: [LLVMdev] Set alignment of a structure? In-Reply-To: <0F5C6732-5968-4338-95FC-1EE72158301C@apple.com> References: <0F5C6732-5968-4338-95FC-1EE72158301C@apple.com> Message-ID: >> Is it possible to set the alignment of a StructType in llvm? > > Nope. If this is for a global variable (For example), you build the > ConstantStruct with a type that ensures that the elements get the > right offsets, then you put the alignment on the GlobalVariable itself. That is unfortunate for a few reasons, (1) I am generating multi-threaded code, and I want to use alignment to ensure that the memory used by each thread is in separate cache lines. (2) The code I generate links against external libraries which contain complicated data types---also featuring alignment. Because llvm doesn't support alignment, I must represent these as opaque types. However, that means that I cannot even manually pad the size of the structure with a char array, since there is no way to determine the size of the opaque type. I think the best solution to this problem is simply to set a structure alignment. If I'm not mistaken, nothing in llvm really needs to know the exact structure alignment until GEPs have been lowered to native. -- Nick Johnson From tilmann.scheller at googlemail.com Thu May 7 11:58:47 2009 From: tilmann.scheller at googlemail.com (Tilmann Scheller) Date: Thu, 7 May 2009 18:58:47 +0200 Subject: [LLVMdev] obtaining IR for CellBE code In-Reply-To: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com> References: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com> Message-ID: Hi Kshitiz, unfortunately it is not possible to build an spu-llvm-gcc yet, there is a small number of issues (mainly support for integer divides and some 128-bit related stuff) which prevent the LLVM SPU backend from compiling libgcc successfully (the low level runtime library which is built as part of llvm-gcc) and thus prevent a successful llvm-gcc build. Please note that the Cell SPU backend is considered experimental. Patches welcome though! :) Greetings, Tilmann On Thu, May 7, 2009 at 6:03 PM, Kshitiz Garg wrote: > Hello, > ? ?I was trying to extract out the IR for some CELLBE code. However i > was not able to compile with llvm-gcc. > Has someone who has tried this shed some light on the changes required > to use ?llvm-gcc instead of gcc or xlc. > A simple replacement of gcc with llvm-gcc -emit-llvm -S or marking $CC > as llvm-gcc in the makefile did not work for me. I am using the > standard makefile format supplied with the example codes of CellSDK. > ?Is there any alternate way / intrinsic which can be called to > introduce calls to the Cell C intrinsic functions?? > TIA, > regards, > Kshitiz > -- > Kshitiz Garg > Graduate Student > Department of Computer Science & Engineering > IIT Kanpur > http://home.iitk.ac.in/~kshitizg > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From ksh.cseiitk at gmail.com Thu May 7 11:59:09 2009 From: ksh.cseiitk at gmail.com (Kshitiz Garg) Date: Thu, 7 May 2009 22:29:09 +0530 Subject: [LLVMdev] obtaining IR for CellBE code In-Reply-To: References: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com> <13da638f0905070925u5e2df32r862ffb400d357e87@mail.gmail.com> Message-ID: <13da638f0905070959g12f6596dp98e70f0b3bdd73dc@mail.gmail.com> On Thu, May 7, 2009 at 10:12 PM, Eli Friedman wrote: > On Thu, May 7, 2009 at 9:25 AM, Kshitiz Garg wrote: >>> Can you give a couple examples of error messages you're getting? >> ?llvm-gcc -emit-llvm -S ? ? ? ?-W -Wall -Winline -Wno-main ?-I. ?-I >> /opt/cell/sysroot/usr/spu/include -I >> /opt/cell/sysroot/opt/cell/sdk/usr/spu/include ?-O3 -c simpleDMA_spu.c >> simpleDMA_spu.c:42:23: error: spu_mfcio.h: No such file or directory > > Sorry for the extremely low-level question, but did you compile > llvm-gcc as a cross-compiler targeting Cell? ?Assuming you did, I'm > not sure what the issue is; llvm-gcc should be providing that header. > Oh ok.. I think that is the problem. I was using the llvm-gcc x86 pre compiled binary. . I will compile llvm-gcc fromt end from the source code and try that. Thanks a lot.. :) Kshitiz From monping at apple.com Thu May 7 12:34:18 2009 From: monping at apple.com (Mon Ping Wang) Date: Thu, 7 May 2009 10:34:18 -0700 Subject: [LLVMdev] Command Line Argument 'inline-threshold' In-Reply-To: <16f40f0905070517k1eb2e1a3k1d3af538e23c0dfa@mail.gmail.com> References: <16f40f0905070517k1eb2e1a3k1d3af538e23c0dfa@mail.gmail.com> Message-ID: <08D5FD3A-48EB-42CB-91F9-45ED1D1FD347@apple.com> Hi, No, you didn't do anything wrong. This has been changed in TOT. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090223/074122.html -- Mon Ping On May 7, 2009, at 5:17 AM, john hull wrote: > When I run a pass with opt, for example -view-cfg, I get the > following error message: > > opt: CommandLine Error: Argument 'inline-threshold' defined more > than once! > > It seems that it is complaining "inline-threshold" is defined in > more than one pass. > I checked the source files, and there are two places where it is > defined. > > Transforms/Utils/BasicInliner.cpp > Transforms/IPO/Inliner.cpp > > Has anyone encountered this error and is this caused by something I > did wrong when I built LLVM? > > Thank you. > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From mjr at cs.wisc.edu Thu May 7 11:47:50 2009 From: mjr at cs.wisc.edu (Matt Renzelmann) Date: Thu, 7 May 2009 11:47:50 -0500 Subject: [LLVMdev] Compiling user mode linux with LLVM Message-ID: <002c01c9cf33$94ae9180$be0bb480$@wisc.edu> Hello, I've recently started working on compiling UML with LLVM: the goal is to produce a bitcode version of vmlinux. With some tweaks to the build process, I can use: make ARCH=um CROSS_COMPILE=llvm- CFLAGS="-emit-llvm" to produce vmlinux bitcode. The question is with respect linker script support. Since llvm-ld does not support linker scripts--please correct me if I'm wrong--it's clear that some work is necessary to get things running. There was a thread on the mailing list last September about this question: ====================================== > Hi, > > I'm trying to compile linux kernel with llvm to generate llvm ir > (bitcode). It seems like llvm-ld doesn't accept any linker scripts. > How do I deal with vmlinux.lds in such a case? How did people who have > compiled linux kernel with llvm deal with this in the past? You need to add a bytecode linker stage before that. You still need the linker script for correctness, but you must use it in the final link stage after you have generated a native .o file from the bitcode. By the way, it you are still planning on jitting the kernel, you should be warned that the linker script creates globals and arrays that are referenced by the kernel code but otherwise will appear nowhere in your bitcode... You will have to rewrite the kernel's initialization infastructure or write a pass to fix up the bitcode or both. Andrew ====================================== As an experiment, I've tried using llc to convert the vmlinux.bc output into native assembly, then use "as" and "ld" to produce a native vmlinux, but the ld step fails with: ld: ./vmlinux_native.o: bad reloc symbol index (0x9c113c >= 0x4af6) for offset 0x18585 in section `.text' ./vmlinux_native.o: could not read symbols: Bad value I've not pursued this specific issue further since my goal is to run the bitcode directly, e.g. via lli. I'm also aware of the clever tricks the kernel uses that need to be addressed, mentioned in the second paragraph of Andrew's above reply. As an example, the symbol __initcall_start is defined in a linker script (vmlinux.lds) and is used in the kernel as part of the initialization. Has anyone successfully modified the kernel initialization code to get UML working with LLVM? If so, I'm interested in the approach taken so as to avoid wasting time. Thanks and regards, Matt Renzelmann From clattner at apple.com Thu May 7 18:20:22 2009 From: clattner at apple.com (Chris Lattner) Date: Thu, 7 May 2009 16:20:22 -0700 Subject: [LLVMdev] Set alignment of a structure? In-Reply-To: References: <0F5C6732-5968-4338-95FC-1EE72158301C@apple.com> Message-ID: <753162DD-BD87-4E03-83D5-BDD61E9E6D5A@apple.com> On May 7, 2009, at 9:58 AM, Nick Johnson wrote: >>> Is it possible to set the alignment of a StructType in llvm? >> >> Nope. If this is for a global variable (For example), you build the >> ConstantStruct with a type that ensures that the elements get the >> right offsets, then you put the alignment on the GlobalVariable >> itself. > > That is unfortunate for a few reasons, > > (1) I am generating multi-threaded code, and I want to use alignment > to ensure that the memory used by each thread is in separate cache > lines. > > (2) The code I generate links against external libraries which contain > complicated data types---also featuring alignment. Because llvm > doesn't support alignment, I must represent these as opaque types. > However, that means that I cannot even manually pad the size of the > structure with a char array, since there is no way to determine the > size of the opaque type. > > I think the best solution to this problem is simply to set a structure > alignment. If I'm not mistaken, nothing in llvm really needs to know > the exact structure alignment until GEPs have been lowered to native. I don't understand what you're saying. LLVM can and does already express this, just in a different form. Why does this need to be in the type? -Chris From hc2428 at columbia.edu Thu May 7 18:41:49 2009 From: hc2428 at columbia.edu (hc2428 at columbia.edu) Date: Thu, 07 May 2009 19:41:49 -0400 Subject: [LLVMdev] How to use the PoolDescriptor in ds-aa alias analysis? Message-ID: <20090507194149.xnehlb7aoo04o404@cubmail.cc.columbia.edu> Dear Staff, I am reading the paper "Making Context-sensitive Points-to Analysis with Heap Cloning Practical For The Real World", and I build the poolalloc module, and run the program in Figure 1 in this paper with -ds-aa alias analysis. Now I know that X and Y in the program would have distinct PoolDescriptors to make them disjoint data structures. However, how can we use the PoolDescriptor? What is storing in it? It seems that the PoolDescriptor in the program is just parsed as an argument from top to down, but it is not modified, so I am a little confused. Thanks, Heming From hc2428 at columbia.edu Thu May 7 19:07:37 2009 From: hc2428 at columbia.edu (hc2428 at columbia.edu) Date: Thu, 07 May 2009 20:07:37 -0400 Subject: [LLVMdev] Some questions on the output formats of AliasSetTracker Message-ID: <20090507200737.skmhln5yosokkgcw@cubmail.cc.columbia.edu> Dear Staff, Here are some questions on the output formats of AliasSetTracker. The code is as below: int G1 = 9; int G2 = 5; int main() { int * XX; int * YY; XX = &G1; YY = XX; YY = &G2; XX = &G2; } The output for -anders-aa is: Alias Set Tracker: 5 alias sets for 4 pointer values. AliasSet[0xea6fb0,0] may alias, Mod/Ref 10 Call Sites: void ({ }*)* @llvm.dbg.func.start, void ({ }*, { }*)* @llvm.dbg.declare, void ({ }*, { }*)* @llvm.dbg.declare, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void ({ }*)* @llvm.dbg.region.end AliasSet[0xea7040,1] must alias, Mod/Ref Pointers: (i32** %XX, 8) AliasSet[0xea6d40,1] must alias, Mod Pointers: (i32** %YY, 8) AliasSet[0xea6ec0,1] must alias, Mod/Ref Pointers: (i32* %0, 4) AliasSet[0xea67d0,1] must alias, Mod/Ref Pointers: (i32* %retval, 4) The output for -steens-aa in poolalloc module is: Alias Set Tracker: 5 alias sets for 4 pointer values. AliasSet[0xeb0e20,0] may alias, Mod/Ref 10 Call Sites: void ({ }*)* @llvm.dbg.func.start, void ({ }*, { }*)* @llvm.dbg.declare, void ({ }*, { }*)* @llvm.dbg.declare, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void ({ }*)* @llvm.dbg.region.end AliasSet[0xeb5a20,1] must alias, Mod/Ref Pointers: (i32** %XX, 8) AliasSet[0xebb210,1] must alias, Mod Pointers: (i32** %YY, 8) AliasSet[0xebabb0,1] must alias, Mod/Ref Pointers: (i32* %0, 4) AliasSet[0xebac10,1] must alias, Mod/Ref Pointers: (i32* %retval, 4) However, I am a little confused with these output. In Both anders-aa and steens-aa, XX and YY should stay in the same AliasSet, and their alias relationship should be May Alias, right? Sorry I am just a freshman to the alias analysis area, please shed some light on the understanding of the output formats. Best, Heming From hc2428 at columbia.edu Thu May 7 19:13:14 2009 From: hc2428 at columbia.edu (hc2428 at columbia.edu) Date: Thu, 07 May 2009 20:13:14 -0400 Subject: [LLVMdev] Some questions on the output formats of AliasSetTracker Message-ID: <20090507201314.2trbpjqn4kgckwo4@cubmail.cc.columbia.edu> Dear Staff, Here are some questions on the output formats of AliasSetTracker. The code is as below: int G1 = 9; int G2 = 5; int main() { int * XX; int * YY; XX = &G1; YY = XX; YY = &G2; XX = &G2; } The output for -anders-aa is (the command is: opt -anders-aa test.bc -disable-output -print-alias-sets &> output-anders.txt): Alias Set Tracker: 5 alias sets for 4 pointer values. AliasSet[0xea6fb0,0] may alias, Mod/Ref 10 Call Sites: void ({ }*)* @llvm.dbg.func.start, void ({ }*, { }*)* @llvm.dbg.declare, void ({ }*, { }*)* @llvm.dbg.declare, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void ({ }*)* @llvm.dbg.region.end AliasSet[0xea7040,1] must alias, Mod/Ref Pointers: (i32** %XX, 8) AliasSet[0xea6d40,1] must alias, Mod Pointers: (i32** %YY, 8) AliasSet[0xea6ec0,1] must alias, Mod/Ref Pointers: (i32* %0, 4) AliasSet[0xea67d0,1] must alias, Mod/Ref Pointers: (i32* %retval, 4) The output for -steens-aa in poolalloc module is: Alias Set Tracker: 5 alias sets for 4 pointer values. AliasSet[0xeb0e20,0] may alias, Mod/Ref 10 Call Sites: void ({ }*)* @llvm.dbg.func.start, void ({ }*, { }*)* @llvm.dbg.declare, void ({ }*, { }*)* @llvm.dbg.declare, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void ({ }*)* @llvm.dbg.region.end AliasSet[0xeb5a20,1] must alias, Mod/Ref Pointers: (i32** %XX, 8) AliasSet[0xebb210,1] must alias, Mod Pointers: (i32** %YY, 8) AliasSet[0xebabb0,1] must alias, Mod/Ref Pointers: (i32* %0, 4) AliasSet[0xebac10,1] must alias, Mod/Ref Pointers: (i32* %retval, 4) However, I am a little confused with these output. In Both anders-aa and steens-aa, XX and YY should stay in the same AliasSet, and their alias relationship should be May Alias, right? Sorry I am just a freshman to the alias analysis area, please shed some light on the understanding of the output formats. Best, Heming From eli.friedman at gmail.com Thu May 7 19:19:13 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 7 May 2009 17:19:13 -0700 Subject: [LLVMdev] Some questions on the output formats of AliasSetTracker In-Reply-To: <20090507200737.skmhln5yosokkgcw@cubmail.cc.columbia.edu> References: <20090507200737.skmhln5yosokkgcw@cubmail.cc.columbia.edu> Message-ID: On Thu, May 7, 2009 at 5:07 PM, wrote: > However, I am a little confused with these output. In Both anders-aa > and steens-aa, XX and YY should stay in the same AliasSet, and their > alias relationship should be May Alias, right? %XX and %YY are the results of alloca instructions (i.e. equivalent to the C expressions "&XX" and "&YY"), so they do not in fact alias. -Eli From keveman at gmail.com Thu May 7 19:27:39 2009 From: keveman at gmail.com (Manjunath Kudlur) Date: Thu, 7 May 2009 17:27:39 -0700 Subject: [LLVMdev] Question on tablegen In-Reply-To: <14072311-B382-463F-92BB-73DDC8E57F0C@apple.com> References: <68c4c3e20905052223v3143f7b7u892de3e156f87f9c@mail.gmail.com> <14072311-B382-463F-92BB-73DDC8E57F0C@apple.com> Message-ID: <68c4c3e20905071727x33a24b73k79b5c11cd42ab21b@mail.gmail.com> Dan, Thanks a lot. Using a modifier in the assembly string works for this case. I am trying to solve a related problem. I am trying to print out a set of "mov" ops for the vector_shuffle node. Since the source of the "mov" is from one of the sources to vector_shuffle, depending on the mask, I am not sure what assembly string to emit. For example, if I have d <- vector_shuffle s1, s2, <0,3> I want to emit mov d.x, s1.x mov d.y, s2.y For this, I need some thing like "mov $d.x, <$src1 or $src2>." I can use the same modifier trick for which component of the source to select, but I don't know how to select which of the sources to select ($src1 or $src2) depending on the mask. Do you have any suggestions? Thanks, Manjunath On Wed, May 6, 2009 at 10:10 AM, Dan Gohman wrote: > One way to do this is to handle this in the AsmPrinter, with > operand modifiers. > > For example, on x86 there are instructions with ${dst:call} in > their asm string. The "call" part is interpreted as an operand > modifier. The assembly printer looks for the "call" modifier > on MachineOperand::MO_Immediate operands > (in X86ATTAsmPrinter::printOperand), which lets it perform custom > printing for that type of operand. You could use a modifier which > tells the AsmPrinter to print an immediate as the appropriate > letter. > > Dan > > > On May 5, 2009, at 10:23 PM, Manjunath Kudlur wrote: > >> Hello, >> >> I am trying to create a machine instruction for "extractelement". I >> want to translate >> r <- extractelement v, 0 >> to >> mov r, v.x >> >> I was looking at the dag I can use and I found vector_extract. The >> inputs for this SDnode are a register and a iPtr constant. With that, >> I need to create 4 separate def's to extract element 0, 1, 2, and 3 >> and translate to v.x, v.y, v.z, and v.w. I was wondering if I can use >> the dag's 2nd input as an index into a list of strings and form the >> assembly instruction, something like !strconcat("mov $dst, v.", >> elemnames[$input]). I am still trying to learn the tablegen syntax and >> semantics, so how to do this is not clear to me. I will appreciate any >> suggestions on how to do this, or pointers to other places where >> similar things are done. >> >> Thanks, >> Manjunath >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From hc2428 at columbia.edu Thu May 7 19:29:25 2009 From: hc2428 at columbia.edu (hc2428 at columbia.edu) Date: Thu, 07 May 2009 20:29:25 -0400 Subject: [LLVMdev] Some questions on the output formats of AliasSetTracker In-Reply-To: References: <20090507200737.skmhln5yosokkgcw@cubmail.cc.columbia.edu> Message-ID: <20090507202925.i2vbwux1k0gckgk0@cubmail.cc.columbia.edu> Quoting Eli Friedman : Dear Eli, Thanks very much for your reply. I have modified the XX and YY to be global variables, but the output of AliasSetTracker are still MUST alias: Alias Set Tracker: 5 alias sets for 4 pointer values. AliasSet[0xea55d0,0] may alias, Mod/Ref 8 Call Sites: void ({ }*)* @llvm.dbg.func.start, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void ({ }*)* @llvm.dbg.region.end AliasSet[0xeb81e0,1] must alias, Mod/Ref Pointers: (i32** @XX, 8) AliasSet[0xea5fc0,1] must alias, Mod Pointers: (i32** @YY, 8) AliasSet[0xeab830,1] must alias, Mod/Ref Pointers: (i32* %0, 4) AliasSet[0xea5e70,1] must alias, Mod/Ref Pointers: (i32* %retval, 4) I am sure that the XX and YY are global: @XX = common global i32* null ; [#uses=4] @YY = common global i32* null ; [#uses=3] would you please tell me more details? Thanks, Heming > On Thu, May 7, 2009 at 5:07 PM, wrote: >> However, I am a little confused with these output. In Both anders-aa >> and steens-aa, XX and YY should stay in the same AliasSet, and their >> alias relationship should be May Alias, right? > > %XX and %YY are the results of alloca instructions (i.e. equivalent to > the C expressions "&XX" and "&YY"), so they do not in fact alias. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From nicholas.paul.johnson at gmail.com Thu May 7 19:58:23 2009 From: nicholas.paul.johnson at gmail.com (Nick Johnson) Date: Thu, 7 May 2009 20:58:23 -0400 Subject: [LLVMdev] Set alignment of a structure? In-Reply-To: <753162DD-BD87-4E03-83D5-BDD61E9E6D5A@apple.com> References: <0F5C6732-5968-4338-95FC-1EE72158301C@apple.com> <753162DD-BD87-4E03-83D5-BDD61E9E6D5A@apple.com> Message-ID: Chris, On Thu, May 7, 2009 at 7:20 PM, Chris Lattner wrote: > nd what you're saying. LLVM can and does already > express this, just in a different form. Why does this need to be in > the type? I misunderstood your earlier email. Now I understand. Setting alignment on a global variable will work for many of my needs. However, say I need to construct an array of OpaqueTypes; can I set an alignment on the elements of that array? For instance, is it possible to have an array where each element is forced to be a multiple of the cacheline size? Thank you again! -- Nick Johnson From Micah.Villmow at amd.com Thu May 7 20:19:01 2009 From: Micah.Villmow at amd.com (Villmow, Micah) Date: Thu, 7 May 2009 18:19:01 -0700 Subject: [LLVMdev] Question on tablegen In-Reply-To: <68c4c3e20905071727x33a24b73k79b5c11cd42ab21b@mail.gmail.com> References: <68c4c3e20905052223v3143f7b7u892de3e156f87f9c@mail.gmail.com><14072311-B382-463F-92BB-73DDC8E57F0C@apple.com> <68c4c3e20905071727x33a24b73k79b5c11cd42ab21b@mail.gmail.com> Message-ID: <493720826E33B1459E7F5C253E6D4BB50FFDC5@ssanexmb2.amd.com> Manjunath, I had a very similar problem and I solved it using a custom vector shuffle and addition instead of mov. For example, Vector_shuffle s1, s2, <0,3> is mapped to a custom instruction where I transform the swizzle to a 32bit integer mask and an inverted mask. So I have dst, src0, src1, imm1, imm2 And I have my asm look similar to: Add dst, src0.imm1, src1.imm2 and then in the asm printer I intercept vector_shuffle and I convert the integer to x,y,z,w, 0, 1 or _. For example if the mask is to take x from s1 and yzw from s2, I would generate 0x1000 and 0x0234. So my result looks like Iadd d0, s1.x000, s2.0yzw This allows you to do your vector shuffle in a single instruction. It's not the cleanest approach but it works for me and I can encode up to 8 swizzle per immediate so works on vector sizes up to 8 in length. Hope this helps, Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Manjunath Kudlur Sent: Thursday, May 07, 2009 5:28 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Question on tablegen Dan, Thanks a lot. Using a modifier in the assembly string works for this case. I am trying to solve a related problem. I am trying to print out a set of "mov" ops for the vector_shuffle node. Since the source of the "mov" is from one of the sources to vector_shuffle, depending on the mask, I am not sure what assembly string to emit. For example, if I have d <- vector_shuffle s1, s2, <0,3> I want to emit mov d.x, s1.x mov d.y, s2.y For this, I need some thing like "mov $d.x, <$src1 or $src2>." I can use the same modifier trick for which component of the source to select, but I don't know how to select which of the sources to select ($src1 or $src2) depending on the mask. Do you have any suggestions? Thanks, Manjunath On Wed, May 6, 2009 at 10:10 AM, Dan Gohman wrote: > One way to do this is to handle this in the AsmPrinter, with > operand modifiers. > > For example, on x86 there are instructions with ${dst:call} in > their asm string. The "call" part is interpreted as an operand > modifier. The assembly printer looks for the "call" modifier > on MachineOperand::MO_Immediate operands > (in X86ATTAsmPrinter::printOperand), which lets it perform custom > printing for that type of operand. You could use a modifier which > tells the AsmPrinter to print an immediate as the appropriate > letter. > > Dan > > > On May 5, 2009, at 10:23 PM, Manjunath Kudlur wrote: > >> Hello, >> >> I am trying to create a machine instruction for "extractelement". I >> want to translate >> r <- extractelement v, 0 >> to >> mov r, v.x >> >> I was looking at the dag I can use and I found vector_extract. The >> inputs for this SDnode are a register and a iPtr constant. With that, >> I need to create 4 separate def's to extract element 0, 1, 2, and 3 >> and translate to v.x, v.y, v.z, and v.w. I was wondering if I can use >> the dag's 2nd input as an index into a list of strings and form the >> assembly instruction, something like !strconcat("mov $dst, v.", >> elemnames[$input]). I am still trying to learn the tablegen syntax and >> semantics, so how to do this is not clear to me. I will appreciate any >> suggestions on how to do this, or pointers to other places where >> similar things are done. >> >> Thanks, >> Manjunath >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From mrs at apple.com Thu May 7 20:24:45 2009 From: mrs at apple.com (Mike Stump) Date: Thu, 7 May 2009 18:24:45 -0700 Subject: [LLVMdev] Darwin option processing Message-ID: I'm toying with building with -mdynamic-no-pic, but for this to work, the shared library bits in llvm can't be built with that flag. I've found that: Index: Makefile.rules =================================================================== --- Makefile.rules (revision 71041) +++ Makefile.rules (working copy) @@ -472,6 +476,9 @@ ifneq ($(DARWIN_MAJVERS),4) LD.Flags += $(RPATH) -Wl,$(LibDir) endif + ifeq ($(OS),Darwin) + EXTRA_OPTIONS := $(filter-out -mdynamic-no-pic,$(EXTRA_OPTIONS)) + endif endif ifdef TOOL_VERBOSE can be used to strip the option out in the places it won't work. This mirrors the style used in other parts of the file. If the experiment goes well, I'd like to check this in, if no objections. If someone wants to approve it (pending testing), let me know... From mrs at apple.com Thu May 7 20:29:24 2009 From: mrs at apple.com (Mike Stump) Date: Thu, 7 May 2009 18:29:24 -0700 Subject: [LLVMdev] new warnings Message-ID: <5038E985-FBC7-4A71-8E8A-0F76B6FCCBFD@apple.com> I discovered I needed: Index: lib/CodeGen/TwoAddressInstructionPass.cpp =================================================================== --- lib/CodeGen/TwoAddressInstructionPass.cpp (revision 71041) +++ lib/CodeGen/TwoAddressInstructionPass.cpp (working copy) @@ -935,6 +935,7 @@ ++NumReMats; } else { bool Emitted = TII->copyRegToReg(*mbbi, mi, regA, regB, rc, rc); + (void)Emitted; assert(Emitted && "Unable to issue a copy instruction! \n"); } in a release-asserts build to get around a warning: /Volumes/mrs5/net/clang/clang/clang/lib/CodeGen/ TwoAddressInstructionPass.cpp: In member function ?virtual bool::TwoAddressInstructionPass::runOnMachineFunction (llvm::MachineFunction&)?: /Volumes/mrs5/net/clang/clang/clang/lib/CodeGen/ TwoAddressInstructionPass.cpp:937: warning: unused variable ?Emitted? I can't recall if that is the recommended way to fix these types of errors, so I thought I'd ask here first. From clattner at apple.com Thu May 7 21:52:36 2009 From: clattner at apple.com (Chris Lattner) Date: Thu, 7 May 2009 19:52:36 -0700 Subject: [LLVMdev] Set alignment of a structure? In-Reply-To: References: <0F5C6732-5968-4338-95FC-1EE72158301C@apple.com> <753162DD-BD87-4E03-83D5-BDD61E9E6D5A@apple.com> Message-ID: <6ABEE567-B52A-444E-BC7E-BD12A196B5AC@apple.com> On May 7, 2009, at 5:58 PM, Nick Johnson wrote: > Chris, > > On Thu, May 7, 2009 at 7:20 PM, Chris Lattner > wrote: >> nd what you're saying. LLVM can and does already >> express this, just in a different form. Why does this need to be in >> the type? > > I misunderstood your earlier email. Now I understand. Setting > alignment on a global variable will work for many of my needs. > > However, say I need to construct an array of OpaqueTypes; can I set an > alignment on the elements of that array? For instance, is it possible > to have an array where each element is forced to be a multiple of the > cacheline size? I'm not sure what you mean: do you have a pointer to these, or do you have an array of pointers? Do you know the size of the elements? The compiler can't lay out a structure or array without knowing the size (not just the alignment) of the elements. -Chris From viridia at gmail.com Fri May 8 00:49:50 2009 From: viridia at gmail.com (Talin) Date: Thu, 07 May 2009 22:49:50 -0700 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> Message-ID: <4A03C7FE.5000206@gmail.com> Chris Lattner wrote: > On Dec 30, 2008, at 12:41 PM, Talin wrote: > >> I've been thinking about how to represent unions or "disjoint types" >> in LLVM IR. At the moment, the only way I know to achieve this right >> now is to create a struct that is as large as the largest type in >> the union and then bitcast it to access the fields contained within. >> However, that requires that the frontend know the sizes of all of >> the various low-level types (the "size_t" problem, which has been >> discussed before), otherwise you get problems trying to mix pointer >> and non-pointer types. >> > > That's an interesting point. As others have pointed out, we've > resisted having a union type because it isn't strictly needed for the > current set of front-ends. If a front-end is trying to generate > target-independent IR though, I can see the utility. The "gep trick" > won't work for type generation. > > >> It seems to me that adding a union type to the IR would be a logical >> extension to the language. The syntax for declaring a union would be >> similar to that of declaring a struct. To access a union member, you >> would use GetElementPointer, just as if it were a struct. The only >> difference is that in this case, the GEP doesn't actually modify the >> address, it merely returns the input argument as a different type. >> In all other ways, unions would be treated like structs, except that >> the size of the union would always be the size of the largest >> member, and all of the fields within the union would be located >> located at relative offset zero. >> > > Yes, your proposal makes sense, for syntax, I'd suggest: u{ i32, float} > > >> Unions could of course be combined with other types: >> >> {{int|float}, bool} * >> n = getelementptr i32 0, i32 0, i32 1 >> >> So in the above example, the GEP returns a pointer to the float field. >> > > I don't have a specific problem with adding this. The cost of doing > so is that it adds (a small amount of) complexity to a lot of places > that walk the type graphs. The only pass that I predict will be > difficult to update to handle this is the BasicAA pass, which reasons > about symbolic (not concrete) offsets and should return mustalias in > the appropriate cases. Also, to validate this, I think llvm-gcc > should start generating this for C unions where possible. > > If you're interested in implementing this and seeing all the details > of the implementation through to the end, I don't see significant > problems. I think adding a simple union type would make more sense > than adding first-class support for a *discriminated* union. > So, I spent a little bit of time looking at how to code this. Rather than defining a brand-new LLVM type, I think the best approach is to generalize the existing StructType. We can change the "isPacked" flag (which is stored in the SubclassData of the type) to a 3-valued enum called StructLayout, which has 3 members: UnpackedLayout, PackedLayout, and UnionLayout. After that, it's mostly a case of hunting down everywhere that calls "isPacked", and adding the appropriate case. :) > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From nicholas at mxc.ca Fri May 8 01:10:09 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Thu, 07 May 2009 23:10:09 -0700 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <4A03C7FE.5000206@gmail.com> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> <4A03C7FE.5000206@gmail.com> Message-ID: <4A03CCC1.6040001@mxc.ca> Talin wrote: > Chris Lattner wrote: >> On Dec 30, 2008, at 12:41 PM, Talin wrote: >> >>> I've been thinking about how to represent unions or "disjoint types" >>> in LLVM IR. At the moment, the only way I know to achieve this right >>> now is to create a struct that is as large as the largest type in >>> the union and then bitcast it to access the fields contained within. >>> However, that requires that the frontend know the sizes of all of >>> the various low-level types (the "size_t" problem, which has been >>> discussed before), otherwise you get problems trying to mix pointer >>> and non-pointer types. >>> >> That's an interesting point. As others have pointed out, we've >> resisted having a union type because it isn't strictly needed for the >> current set of front-ends. If a front-end is trying to generate >> target-independent IR though, I can see the utility. The "gep trick" >> won't work for type generation. >> >> >>> It seems to me that adding a union type to the IR would be a logical >>> extension to the language. The syntax for declaring a union would be >>> similar to that of declaring a struct. To access a union member, you >>> would use GetElementPointer, just as if it were a struct. The only >>> difference is that in this case, the GEP doesn't actually modify the >>> address, it merely returns the input argument as a different type. >>> In all other ways, unions would be treated like structs, except that >>> the size of the union would always be the size of the largest >>> member, and all of the fields within the union would be located >>> located at relative offset zero. >>> >> Yes, your proposal makes sense, for syntax, I'd suggest: u{ i32, float} >> >> >>> Unions could of course be combined with other types: >>> >>> {{int|float}, bool} * >>> n = getelementptr i32 0, i32 0, i32 1 >>> >>> So in the above example, the GEP returns a pointer to the float field. >>> >> I don't have a specific problem with adding this. The cost of doing >> so is that it adds (a small amount of) complexity to a lot of places >> that walk the type graphs. The only pass that I predict will be >> difficult to update to handle this is the BasicAA pass, which reasons >> about symbolic (not concrete) offsets and should return mustalias in >> the appropriate cases. Also, to validate this, I think llvm-gcc >> should start generating this for C unions where possible. >> >> If you're interested in implementing this and seeing all the details >> of the implementation through to the end, I don't see significant >> problems. I think adding a simple union type would make more sense >> than adding first-class support for a *discriminated* union. >> > So, I spent a little bit of time looking at how to code this. Rather > than defining a brand-new LLVM type, I think the best approach is to > generalize the existing StructType. We can change the "isPacked" flag > (which is stored in the SubclassData of the type) to a 3-valued enum > called StructLayout, which has 3 members: UnpackedLayout, PackedLayout, > and UnionLayout. > > After that, it's mostly a case of hunting down everywhere that calls > "isPacked", and adding the appropriate case. :) Hi Talin, thanks for looking in to this. I think there's already a lot of code that makes the assumption that the different members of a StructType represent distinct storage. Why is it easier to co-opt StructType than to create a new 'UnionType' under CompositeType? What's the tradeoff? Nick From andrii.vasyliev at gmail.com Fri May 8 03:40:12 2009 From: andrii.vasyliev at gmail.com (Andrii Vasyliev) Date: Fri, 8 May 2009 11:40:12 +0300 Subject: [LLVMdev] Automake and llvm-config Message-ID: Hello, I'm using autotools to build my little lang. So I want to have something like this in my Makefile.am: mylang_SOURCES = mylang.cpp mylang_LDADD = mylib.a `llvm-config --cppflags --ldflags --libs core jit native ipo` But automake complains: tools/Makefile.am:8: linker flags such as `--cppflags' belong in `mylang_LDFLAGS I tried different workarounds but nothing helps :( The only way I found is to copy llvm-config's output directly to Makefile.am which is non-portable. So actually the question is how to use backticks in Makefile.am, but I posted it here because I hope everybody has already solved the problem :) Thanks, Andrii From gordonhenriksen at me.com Fri May 8 05:01:57 2009 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Fri, 08 May 2009 06:01:57 -0400 Subject: [LLVMdev] Automake and llvm-config In-Reply-To: References: Message-ID: <2E7D2B3B-BB07-478A-AD3A-B02F2D21D326@me.com> Can you use an intermediate variable? TMP = `...` mylang_LDADD = ... $TMP On 2009-05-08, at 04:40, Andrii Vasyliev wrote: > Hello, > > I'm using autotools to build my little lang. > So I want to have something like this in my Makefile.am: > > mylang_SOURCES = mylang.cpp > mylang_LDADD = mylib.a `llvm-config --cppflags --ldflags --libs core > jit native ipo` > > But automake complains: > tools/Makefile.am:8: linker flags such as `--cppflags' belong in > `mylang_LDFLAGS > > I tried different workarounds but nothing helps :( > The only way I found is to copy llvm-config's output directly to > Makefile.am which > is non-portable. > So actually the question is how to use backticks in Makefile.am, but I > posted it here > because I hope everybody has already solved the problem :) > > Thanks, > Andrii > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From ksh.cseiitk at gmail.com Fri May 8 06:07:19 2009 From: ksh.cseiitk at gmail.com (Kshitiz Garg) Date: Fri, 8 May 2009 16:37:19 +0530 Subject: [LLVMdev] problem with analysis required Message-ID: <13da638f0905080407n6d2a1be7k9a451070fc65ed30@mail.gmail.com> Hello, I was trying to get the loop info in a module pass to be able to iterate over the loops int the module itself. Since my pass requires to make module level changes including adding new types to module hence a looppass cannot be used here. I am getting the following error on running opt. opt: /root/llvm-2.4/include/llvm/PassAnalysisSupport.h:199: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = llvm::LoopInfo]: Assertion `ResultPass && "getAnalysis*() called on an analysis that was not " "'required' by pass!"' failed. #4 0x083006f2 in llvm::Pass::getAnalysisID (this=0x86cfc48, PI=0x86cbfe0) at /root/llvm-2.4/include/llvm/PassAnalysisSupport.h:197 #5 0x083007aa in llvm::Pass::getAnalysis (this=0x86cfc48) at /root/llvm-2.4/include/llvm/PassAnalysisSupport.h:186 #6 0x0056e1c0 in runOnModule (this=0x86cfc48, M=@0x86cfeb8) at timing.cpp:167 gdb backtrace points to the following statement in the runOnModule method; Loopinfo * LI = &getAnalysis(); following is the content of the getAnalysis Usage method. void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired (); AU.addPreserved (); } I picked this from the LPPassManager class which has a similar structure and its runOnFunction iterates over loop list from LoopInfo. I think I am missing some line to add. Can someone please point out the cause of the error?? Thanks regards, Kshitiz -- Kshitiz Garg Graduate Student Department of Computer Science & Engineering IIT Kanpur http://home.iitk.ac.in/~kshitizg From andrii.vasyliev at gmail.com Fri May 8 06:59:30 2009 From: andrii.vasyliev at gmail.com (Andrii Vasyliev) Date: Fri, 8 May 2009 14:59:30 +0300 Subject: [LLVMdev] Automake and llvm-config In-Reply-To: <2E7D2B3B-BB07-478A-AD3A-B02F2D21D326@me.com> References: <2E7D2B3B-BB07-478A-AD3A-B02F2D21D326@me.com> Message-ID: I tried it - doesn't work. Automake just passes exact value of variable into mylang_LDADD without calculation, and produces the same error message. Also I tried this: TMP = $(shell llvm-config ...) Doesn't work. 2009/5/8 Gordon Henriksen : > Can you use an intermediate variable? > > TMP = `...` > mylang_LDADD = ... $TMP From torvald at se.inf.tu-dresden.de Fri May 8 07:03:34 2009 From: torvald at se.inf.tu-dresden.de (Torvald Riegel) Date: Fri, 8 May 2009 14:03:34 +0200 Subject: [LLVMdev] How to use the PoolDescriptor in ds-aa alias analysis? In-Reply-To: <20090507194149.xnehlb7aoo04o404@cubmail.cc.columbia.edu> References: <20090507194149.xnehlb7aoo04o404@cubmail.cc.columbia.edu> Message-ID: <200905081403.35165.torvald@se.inf.tu-dresden.de> On Friday 08 May 2009, hc2428 at columbia.edu wrote: > Dear Staff, > I am reading the paper "Making Context-sensitive Points-to > Analysis with Heap Cloning Practical For The Real World", and I build > the poolalloc module, and run the program in Figure 1 in this paper > with -ds-aa alias analysis. Now I know that X and Y in the program > would have distinct PoolDescriptors to make them disjoint data > structures. > However, how can we use the PoolDescriptor? What is storing in > it? It seems that the PoolDescriptor in the program is just parsed as > an argument from top to down, but it is not modified, so I am a little > confused. Pool descriptors get allocated before the data in the pool starts to exist. After that, pointers to those pool descriptors get passed around. If you are the only poolalloc user, then you can use the pools in any way you want. If you just want an ID for a pool, it should be safe to not release pools and just return unique pointers from the pool allocator. Torvald From jvb at wongr.net Fri May 8 07:31:45 2009 From: jvb at wongr.net (Julian v. Bock) Date: Fri, 08 May 2009 14:31:45 +0200 Subject: [LLVMdev] Automake and llvm-config In-Reply-To: (Andrii Vasyliev's message of "Fri, 8 May 2009 11:40:12 +0300") References: Message-ID: Hi >>>>> "AV" == Andrii Vasyliev writes: AV> Hello, I'm using autotools to build my little lang. So I want to AV> have something like this in my Makefile.am: AV> mylang_SOURCES = mylang.cpp mylang_LDADD = mylib.a `llvm-config AV> --cppflags --ldflags --libs core jit native ipo` AV> But automake complains: tools/Makefile.am:8: linker flags such as AV> `--cppflags' belong in `mylang_LDFLAGS You can use AC_SUBST in configure.ac to set the flags at configure time. I use something like this: AC_SUBST(LLVM_CPPFLAGS, $(llvm-config --cppflags)) AC_SUBST(LLVM_LDADD, $(llvm-config --ldflags --libs core jit native | tr '\n' ' ')) and in Makefile.am: foo_LDADD = $(LLVM_LDADD) ... ... Regards, Julian v. Bock From edwintorok at gmail.com Fri May 8 07:45:30 2009 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Fri, 08 May 2009 15:45:30 +0300 Subject: [LLVMdev] Automake and llvm-config In-Reply-To: References: Message-ID: <4A04296A.4070307@gmail.com> On 2009-05-08 11:40, Andrii Vasyliev wrote: > Hello, > > I'm using autotools to build my little lang. > So I want to have something like this in my Makefile.am: > > mylang_SOURCES = mylang.cpp > mylang_LDADD = mylib.a `llvm-config --cppflags --ldflags --libs core > jit native ipo` > > But automake complains: > tools/Makefile.am:8: linker flags such as `--cppflags' belong in `mylang_LDFLAGS > Why not do what automake told you to do? mylang_LDFLAGS=`llvm-config --ldflags core` mylang_LDADD=mylib.a `llvm-config --libs core` AM_CPPFLAGS=`llvm-config --cppflags` Best regards, --Edwin From nicholas.paul.johnson at gmail.com Fri May 8 09:18:51 2009 From: nicholas.paul.johnson at gmail.com (Nick Johnson) Date: Fri, 8 May 2009 10:18:51 -0400 Subject: [LLVMdev] Set alignment of a structure? In-Reply-To: <6ABEE567-B52A-444E-BC7E-BD12A196B5AC@apple.com> References: <0F5C6732-5968-4338-95FC-1EE72158301C@apple.com> <753162DD-BD87-4E03-83D5-BDD61E9E6D5A@apple.com> <6ABEE567-B52A-444E-BC7E-BD12A196B5AC@apple.com> Message-ID: Chris, > I'm not sure what you mean: do you have a pointer to these, or do you > have an array of pointers? Do you know the size of the elements? The > compiler can't lay out a structure or array without knowing the size > (not just the alignment) of the elements. I can think of three cases that are important to my research, detailed below. [1] is solved by global variable alignment; [2] is hacked and working, through type-alignment---not storage-location alignment---would make it easier; [3] is unsolved, and we use a sub-optimal work-around. One could summarize all three cases succinctly with a simple question: should alignment be an aspect of a storage location, or of a type? In llvm, it appears to be an aspect of a storage location. But I think it should be an aspect of the type. (Case 1) There is some set of values V that we wish to transfer from one thread to another. The size and types of V can only be known at compile time. We want to create a corresponding type struct.V to carry those values. In our situation, several threads will be writing to its own structure simultaneously. By aligning the structures to cacheline boundaries, we can ensure that no two of these structures occupy the same cacheline, and so no two threads are competing for that cacheline. As you noted, this case can be handled by setting an alignment on a global variable. (Case 2) We have a group of closely related threads, all running the same code, but parameterized with some integer instance number. Just like the previous case, these threads need to communicate some set of values. When they write their values, they can use their instance number to index into an array of struct.V's. But, say two threads i and i+1 are both trying to write to the array. I would like to ensure that array[i] and array[i+1] lay in different cachelines. The only way to guarantee that is if each /element/ of the array is cacheline aligned. In other words, I am not trying to align the global variable (the array) to a cacheline, rather its elements. I accomplish this by first making an assumption about cacheline size, and then adding a char[] padding element to the structure type. I'd rather set alignment on the element type. (Case 3) We have a group of closely related threads, all running the same code, but parameterized with some integer instance number. Additionally, we use some external library to provide an inter-thread communication facility. Each thread must have a distinct handle object for that library. The handle objects are complicated: many fields, many alignment rules, etc. Also, as our research has progressed, the internal structure of the handle object has been revised several times. For these reasons, we would like to maintain the handle-type in llvm as an Opaque type. Also, initialization of these handle objects is relatively slow. A comparison could be made to a thread pool: you initialize a pool when you start your program so you don't have to pay the thread-spawn penalty inside a hot loop. For this reason, we initializie the handles within static constructors. Therefore, we cannot easily place them in thread-local storage. A global variable is the natural place to put them. I would like to create an array of handles so that the threads can simply index into the array by their instance number. Like before, I want to guarantee that if two threads i and i+1 try to access their handles in the handles array, that handles[i] and handles[i+1] do not share a cacheline. In this case, I cannot even manually pad the arrays, because I cannot determine the size of the OpaqueType handle. Ideally, I want to tell llvm that, no matter how big or small a handle is, it should ensure that each element of the array is a multiple of cacheline size. Again, this is an alignment property of the array /element/ type, not of the array storage location. To work around this, we must use pointers to handles, and store those pointers within structures that have been padded to a cacheline size. Again, that's 8-bytes of pointer, and 120-bytes of padding. Additionally, this forces us to dynamically allocate storage for the handles, even though I'd prefer to have them statically allocated. I'd really appreciate to hear your thoughts on this matter. Or, maybe I'm missing some obvious solution... -- Nick Johnson From criswell at cs.uiuc.edu Fri May 8 09:22:47 2009 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri, 8 May 2009 09:22:47 -0500 Subject: [LLVMdev] problem with analysis required In-Reply-To: <13da638f0905080407n6d2a1be7k9a451070fc65ed30@mail.gmail.com> References: <13da638f0905080407n6d2a1be7k9a451070fc65ed30@mail.gmail.com> Message-ID: <4A044037.2050203@cs.uiuc.edu> Kshitiz Garg wrote: > Hello, > I was trying to get the loop info in a module pass to be able to > iterate over the loops int the module itself. Since my pass requires > to make module level changes including adding new types to module > hence a looppass cannot be used here. > I am getting the following error on running opt. > > opt: /root/llvm-2.4/include/llvm/PassAnalysisSupport.h:199: > AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const > [with AnalysisType = llvm::LoopInfo]: Assertion `ResultPass && > "getAnalysis*() called on an analysis that was not " "'required' by > pass!"' failed. > > > #4 0x083006f2 in llvm::Pass::getAnalysisID (this=0x86cfc48, > PI=0x86cbfe0) at /root/llvm-2.4/include/llvm/PassAnalysisSupport.h:197 > #5 0x083007aa in llvm::Pass::getAnalysis (this=0x86cfc48) > at /root/llvm-2.4/include/llvm/PassAnalysisSupport.h:186 > #6 0x0056e1c0 in runOnModule (this=0x86cfc48, M=@0x86cfeb8) at timing.cpp:167 > > gdb backtrace points to the following statement in the runOnModule method; > Loopinfo * LI = &getAnalysis(); > I believe the problem here is that you need to specify the function for which you want loop information in the above call, i.e.: Loopinfo * LI = &getAnalysis(F) ... where F is either a pointer to the Function or is a reference to the Function (I don't recall the details off-hand; see http://llvm.org/docs/WritingAnLLVMPass.html#getAnalysis for more information. You said that your pass needs to make some global modification to the Module. In some cases, you can still write your pass as a FunctionPass; simply put the code that changes global Module information into the doInitialization() or doFinalization() methods. -- John T. > following is the content of the getAnalysis Usage method. > > void getAnalysisUsage(AnalysisUsage &AU) const { > AU.addRequired (); > AU.addPreserved (); > } > > I picked this from the LPPassManager class which has a similar > structure and its runOnFunction iterates over loop list from LoopInfo. > > I think I am missing some line to add. Can someone please point out > the cause of the error?? > > Thanks > regards, > Kshitiz > -- > Kshitiz Garg > Graduate Student > Department of Computer Science & Engineering > IIT Kanpur > http://home.iitk.ac.in/~kshitizg > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From e0325716 at student.tuwien.ac.at Fri May 8 10:05:01 2009 From: e0325716 at student.tuwien.ac.at (Andreas Neustifter) Date: Fri, 08 May 2009 17:05:01 +0200 Subject: [LLVMdev] problem with analysis required In-Reply-To: <13da638f0905080407n6d2a1be7k9a451070fc65ed30@mail.gmail.com> References: <13da638f0905080407n6d2a1be7k9a451070fc65ed30@mail.gmail.com> Message-ID: <4A044A1D.6040702@student.tuwien.ac.at> Hi, Kshitiz Garg wrote: > Hello, > I was trying to get the loop info in a module pass to be able to > iterate over the loops int the module itself. Since my pass requires > to make module level changes including adding new types to module > hence a looppass cannot be used here. > I am getting the following error on running opt. > > opt: /root/llvm-2.4/include/llvm/PassAnalysisSupport.h:199: > AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const > [with AnalysisType = llvm::LoopInfo]: Assertion `ResultPass && > "getAnalysis*() called on an analysis that was not " "'required' by > pass!"' failed. > > > #4 0x083006f2 in llvm::Pass::getAnalysisID (this=0x86cfc48, > PI=0x86cbfe0) at /root/llvm-2.4/include/llvm/PassAnalysisSupport.h:197 > #5 0x083007aa in llvm::Pass::getAnalysis (this=0x86cfc48) > at /root/llvm-2.4/include/llvm/PassAnalysisSupport.h:186 > #6 0x0056e1c0 in runOnModule (this=0x86cfc48, M=@0x86cfeb8) at timing.cpp:167 > > gdb backtrace points to the following statement in the runOnModule method; > Loopinfo * LI = &getAnalysis(); > > following is the content of the getAnalysis Usage method. > > void getAnalysisUsage(AnalysisUsage &AU) const { > AU.addRequired (); > AU.addPreserved (); > } > > I picked this from the LPPassManager class which has a similar > structure and its runOnFunction iterates over loop list from LoopInfo. > > I think I am missing some line to add. Can someone please point out > the cause of the error?? Funny enough I stumbled over the same problem right now. I have no solution either but I will post a follow-up if I find something out. Andi From vadve at cs.uiuc.edu Fri May 8 10:05:15 2009 From: vadve at cs.uiuc.edu (Vikram S. Adve) Date: Fri, 8 May 2009 10:05:15 -0500 Subject: [LLVMdev] How to use the PoolDescriptor in ds-aa alias analysis? In-Reply-To: <200905081403.35165.torvald@se.inf.tu-dresden.de> References: <20090507194149.xnehlb7aoo04o404@cubmail.cc.columbia.edu> <200905081403.35165.torvald@se.inf.tu-dresden.de> Message-ID: <6237778F-1433-4EC7-996A-662A58181117@cs.uiuc.edu> On May 8, 2009, at 7:03 AM, Torvald Riegel wrote: > On Friday 08 May 2009, hc2428 at columbia.edu wrote: >> Dear Staff, >> I am reading the paper "Making Context-sensitive Points-to >> Analysis with Heap Cloning Practical For The Real World", and I build >> the poolalloc module, and run the program in Figure 1 in this paper >> with -ds-aa alias analysis. Now I know that X and Y in the program >> would have distinct PoolDescriptors to make them disjoint data >> structures. >> However, how can we use the PoolDescriptor? What is storing in >> it? It seems that the PoolDescriptor in the program is just parsed as >> an argument from top to down, but it is not modified, so I am a >> little >> confused. > > Pool descriptors get allocated before the data in the pool starts to > exist. > After that, pointers to those pool descriptors get passed around. If > you are > the only poolalloc user, then you can use the pools in any way you > want. If > you just want an ID for a pool, it should be safe to not release > pools and > just return unique pointers from the pool allocator. And if you are only interested in the alias analysis client you mentioned (-ds-aa), then you don't need to run the pool allocation transformation at all. That's just another client that gives you a *run-time* representation of the points-to sets. > > > Torvald > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From andrii.vasyliev at gmail.com Fri May 8 10:10:09 2009 From: andrii.vasyliev at gmail.com (Andrii Vasyliev) Date: Fri, 8 May 2009 18:10:09 +0300 Subject: [LLVMdev] Automake and llvm-config In-Reply-To: References: Message-ID: Thanks Julian, this is what I was looking for :) From viridia at gmail.com Fri May 8 12:07:02 2009 From: viridia at gmail.com (Talin) Date: Fri, 08 May 2009 10:07:02 -0700 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <4A03CCC1.6040001@mxc.ca> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> <4A03C7FE.5000206@gmail.com> <4A03CCC1.6040001@mxc.ca> Message-ID: <4A0466B6.3060502@gmail.com> Nick Lewycky wrote: > Hi Talin, thanks for looking in to this. > > I think there's already a lot of code that makes the assumption that the > different members of a StructType represent distinct storage. Why is it > easier to co-opt StructType than to create a new 'UnionType' under > CompositeType? What's the tradeoff? > Well, from a pure lines-of-code perspective, the struct and union types share about 90% of their implementation, and it seemed wrong to duplicate that code. I thought about factoring out a common base class, however that seemed more disruptive to the code base than I really wanted to deal with. However, I haven't really looked into the parts of LLVM that actually do the analysis. (I'm mostly a front-end guy.) So I don't yet understand how much trouble such a change would cause. > Nick > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From clattner at apple.com Fri May 8 12:23:08 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 8 May 2009 10:23:08 -0700 Subject: [LLVMdev] Set alignment of a structure? In-Reply-To: References: <0F5C6732-5968-4338-95FC-1EE72158301C@apple.com> <753162DD-BD87-4E03-83D5-BDD61E9E6D5A@apple.com> <6ABEE567-B52A-444E-BC7E-BD12A196B5AC@apple.com> Message-ID: <6DEE1199-7FD3-4182-A271-FA7E7FCABFE8@apple.com> On May 8, 2009, at 7:18 AM, Nick Johnson wrote: > I would like to create an array of handles so that the threads can > simply index into the array by their instance number. Like before, I > want to guarantee that if two threads i and i+1 try to access their > handles in the handles array, that handles[i] and handles[i+1] do not > share a cacheline. > > In this case, I cannot even manually pad the arrays, because I cannot > determine the size of the OpaqueType handle. Ideally, I want to tell > llvm that, no matter how big or small a handle is, it should ensure > that each element of the array is a multiple of cacheline size. > Again, this is an alignment property of the array /element/ type, not > of the array storage location. I don't think you need to do anything fancy here, just pass the size of the struct as a symbolic variable value. Given that, you can use something like: void *P = base_of_array; P = (char*)P + threadno*handlesize; The code that sets up the handles array just needs to make sure that handlesize is a multiple of the cache line size. -Chris From clattner at apple.com Fri May 8 12:25:47 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 8 May 2009 10:25:47 -0700 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <4A011842.3030702@gmail.com> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> <4A00FF67.4090500@gmail.com> <0B6805BD-85B8-460F-B35C-8656D26C01A2@apple.com> <4A011842.3030702@gmail.com> Message-ID: <1187D7FA-1A46-404C-B506-9F1349203AD0@apple.com> On May 5, 2009, at 9:55 PM, Talin wrote: >>> (So >>> that the frontend doesn't need to know how big a pointer is and can >>> generate the same IR that works on both 32-bit and 64-bit >>> platforms.) >>> >> >> Why not just use a pointer, such as i8*? >> > Suppose I have an STL-like container that has a 'begin' and 'end' > pointer. Now I want to find the size() of the container. Since you > cannot subtract pointers in LLVM IR, you have to cast them to an > integer > type first. But what integer type do you cast them to? I suppose you > could simply always cast them to i64, and hope that the backend will > generate efficient code for the subtraction, but I have no way of > knowing this. What do you intend to do with this size? At some point you have to do an operation that depends on the size. The problem with adding an intptr_t is that at some point you have to convert it to another datatype, and you don't know whether it will be a zext/trunc/bitcast etc. > Now, I'm going to anticipate what I think will be your next argument, > which is that at some point I must know the size of the result since I > am assigning the result of size() to some interger variable > eventually. yes :) > Which is true, however, if the size of that eventual variable is > smaller > than a pointer, then I want to check it for overflow before I do the > assignment. I don't want to just do a blind bitcast and have the top > bits be lopped off. But you don't know if it will be smaller or larger. -Chris From clattner at apple.com Fri May 8 12:33:22 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 8 May 2009 10:33:22 -0700 Subject: [LLVMdev] Installing tbgen with llvm by default. In-Reply-To: <4A027F8D.2020104@tut.fi> References: <682D1598-44D2-4CE1-AD28-113F0B5B9F06@tut.fi> <282C680B-D934-44E6-BA94-361B8DAAAF08@apple.com> <4A027F8D.2020104@tut.fi> Message-ID: <3EFDD90D-9640-4A41-A46C-91019557C37F@apple.com> On May 6, 2009, at 11:28 PM, Mikael Lepist? wrote: > Chris Lattner wrote: >> >> On May 4, 2009, at 11:03 PM, Mikael Lepist? wrote: >> >>> Hi, >>> >>> Would it be possible to set tbgen to be installed with llvm? For >>> our project http://llvm.org/ProjectsWithLLVM/#tta-tce it would be >>> very helpful, because our tools generate compiler backend plugins >>> in the fly for each customized processor and plugin generation >>> needs tbgen for handling td files. >> >> Sure, would you care to prepare a patch? >> >> -Chris > Great! > > Hope that this patch will do. I removed util dir from install filter- > out list, added NO_INSTALL = 1 to googletest Makefile and removed > NO_INSTALL define from tblgen. Thanks, applied here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090504/077258.html -Chris From sricketts at maxentric.com Fri May 8 13:34:21 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Fri, 8 May 2009 11:34:21 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905052126.59153.baldrick@free.fr> <6d9073030905051324w3c2d7f83s792e6584e175906f@mail.gmail.com> <200905060833.21433.baldrick@free.fr> <6d9073030905061222k14ccfe9dlc90860bccc9e57d9@mail.gmail.com> <1241639473.18321.66.camel@aslstation> <6d9073030905061326u6443401bj8699bde90ada4347@mail.gmail.com> Message-ID: <6d9073030905081134x5b43e96pf79b483695d8325a@mail.gmail.com> Unfortunately I still have yet to successfully install llvm. On Wed, May 6, 2009 at 2:32 PM, Anton Korobeynikov wrote: > That's correct. Since you have everything linked as shared libraries > system dynamic linker will pick the shared library installed in the > default library location. Most probably you will need to edit > /etc/ld.so.conf and put the gcc 4.2.4 library path there *before* > system compiler one and rerun "ldconfig" (from root).... I added the gcc 4.2.4 library paths to /etc/ld.so.conf, then ran ldconfig. Then I: configured llvm: $ ../llvm/configure --prefix=/pkg/bin/llvm built llvm: $ make -j15 configured llvm-gcc: $ ../llvm-gcc/configure --prefix=/pkg/build/llvm/install --program-prefix=llvm- --enable-llvm=/pkg/build/llvm/llvm-obj --enable-languages=c,c++ attempted to build llvm-gcc: $ make -j15 ... cc1: /pkg/build/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:511: bool::SCEVComplexityCompare::operator()(const llvm::SCEV*, const llvm::SCEV*) const: Assertion `0 && "Unknown SCEV kind!"' failed. ../../llvm-gcc/libdecnumber/decNumber.c:5591: internal compiler error: Aborted This is all with llvm and llvm-gcc source from svn. I have tried gcc-4.2.4 and gcc-4.3.2. ENABLE_OPTIMIZED=1 only seems to work with gcc-4.3.2. Here is the error when I try to build llvm with gcc-4.2.4 with ENABLE_OPTIMIZED=1: `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of /pkg/build/llvm/llvm-obj/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of /pkg/build/llvm/llvm-obj/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o) collect2: ld returned 1 exit status make[2]: *** [/pkg/build/llvm/llvm-obj/Release/lib/libLTO.so] Error 1 make[2]: Leaving directory `/pkg/build/llvm/llvm-obj/tools/lto' I have also tried installing with the llvm-gcc binary for RHEL4 (even though I am running Centos 5). However, "make check" returned a bunch of unexpected failures. Any suggestions? Thanks, Scott From clattner at apple.com Fri May 8 13:49:33 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 8 May 2009 11:49:33 -0700 Subject: [LLVMdev] Darwin option processing In-Reply-To: References: Message-ID: On May 7, 2009, at 6:24 PM, Mike Stump wrote: > I'm toying with building with -mdynamic-no-pic, but for this to work, > the shared library bits in llvm can't be built with that flag. Hi Mike, If you're doing this for Clang's benefit, I think the best thing to do is to compile LLVM PIC (the default) and then build the clang front- end pieces with -mdynamic-no-pic. Does this work for you? -Chris > > > I've found that: > > Index: Makefile.rules > =================================================================== > --- Makefile.rules (revision 71041) > +++ Makefile.rules (working copy) > @@ -472,6 +476,9 @@ > ifneq ($(DARWIN_MAJVERS),4) > LD.Flags += $(RPATH) -Wl,$(LibDir) > endif > + ifeq ($(OS),Darwin) > + EXTRA_OPTIONS := $(filter-out -mdynamic-no-pic,$(EXTRA_OPTIONS)) > + endif > endif > > ifdef TOOL_VERBOSE > > > can be used to strip the option out in the places it won't work. This > mirrors the style used in other parts of the file. If the experiment > goes well, I'd like to check this in, if no objections. If someone > wants to approve it (pending testing), let me know... > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From mrs at apple.com Fri May 8 14:58:24 2009 From: mrs at apple.com (Mike Stump) Date: Fri, 8 May 2009 12:58:24 -0700 Subject: [LLVMdev] Darwin option processing In-Reply-To: References: Message-ID: <9B56655C-69E2-410C-B63C-858785289F11@apple.com> On May 8, 2009, at 11:49 AM, Chris Lattner wrote: > On May 7, 2009, at 6:24 PM, Mike Stump wrote: >> I'm toying with building with -mdynamic-no-pic, but for this to work, >> the shared library bits in llvm can't be built with that flag. > > Hi Mike, > > If you're doing this for Clang's benefit, No, not really, I'm doing it for the general benefit of llvm and all that use Makefile.rules. > I think the best thing to do > is to compile LLVM PIC (the default) and then build the clang front- > end pieces with -mdynamic-no-pic. Does this work for you? The proposed patch is more general that that. It avoids the flag, when it is known it can't work, and leaves it in otherwise. This allows the configurer of llvm to make the choice. Longer term, I'd like to have the build system default to this, as appropriate. This patch is merely a bridge until that patch is in. If you'd prefer that patch instead, I could just do that one up. My only reservation is that a change like that precedes the testing I'd rather have on it before I did the flip. The other patch would look something like this: Index: Makefile.rules =================================================================== --- Makefile.rules (revision 71041) +++ Makefile.rules (working copy) @@ -245,6 +245,13 @@ OmitFramePointer := -fomit-frame-pointer endif endif + ifndef LOADABLE_MODULE + ifndef SHARED_LIBRARY + ifeq ($(OS),Darwin) + DynamicNoPic := -mdynamic-no-pic + endif + endif + endif # Darwin requires -fstrict-aliasing to be explicitly enabled. # Avoid -fstrict-aliasing on Darwin for now, there are unresolved issues @@ -252,8 +259,8 @@ #ifeq ($(OS),Darwin) # EXTRA_OPTIONS += -fstrict-aliasing -Wstrict-aliasing #endif - CXX.Flags += $(OPTIMIZE_OPTION) $(OmitFramePointer) - C.Flags += $(OPTIMIZE_OPTION) $(OmitFramePointer) + CXX.Flags += $(OPTIMIZE_OPTION) $(OmitFramePointer) $(DynamicNoPic) + C.Flags += $(OPTIMIZE_OPTION) $(OmitFramePointer) $(DynamicNoPic) LD.Flags += $(OPTIMIZE_OPTION) else BuildMode := Debug Thoughts? From clattner at apple.com Fri May 8 15:02:53 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 8 May 2009 13:02:53 -0700 Subject: [LLVMdev] Darwin option processing In-Reply-To: <9B56655C-69E2-410C-B63C-858785289F11@apple.com> References: <9B56655C-69E2-410C-B63C-858785289F11@apple.com> Message-ID: On May 8, 2009, at 12:58 PM, Mike Stump wrote: >> I think the best thing to do >> is to compile LLVM PIC (the default) and then build the clang front- >> end pieces with -mdynamic-no-pic. Does this work for you? > > The proposed patch is more general that that. It avoids the flag, > when it is known it can't work, and leaves it in otherwise. This > allows the configurer of llvm to make the choice. Longer term, I'd > like to have the build system default to this, as appropriate. This > patch is merely a bridge until that patch is in. If you'd prefer that > patch instead, I could just do that one up. My only reservation is > that a change like that precedes the testing I'd rather have on it > before I did the flip. This goes against our general direction for llvm libraries: they should generally all be built pic. This is because we don't know how they will be linked in. For example, anything that links into liblto or llvm-gcc (on the mac) get stuck into dylibs. > The other patch would look something like this: > > Index: Makefile.rules > =================================================================== > --- Makefile.rules (revision 71041) > +++ Makefile.rules (working copy) > @@ -245,6 +245,13 @@ > OmitFramePointer := -fomit-frame-pointer > endif > endif > + ifndef LOADABLE_MODULE > + ifndef SHARED_LIBRARY > + ifeq ($(OS),Darwin) > + DynamicNoPic := -mdynamic-no-pic > + endif > + endif > + endif How about factoring the logic so that there is one PIC_SETTING. This setting can be either -fpic, -mdynamic-no-pic, or empty. -Chris > > > # Darwin requires -fstrict-aliasing to be explicitly enabled. > # Avoid -fstrict-aliasing on Darwin for now, there are unresolved > issues > @@ -252,8 +259,8 @@ > #ifeq ($(OS),Darwin) > # EXTRA_OPTIONS += -fstrict-aliasing -Wstrict-aliasing > #endif > - CXX.Flags += $(OPTIMIZE_OPTION) $(OmitFramePointer) > - C.Flags += $(OPTIMIZE_OPTION) $(OmitFramePointer) > + CXX.Flags += $(OPTIMIZE_OPTION) $(OmitFramePointer) $(DynamicNoPic) > + C.Flags += $(OPTIMIZE_OPTION) $(OmitFramePointer) $(DynamicNoPic) > LD.Flags += $(OPTIMIZE_OPTION) > else > BuildMode := Debug > > Thoughts? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From isanbard at gmail.com Fri May 8 15:09:45 2009 From: isanbard at gmail.com (Bill Wendling) Date: Fri, 8 May 2009 13:09:45 -0700 Subject: [LLVMdev] RFA: flag_objc_abi on Non-Darwin Platforms? Message-ID: <16e5fdf90905081309v104f984evddd6792c629f2eae@mail.gmail.com> Is the flag_objc_abi variable available on non-Darwin platforms in llvm-gcc? I want to use it in llvm-backend.cpp to conditionalize a test. But I don't want to break Linux, Ada, Fortran, etc. -bw From clattner at apple.com Fri May 8 15:16:04 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 8 May 2009 13:16:04 -0700 Subject: [LLVMdev] RFA: flag_objc_abi on Non-Darwin Platforms? In-Reply-To: <16e5fdf90905081309v104f984evddd6792c629f2eae@mail.gmail.com> References: <16e5fdf90905081309v104f984evddd6792c629f2eae@mail.gmail.com> Message-ID: On May 8, 2009, at 1:09 PM, Bill Wendling wrote: > Is the flag_objc_abi variable available on non-Darwin platforms in > llvm-gcc? I want to use it in llvm-backend.cpp to conditionalize a > test. But I don't want to break Linux, Ada, Fortran, etc. If not, you can define it in objc-stubs.c -Chris From isanbard at gmail.com Fri May 8 15:19:43 2009 From: isanbard at gmail.com (Bill Wendling) Date: Fri, 8 May 2009 13:19:43 -0700 Subject: [LLVMdev] RFA: flag_objc_abi on Non-Darwin Platforms? In-Reply-To: References: <16e5fdf90905081309v104f984evddd6792c629f2eae@mail.gmail.com> Message-ID: <16e5fdf90905081319n31bee67coab45206039a118df@mail.gmail.com> On Fri, May 8, 2009 at 1:16 PM, Chris Lattner wrote: > On May 8, 2009, at 1:09 PM, Bill Wendling wrote: >> Is the flag_objc_abi variable available on non-Darwin platforms in >> llvm-gcc? I want to use it in llvm-backend.cpp to conditionalize a >> test. But I don't want to break Linux, Ada, Fortran, etc. > > If not, you can define it in objc-stubs.c > I think I just answered my own question. It's already used in llvm-debug.cpp. So it should be safe... -bw From mrs at apple.com Fri May 8 15:49:35 2009 From: mrs at apple.com (Mike Stump) Date: Fri, 8 May 2009 13:49:35 -0700 Subject: [LLVMdev] Darwin option processing In-Reply-To: References: <9B56655C-69E2-410C-B63C-858785289F11@apple.com> Message-ID: On May 8, 2009, at 1:02 PM, Chris Lattner wrote: > This goes against our general direction for llvm libraries: they > should generally all be built pic. After reviewing yet more of the Makefile,rules file, I believe ENABLE_PIC is the right thing to check. Currently ENABLE_PIC has to be set to get shared bits built, if the user wants them. Given that, we can use that to control wether or not -mdynamic-no-pic is added. Because this _must_ be set, it is safe to use the setting of that flag to make the decision on wether to add -mdynamic-no-pic. If that flag isn't set, the resulting objects, in general, can't be used in a shared library. > This is because we don't know how they will be linked in. Currently, the Makefile does know how the object will be used. On darwin, -fno-common is only added when ENABLE_PIC is 1, and objects can't be used in a shared library unless -fno-common is added. From gohman at apple.com Fri May 8 16:11:38 2009 From: gohman at apple.com (Dan Gohman) Date: Fri, 8 May 2009 14:11:38 -0700 Subject: [LLVMdev] Some questions on the output formats of AliasSetTracker In-Reply-To: <20090507202925.i2vbwux1k0gckgk0@cubmail.cc.columbia.edu> References: <20090507200737.skmhln5yosokkgcw@cubmail.cc.columbia.edu> <20090507202925.i2vbwux1k0gckgk0@cubmail.cc.columbia.edu> Message-ID: <77EC5414-3E55-4F42-B720-493BCBE8E372@apple.com> On May 7, 2009, at 5:29 PM, hc2428 at columbia.edu wrote: > Quoting Eli Friedman : > > Dear Eli, > Thanks very much for your reply. I have modified the XX and YY to > be global variables, but the output of AliasSetTracker are still MUST > alias: > > Alias Set Tracker: 5 alias sets for 4 pointer values. > AliasSet[0xea55d0,0] may alias, Mod/Ref > 8 Call Sites: void ({ }*)* @llvm.dbg.func.start, void (i32, i32, > { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* > @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void > (i32, i32, { }*)* @llvm.dbg.stoppoint, void (i32, i32, { }*)* > @llvm.dbg.stoppoint, void (i32, i32, { }*)* @llvm.dbg.stoppoint, void > ({ }*)* @llvm.dbg.region.end > AliasSet[0xeb81e0,1] must alias, Mod/Ref Pointers: (i32** @XX, 8) > AliasSet[0xea5fc0,1] must alias, Mod Pointers: (i32** @YY, 8) > AliasSet[0xeab830,1] must alias, Mod/Ref Pointers: (i32* %0, 4) > AliasSet[0xea5e70,1] must alias, Mod/Ref Pointers: (i32* > %retval, 4) This means that @XX and the others are each in an alias set of their own. A "must alias" on an AliasSetTracker AliasSet indicates that everything in the set is considered to must-alias every other element in that set. However since the above sets have just one element each, that indicates that there is no aliasing. Dan From mrs at apple.com Fri May 8 16:54:24 2009 From: mrs at apple.com (Mike Stump) Date: Fri, 8 May 2009 14:54:24 -0700 Subject: [LLVMdev] Darwin option processing In-Reply-To: References: <9B56655C-69E2-410C-B63C-858785289F11@apple.com> Message-ID: <9CF6C414-13B9-4509-BAE5-8A1B4C8D6A62@apple.com> On May 8, 2009, at 1:49 PM, Mike Stump wrote: > On May 8, 2009, at 1:02 PM, Chris Lattner wrote: >> This goes against our general direction for llvm libraries: they >> should generally all be built pic. > > After reviewing yet more of the Makefile,rules file, I believe > ENABLE_PIC is the right thing to check. Index: clang/Makefile.rules =================================================================== --- clang/Makefile.rules (revision 71270) +++ clang/Makefile.rules (working copy) @@ -338,6 +338,11 @@ C.Flags += -fPIC endif endif +else + ifeq ($(OS),Darwin) + CXX.Flags += -mdynamic-no-pic + C.Flags += -mdynamic-no-pic + endif endif CXX.Flags += $(CXXFLAGS) -Woverloaded-virtual is the patch I had in mind. Any objections? From vgrover528 at gmail.com Fri May 8 17:08:59 2009 From: vgrover528 at gmail.com (Vinod Grover) Date: Fri, 8 May 2009 14:08:59 -0800 Subject: [LLVMdev] Question on tablegen In-Reply-To: <493720826E33B1459E7F5C253E6D4BB50FFDC5@ssanexmb2.amd.com> References: <68c4c3e20905052223v3143f7b7u892de3e156f87f9c@mail.gmail.com> <14072311-B382-463F-92BB-73DDC8E57F0C@apple.com> <68c4c3e20905071727x33a24b73k79b5c11cd42ab21b@mail.gmail.com> <493720826E33B1459E7F5C253E6D4BB50FFDC5@ssanexmb2.amd.com> Message-ID: <35657f570905081508s35847504q4402b56a43f1e971@mail.gmail.com> I was wondering if there is a dag pattern for shuffle masks? On Thu, May 7, 2009 at 5:19 PM, Villmow, Micah wrote: > Manjunath, > I had a very similar problem and I solved it using a custom vector shuffle > and addition instead of mov. > > For example, > Vector_shuffle s1, s2, <0,3> is mapped to a custom instruction where I > transform the swizzle to a 32bit integer mask and an inverted mask. > > So I have dst, src0, src1, imm1, imm2 > And I have my asm look similar to: > Add dst, src0.imm1, src1.imm2 and then in the asm printer I intercept > vector_shuffle and I convert the integer to x,y,z,w, 0, 1 or _. > For example if the mask is to take x from s1 and yzw from s2, I would > generate 0x1000 and 0x0234. > So my result looks like > Iadd d0, s1.x000, s2.0yzw > > This allows you to do your vector shuffle in a single instruction. > > It's not the cleanest approach but it works for me and I can encode up to 8 > swizzle per immediate so works on vector sizes up to 8 in length. > > Hope this helps, > Micah > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Manjunath Kudlur > Sent: Thursday, May 07, 2009 5:28 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Question on tablegen > > Dan, > > Thanks a lot. Using a modifier in the assembly string works for this > case. I am trying to solve a related problem. I am trying to print out > a set of "mov" ops for the vector_shuffle node. Since the source of > the "mov" is from one of the sources to vector_shuffle, depending on > the mask, I am not sure what assembly string to emit. For example, if > I have > > d <- vector_shuffle s1, s2, <0,3> > > I want to emit > > mov d.x, s1.x > mov d.y, s2.y > > For this, I need some thing like > > "mov $d.x, <$src1 or $src2>." > > I can use the same modifier trick for which component of the source to > select, but I don't know how to select which of the sources to select > ($src1 or $src2) depending on the mask. Do you have any suggestions? > > Thanks, > Manjunath > > On Wed, May 6, 2009 at 10:10 AM, Dan Gohman wrote: > > One way to do this is to handle this in the AsmPrinter, with > > operand modifiers. > > > > For example, on x86 there are instructions with ${dst:call} in > > their asm string. The "call" part is interpreted as an operand > > modifier. The assembly printer looks for the "call" modifier > > on MachineOperand::MO_Immediate operands > > (in X86ATTAsmPrinter::printOperand), which lets it perform custom > > printing for that type of operand. You could use a modifier which > > tells the AsmPrinter to print an immediate as the appropriate > > letter. > > > > Dan > > > > > > On May 5, 2009, at 10:23 PM, Manjunath Kudlur wrote: > > > >> Hello, > >> > >> I am trying to create a machine instruction for "extractelement". I > >> want to translate > >> r <- extractelement v, 0 > >> to > >> mov r, v.x > >> > >> I was looking at the dag I can use and I found vector_extract. The > >> inputs for this SDnode are a register and a iPtr constant. With that, > >> I need to create 4 separate def's to extract element 0, 1, 2, and 3 > >> and translate to v.x, v.y, v.z, and v.w. I was wondering if I can use > >> the dag's 2nd input as an index into a list of strings and form the > >> assembly instruction, something like !strconcat("mov $dst, v.", > >> elemnames[$input]). I am still trying to learn the tablegen syntax and > >> semantics, so how to do this is not clear to me. I will appreciate any > >> suggestions on how to do this, or pointers to other places where > >> similar things are done. > >> > >> Thanks, > >> Manjunath > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090508/a446b6a4/attachment.html From npjohnso at cs.princeton.edu Fri May 8 18:02:54 2009 From: npjohnso at cs.princeton.edu (Nick Johnson) Date: Fri, 8 May 2009 19:02:54 -0400 Subject: [LLVMdev] Splitting a basic block, replacing it's terminator Message-ID: Hi, I want to insert a conditional branch in the middle of a basic block. To that end, I am doing these steps: (1) Split the basic block: bb->splitBasicBlock() (2) Remove the old terminator: succ->removePredecessor(bb) bb->getTerminator()->getParent() (3) Adding a new terminator: BranchInst::Create(ifTrue, ifFalse, cnd, "", bb); That seems to work, but later passes are dieing. When I dump the function from my debugger, I notice that the new block (the second half of the block I split) has a "" as a predecessor. What am I doing wrong? Here's what bb->getParent()->dump shows. bb4.preheader is the original basic block; bb4.preheader.noExit is the block created by the splitBasicBlock() operation: bb4.preheader: ; preds = %bb5, %preheader ; blah blah blah %6 = icmp slt i32 %timestamp, 0 ; [#uses=1] br i1 %6, label %__mtcg_sync_to_bb7.loopexit, label %bb4.preheader.noExit bb4.preheader.noExit: ; preds = %bb4.preheader, ; blah blah blah br i1 %10, label %bb5, label %bb1 -- Nick Johnson From clattner at apple.com Fri May 8 18:06:16 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 8 May 2009 16:06:16 -0700 Subject: [LLVMdev] Darwin option processing In-Reply-To: <9CF6C414-13B9-4509-BAE5-8A1B4C8D6A62@apple.com> References: <9B56655C-69E2-410C-B63C-858785289F11@apple.com> <9CF6C414-13B9-4509-BAE5-8A1B4C8D6A62@apple.com> Message-ID: <4ECE1E60-F918-42D3-84B9-1D7A632BA0F8@apple.com> On May 8, 2009, at 2:54 PM, Mike Stump wrote: > On May 8, 2009, at 1:49 PM, Mike Stump wrote: >> On May 8, 2009, at 1:02 PM, Chris Lattner wrote: >>> This goes against our general direction for llvm libraries: they >>> should generally all be built pic. >> >> After reviewing yet more of the Makefile,rules file, I believe >> ENABLE_PIC is the right thing to check. Looks good to me, thanks Mike. -Chris >> > > Index: clang/Makefile.rules > =================================================================== > --- clang/Makefile.rules (revision 71270) > +++ clang/Makefile.rules (working copy) > @@ -338,6 +338,11 @@ > C.Flags += -fPIC > endif > endif > +else > + ifeq ($(OS),Darwin) > + CXX.Flags += -mdynamic-no-pic > + C.Flags += -mdynamic-no-pic > + endif > endif > > CXX.Flags += $(CXXFLAGS) -Woverloaded-virtual > > is the patch I had in mind. Any objections? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From rjmccall at apple.com Fri May 8 18:10:34 2009 From: rjmccall at apple.com (John McCall) Date: Fri, 8 May 2009 16:10:34 -0700 Subject: [LLVMdev] Splitting a basic block, replacing it's terminator In-Reply-To: References: Message-ID: <65CE15BF-04AE-483D-A68C-2F679DE11B4E@apple.com> On May 8, 2009, at 4:02 PM, Nick Johnson wrote: > I want to insert a conditional branch in the middle of a basic block. > To that end, I am doing these steps: > > (1) Split the basic block: > bb->splitBasicBlock() > > (2) Remove the old terminator: > succ->removePredecessor(bb) > bb->getTerminator()->getParent() Assuming that the new block will still be a successor of the old block (just not the unique successor), all you really need to do is: BasicBlock* succ = bb->splitBasicBlock(); bb->getTerminator()->eraseFromParent(); BranchInst::Create(, , , bb); John. From nicholas.paul.johnson at gmail.com Fri May 8 18:19:29 2009 From: nicholas.paul.johnson at gmail.com (Nick Johnson) Date: Fri, 8 May 2009 19:19:29 -0400 Subject: [LLVMdev] Splitting a basic block, replacing it's terminator In-Reply-To: <65CE15BF-04AE-483D-A68C-2F679DE11B4E@apple.com> References: <65CE15BF-04AE-483D-A68C-2F679DE11B4E@apple.com> Message-ID: Thanks John. The problem was that I used bb->getTerminator()->removeFromParent(), but I should have used bb->getTerminator()->eraseFromParent(). Nick On Fri, May 8, 2009 at 7:10 PM, John McCall wrote: > On May 8, 2009, at 4:02 PM, Nick Johnson wrote: >> I want to insert a conditional branch in the middle of a basic block. >> To that end, I am doing these steps: >> >> (1) Split the basic block: >> bb->splitBasicBlock() >> >> (2) Remove the old terminator: >> succ->removePredecessor(bb) >> bb->getTerminator()->getParent() > > Assuming that the new block will still be a successor of the old block > (just not the unique successor), all you really need to do is: > > BasicBlock* succ = bb->splitBasicBlock(); > bb->getTerminator()->eraseFromParent(); > BranchInst::Create(, , , bb); > > John. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Nick Johnson From dag at cray.com Fri May 8 19:18:00 2009 From: dag at cray.com (David Greene) Date: Fri, 8 May 2009 19:18:00 -0500 Subject: [LLVMdev] TableGen List Manipulation Message-ID: <200905081918.01152.dag@cray.com> I see that one can take slices of lists, but is there any way to conditionally take a slice? For example, let's say I have this (fictitious) code: class FOO names> { string First = names[0]; string Middle = !if(!eq(!length(names), 3), names[1], ""); string Last = !last(names); } Is there currently a way to implement this behavior or should I code up some new operators? -Dave From ksh.cseiitk at gmail.com Fri May 8 22:44:56 2009 From: ksh.cseiitk at gmail.com (Kshitiz Garg) Date: Sat, 9 May 2009 09:14:56 +0530 Subject: [LLVMdev] problem with analysis required In-Reply-To: <4A044037.2050203@cs.uiuc.edu> References: <13da638f0905080407n6d2a1be7k9a451070fc65ed30@mail.gmail.com> <4A044037.2050203@cs.uiuc.edu> Message-ID: <13da638f0905082044t3426a6c9r93283bf5134cb193@mail.gmail.com> >> > I believe the problem here is that you need to specify the function for > which you want loop information in the above call, i.e.: > > Loopinfo * LI = &getAnalysis(F) > Thanks John . Your solution worked. We need to pass the function as a reference. However only the do initialization can do some module level stuff but it will not serve my purpose as one is not allowed to maintain states across 2 invocations of a function pass. kshitiz From ksh.cseiitk at gmail.com Fri May 8 23:38:35 2009 From: ksh.cseiitk at gmail.com (Kshitiz Garg) Date: Sat, 9 May 2009 10:08:35 +0530 Subject: [LLVMdev] inserting #pragmas and comments? Message-ID: <13da638f0905082138i14aa55b0k6b803a2a650e0ae0@mail.gmail.com> Hello, Is there a way such that one can insert #pragmas and /or comments in the IR such that the C code produced by llc has those pragmas which can be used later by another tool?. Say for example I have a pass that shall do some analysis and modifications to provided source code. Then I wish to parallelize the modified loop using open-MP by inserting openmp pragmas in the generated c code. regards, Kshitiz -- Kshitiz Garg Graduate Student Department of Computer Science & Engineering IIT Kanpur http://home.iitk.ac.in/~kshitizg From baldrick at free.fr Sat May 9 02:20:28 2009 From: baldrick at free.fr (Duncan Sands) Date: Sat, 9 May 2009 09:20:28 +0200 Subject: [LLVMdev] RFA: flag_objc_abi on Non-Darwin Platforms? In-Reply-To: <16e5fdf90905081309v104f984evddd6792c629f2eae@mail.gmail.com> References: <16e5fdf90905081309v104f984evddd6792c629f2eae@mail.gmail.com> Message-ID: <200905090920.29495.baldrick@free.fr> Hi Bill, > Is the flag_objc_abi variable available on non-Darwin platforms in > llvm-gcc? I want to use it in llvm-backend.cpp to conditionalize a > test. But I don't want to break Linux, Ada, Fortran, etc. since Fortran is now a release language, please always build with Fortran enabled (add fortran to --enable-languages) when testing. That should catch problems of this kind. Ciao, Duncan. From baldrick at free.fr Sat May 9 02:38:28 2009 From: baldrick at free.fr (Duncan Sands) Date: Sat, 9 May 2009 09:38:28 +0200 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905081134x5b43e96pf79b483695d8325a@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <6d9073030905081134x5b43e96pf79b483695d8325a@mail.gmail.com> Message-ID: <200905090938.28318.baldrick@free.fr> Hi, > $ make -j15 do you really have 15 CPUs? If not, this will most likely just slow things down. > cc1: /pkg/build/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:511: > bool::SCEVComplexityCompare::operator()(const llvm::SCEV*, > const llvm::SCEV*) const: Assertion `0 && "Unknown SCEV kind!"' > failed. > ../../llvm-gcc/libdecnumber/decNumber.c:5591: internal compiler error: Aborted > > This is all with llvm and llvm-gcc source from svn. Since the SCEV code is changing rapidly at the moment, it may be that you had the bad luck to update to a broken revision. > Here is the error when I try to build llvm with gcc-4.2.4 with > ENABLE_OPTIMIZED=1: > > `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' > referenced in section > `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' > of /pkg/build/llvm/llvm-obj/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o): > defined in discarded section > `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' > of /pkg/build/llvm/llvm-obj/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o) > collect2: ld returned 1 exit status > make[2]: *** [/pkg/build/llvm/llvm-obj/Release/lib/libLTO.so] Error 1 > make[2]: Leaving directory `/pkg/build/llvm/llvm-obj/tools/lto' This looks like a clear bug in your system tools: note how it complains that a certain section is referenced by itself, and that this is a problem because it is being discarded, d'oh! There's not much we can do about this kind of thing. > I have also tried installing with the llvm-gcc binary for RHEL4 (even > though I am running Centos 5). However, "make check" returned a bunch > of unexpected failures. If you want llvm from svn, then you should use llvm-gcc from svn too. Ciao, Duncan. From varonrotem at gmail.com Sat May 9 07:35:45 2009 From: varonrotem at gmail.com (Rotem Varon) Date: Sat, 9 May 2009 15:35:45 +0300 Subject: [LLVMdev] LLVM related question Message-ID: <4f5edbea0905090535k1d03e60eib9a5e7a48fc91894@mail.gmail.com> Hi, I am a student (software engineering), and i am using the LLVM in my project (I am sorry of the lack of details, but i want to take the minimum of your time, if you want more details don't hesitate...). I need to add a new optimization to the LLVM compiler. The optimization ALREADY written for x86 IR (i mean that the code that handles the optimization is designated to work on assembly 86) . So, this is what i think - I will add a Basic Block Pass to the LLVM, the code of the pass will iterate etch instruction and convert it to x86 IR, now the optimization will take place, after the optimization i will convert the x86 IR code back into LLVM IR. To the question(s): Do you think my idea is a good one (if yes, do you see any problems implementing this)? Do you have another idea? Is the LLVM have such built in capability ( converting LLVM IR to other IRs ) ? Grateful for you time. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090509/19fc9a13/attachment-0001.html From chihchaoh at gmail.com Sat May 9 08:16:19 2009 From: chihchaoh at gmail.com (kk983) Date: Sat, 9 May 2009 06:16:19 -0700 (PDT) Subject: [LLVMdev] llvm JIT to another target code? Message-ID: <23460198.post@talk.nabble.com> Hi, I am using llvm on cell, there are two different cores on cell, one is PPU and the other is SPU. but the JIT'ed code is always for PPU. I am trying to emit code for SPU through JIT. but I face the following questions: 1. I've trace the JIT code, but I still cant find exactly where JIT allocate PPU as it's target. is it done at make time? 2. I am trying to add an option that is -march=cellSPU to lli, how can I do that? Can anyone give me some tips or tell me which document I should study. thanks. -- View this message in context: http://www.nabble.com/llvm-JIT-to-another-target-code--tp23460198p23460198.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From eli.friedman at gmail.com Sat May 9 09:23:45 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 9 May 2009 07:23:45 -0700 Subject: [LLVMdev] LLVM related question In-Reply-To: <4f5edbea0905090535k1d03e60eib9a5e7a48fc91894@mail.gmail.com> References: <4f5edbea0905090535k1d03e60eib9a5e7a48fc91894@mail.gmail.com> Message-ID: On Sat, May 9, 2009 at 5:35 AM, Rotem Varon wrote: > I need to add a new?optimization to the LLVM compiler. Knowing what the optimization does would be very helpful here. > The optimization ALREADY?written?for x86 IR (i mean that the code that > handles the optimization is designated to work on assembly 86) . It's designed to work on x86 assembly, or "x86 IR"? If it's really x86 assembly, you can use LLVM's code generator to get x86 assembly, but it's extremely difficult to get back to LLVM IR. If it's something higher-level, it might not be so bad. > So, this is what i think - > I will add a Basic Block Pass to the LLVM, the code of the pass will iterate > etch instruction and convert it to x86 IR, now the optimization will take > place, after the optimization i will convert the x86 IR code back into LLVM > IR. > To the question(s): > Do you think my idea is a good one (if yes, do you see any > problems?implementing?this)? > Do you have another idea? If you're going to need conversions both ways, my guess is that it'll be faster to just rewrite the pass as an LLVM IR pass. It depends on how complicated the pass is, though. > Is the LLVM have such built in capability ( converting LLVM IR to?other?IRs > ) ? If you need a different IR, I think you'll have to write your own converter. Converting from LLVM IR to another language generally isn't very difficult if you don't care about the quality of the generated code too much, but it's a lot of work, and it seems like code quality is important here. -Eli From ksh.cseiitk at gmail.com Sat May 9 10:05:39 2009 From: ksh.cseiitk at gmail.com (Kshitiz Garg) Date: Sat, 9 May 2009 20:35:39 +0530 Subject: [LLVMdev] Codegen error with instrinsic Message-ID: <13da638f0905090805h758758b0t863e75d39a05a37b@mail.gmail.com> I am getting the following error when i am trying to generate the code. In the optimization pass I have inserted some calls llvm.annotation.i32 class to provide indentification tags to loops to be used in subsequent passes. Codegen is complaining about these annotations. llc -march=c ham1_seq.bc3 Error: Code generator does not support intrinsic function 'llvm.annotation.i32'! llc -march=x86 ham1_seq.bc3 Cannot yet select: intrinsic %llvm.annotation As per the language reference codegen simply ignores the intrinsics. The value returned by these intrinsics is not being used anywhere inside the code. Am i missing something or is this a bug?? regards, Kshitiz -- Kshitiz Garg Graduate Student Department of Computer Science & Engineering IIT Kanpur http://home.iitk.ac.in/~kshitizg From varonrotem at gmail.com Sat May 9 10:37:57 2009 From: varonrotem at gmail.com (Rotem Varon) Date: Sat, 9 May 2009 18:37:57 +0300 Subject: [LLVMdev] LLVM related question In-Reply-To: References: <4f5edbea0905090535k1d03e60eib9a5e7a48fc91894@mail.gmail.com> Message-ID: <4f5edbea0905090837x2e5ba382q3c10e51734d12763@mail.gmail.com> I will start with that i am vary grateful for your time.And continue with, i am sorry if my Qs aren't quite accurate( i just started with the LLVM compiler). On Sat, May 9, 2009 at 5:23 PM, Eli Friedman wrote: > On Sat, May 9, 2009 at 5:35 AM, Rotem Varon wrote: > > I need to add a new optimization to the LLVM compiler. > > Knowing what the optimization does would be very helpful here. > > > The optimization ALREADY written for x86 IR (i mean that the code that > > handles the optimization is designated to work on assembly 86) . > > It's designed to work on x86 assembly, or "x86 IR"? Its not x86 IR nor x86 assembly. I have x86 IR "like" instructions ( add R1, R2, R3 and so...) > If it's really > x86 assembly, you can use LLVM's code generator to get x86 assembly, Do you mean the "llvm-gcc -S file.c" , or can i have the same effect with C++ code (API) ? > but it's extremely difficult to get back to LLVM IR. Please, its vary important for me that you elaborate why it will be extremely difficult ( i can imagine it would hard, but if you inlight me i would probably create a better design...)? > If it's > something higher-level, it might not be so bad. Do you mean, higher than IR ? like c or C++ code ... > > > > So, this is what i think - > > I will add a Basic Block Pass to the LLVM, the code of the pass will > iterate > > etch instruction and convert it to x86 IR, now the optimization will take > > place, after the optimization i will convert the x86 IR code back into > LLVM > > IR. > > To the question(s): > > Do you think my idea is a good one (if yes, do you see any > > problems implementing this)? > > Do you have another idea? > > If you're going to need conversions both ways, my guess is that it'll > be faster to just rewrite the pass as an LLVM IR pass. Can you tall me where can i fined more information about the LLVM IR pass? > It depends on > how complicated the pass is, though. Lets say its only a project (academic) ... > > Is the LLVM have such built in capability ( converting LLVM IR > to other IRs > > ) ? > > If you need a different IR, I think you'll have to write your own > converter. Converting from LLVM IR to another language generally > isn't very difficult if you don't care about the quality of the > generated code too much, Again, lets say its only a project (academic) ... > but it's a lot of work, and it seems like > code quality is important here. > > -Eli If i have a pointer to Instruction, how can i get or set the VALUE of Instruction's operands ? Thank you. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090509/3853c8b1/attachment.html From sricketts at maxentric.com Sat May 9 11:42:17 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Sat, 9 May 2009 09:42:17 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <200905090938.28318.baldrick@free.fr> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <6d9073030905081134x5b43e96pf79b483695d8325a@mail.gmail.com> <200905090938.28318.baldrick@free.fr> Message-ID: <6d9073030905090942k75d88da4p4d22280a558ed019@mail.gmail.com> >> $ make -j15 > > do you really have 15 CPUs? ?If not, this will most > likely just slow things down. > I have 8 CPUs. I started with -j8 and turned the knob up a bit. It seemed to run faster, so I stuck with j15. I guess there might be some context switching when threads are blocking on memory or IO. I could be imagining the speedups though because of some sort of placebo effect. >> cc1: /pkg/build/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:511: >> bool::SCEVComplexityCompare::operator()(const llvm::SCEV*, >> const llvm::SCEV*) const: Assertion `0 && "Unknown SCEV kind!"' >> failed. >> ../../llvm-gcc/libdecnumber/decNumber.c:5591: internal compiler error: Aborted >> >> This is all with llvm and llvm-gcc source from svn. > > Since the SCEV code is changing rapidly at the moment, it may be that you > had the bad luck to update to a broken revision. Release 2.5 was giving me problems (see older posts on this thread). I will see if updating my current revision helps. > This looks like a clear bug in your system tools: note how it complains > that a certain section is referenced by itself, and that this is a problem > because it is being discarded, d'oh! ?There's not much we can do about this > kind of thing. OK, not quite sure what this means about my system tools. Is there something I should be concerned about? >> I have also tried installing with the llvm-gcc binary for RHEL4 (even >> though I am running Centos 5). However, "make check" returned a bunch >> of unexpected failures. > > If you want llvm from svn, then you should use llvm-gcc from svn too. Yes, I assumed so. I was just getting frustrated with not being able to build the svn llvm-gcc, so I tried the binary. > Ciao, > > Duncan. > Thanks for your help. From chihchaoh at gmail.com Sat May 9 07:44:32 2009 From: chihchaoh at gmail.com (kk983) Date: Sat, 9 May 2009 05:44:32 -0700 (PDT) Subject: [LLVMdev] llvm JIT to another target code? Message-ID: <23460198.post@talk.nabble.com> Hi, I am using llvm on cell, there are two different cores on cell, one is PPU and the other is SPU. but the JIT'ed code is always for PPU. I am trying to emit code for SPU through JIT. but I face the following questions: 1. I've trace the JIT code, but I still cant find exactly where JIT allocate PPU as it's target. is it done at make time? 2. I am trying to add an option that is -march=cellSPU to lli, how can I do that? Can anyone give me some tips or tell me which document I should study. thanks. -- View this message in context: http://www.nabble.com/llvm-JIT-to-another-target-code--tp23460198p23460198.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From baldrick at free.fr Sat May 9 12:32:47 2009 From: baldrick at free.fr (Duncan Sands) Date: Sat, 9 May 2009 19:32:47 +0200 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <6d9073030905090942k75d88da4p4d22280a558ed019@mail.gmail.com> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905090938.28318.baldrick@free.fr> <6d9073030905090942k75d88da4p4d22280a558ed019@mail.gmail.com> Message-ID: <200905091932.48508.baldrick@free.fr> Hi, > OK, not quite sure what this means about my system tools. Is there > something I should be concerned about? it seems that a bug in your system tools happens to be tickled by LLVM. We can't do much about the fact that your system doesn't work properly, though if enough people see a problem we do sometimes try to tweak LLVM so it avoids triggering the bug. If you don't have problems when building other programs then I guess there isn't much to be concerned about! Ciao, Duncan. From varonrotem at gmail.com Sat May 9 13:34:46 2009 From: varonrotem at gmail.com (Rotem Varon) Date: Sat, 9 May 2009 21:34:46 +0300 Subject: [LLVMdev] Instruction Conversion Message-ID: <4f5edbea0905091134g6e4b9fbcp9f48915fb52e11c4@mail.gmail.com> Hi, Let say i am writing a code inside basic block pass and iterating all the instructions inside, and i encountered in this instruction : %3 = add i32 %1, 2 I want to convert this instruction to something like this: add R1, 2, R3 I know the opocode, but i what i need is, the operands %1 and 2 (in this example). I will be grateful if some one will tell me how to do so . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090509/acfd0df2/attachment.html From criswell at uiuc.edu Sat May 9 14:38:34 2009 From: criswell at uiuc.edu (John Criswell) Date: Sat, 09 May 2009 13:38:34 -0600 Subject: [LLVMdev] Instruction Conversion In-Reply-To: <4f5edbea0905091134g6e4b9fbcp9f48915fb52e11c4@mail.gmail.com> References: <4f5edbea0905091134g6e4b9fbcp9f48915fb52e11c4@mail.gmail.com> Message-ID: <4A05DBBA.7050608@uiuc.edu> Rotem Varon wrote: > Hi, > > Let say i am writing a code inside basic block pass and iterating all > the instructions inside, > and i encountered in this instruction : If you're asking how to get the operands of an Instruction, use the getOperand() method: Value * Operand1 = I->getOperand(0); Value * Operand2 = I->getOperand(1); The LLVM doxygen documentation (http://llvm.org/doxygen/) is an invaluable resource. You may also want to read the Programmer's Guide (http://llvm.org/docs/ProgrammersManual.html). Does this answer your question? -- John T. > > %3 = add i32 %1, 2 > > I want to convert this instruction to something like this: > > add R1, 2, R3 > > I know the opocode, but i what i need is, the operands %1 and 2 (in > this example). > > I will be grateful if some one will tell me how to do so . From varonrotem at gmail.com Sat May 9 14:12:25 2009 From: varonrotem at gmail.com (Rotem Varon) Date: Sat, 9 May 2009 22:12:25 +0300 Subject: [LLVMdev] Instruction Conversion In-Reply-To: <4A05DBBA.7050608@uiuc.edu> References: <4f5edbea0905091134g6e4b9fbcp9f48915fb52e11c4@mail.gmail.com> <4A05DBBA.7050608@uiuc.edu> Message-ID: <4f5edbea0905091212s1d1fa477k92e1e340e841e4e@mail.gmail.com> yes, thank you for your quick reply. On Sat, May 9, 2009 at 10:38 PM, John Criswell wrote: > Rotem Varon wrote: > > Hi, > > > > Let say i am writing a code inside basic block pass and iterating all > > the instructions inside, > > and i encountered in this instruction : > If you're asking how to get the operands of an Instruction, use the > getOperand() method: > > Value * Operand1 = I->getOperand(0); > Value * Operand2 = I->getOperand(1); > > The LLVM doxygen documentation (http://llvm.org/doxygen/) is an > invaluable resource. You may also want to read the Programmer's Guide > (http://llvm.org/docs/ProgrammersManual.html). > > Does this answer your question? > > -- John T. > > > > > %3 = add i32 %1, 2 > > > > I want to convert this instruction to something like this: > > > > add R1, 2, R3 > > > > I know the opocode, but i what i need is, the operands %1 and 2 (in > > this example). > > > > I will be grateful if some one will tell me how to do so . > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090509/63a0b703/attachment.html From keveman at gmail.com Sat May 9 15:20:35 2009 From: keveman at gmail.com (Manjunath Kudlur) Date: Sat, 9 May 2009 13:20:35 -0700 Subject: [LLVMdev] Question on register class Message-ID: <68c4c3e20905091320x198049e0y54e754ad5d9c5b6d@mail.gmail.com> Hello, Given a TargetRegisterClass *RC, I was wondering if there is a way to find out what register class it is directly, instead of comparing it against all the &mytarget::Class1, &mytarget::Class2 etc. This goes back to my original intention of having special query functions for a subset of register classes. Suppose I wanted vector register classes (more than one, say 2-elements and 4-elements). I want to define special query functions for these classes, like getVectorLength etc. I can define them using MethodProtos and MethodBodies, but I have to define them for each one the classes in the set. It will be nice if there is a way to build a hierarchy of register classes, and dispatch handlers by finding what class a given RC is. I will appreciate suggestions on how to do this, or alternative ways to solve this problem. Thanks, Manjunath From eli.friedman at gmail.com Sat May 9 16:48:06 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 9 May 2009 14:48:06 -0700 Subject: [LLVMdev] LLVM related question In-Reply-To: <4f5edbea0905090837x2e5ba382q3c10e51734d12763@mail.gmail.com> References: <4f5edbea0905090535k1d03e60eib9a5e7a48fc91894@mail.gmail.com> <4f5edbea0905090837x2e5ba382q3c10e51734d12763@mail.gmail.com> Message-ID: On Sat, May 9, 2009 at 8:37 AM, Rotem Varon wrote: > Its not x86 IR nor ?x86 assembly. I have?x86 IR "like" instructions ( add > R1, R2, R3 ? ?and so...) >> >> ?If it's really >> x86 assembly, you can use LLVM's code generator to get x86 assembly, > > Do you mean the "llvm-gcc -S file.c" , or can i have the same effect with > C++ code (API) ? Everything in LLVM is accessible through the C++ APIs. >> but it's extremely difficult to get back to LLVM IR. > > Please, its vary important for me that you elaborate why it will > be?extremely difficult?( i can?imagine it would hard, but if you inlight me > i would probably create a?better?design...)? A lot of information gets lost when converting to assembly, like types, switches, the SSA form, etc. It's not impossible, especially if you make some assumptions about the compiler, but it's difficult enough that I wouldn't suggest it. It looks like this doesn't apply here, though. >> ?If it's >> something higher-level, it might not be so bad. > > ?Do you mean, higher than IR ? like c or C++ code ... Your IR looks high-level enough that it wouldn't be so bad. It would still be a pain to write, though. >> If you're going to need conversions both ways, my guess is that it'll >> be faster to just rewrite the pass as an LLVM IR pass. > > Can you tall me where can i fined more information about the ?LLVM IR pass? http://llvm.org/docs/WritingAnLLVMPass.html . Also, a bunch of other stuff in http://llvm.org/docs/ is likely to be useful. >> ?It depends on >> how complicated the pass is, though. > > Lets say its only a project (academic) ?... Then it's probably easier to rewrite as an LLVM IR pass. There's less to worry about when you're not converting back and forth. > If i have a pointer to Instruction, how can i get or set the VALUE > of??Instruction's operands ? I->getOperand(0) gets the first operand, I->setOperand(0) sets it, etc. Note that in general, the best way to get used to the API is to look at existing passes, espcecially if there's already a pass that's does stuff that's related to what you're doing. -Eli From criswell at uiuc.edu Sat May 9 17:50:06 2009 From: criswell at uiuc.edu (John Criswell) Date: Sat, 09 May 2009 16:50:06 -0600 Subject: [LLVMdev] Instruction Conversion In-Reply-To: <4f5edbea0905091240s61e31f8dl44ae677bd66d6368@mail.gmail.com> References: <4f5edbea0905091240s61e31f8dl44ae677bd66d6368@mail.gmail.com> Message-ID: <4A06089E.5080003@uiuc.edu> Rotem Varon wrote: > Hi, > > If i want to continue the conversation with you, do i need to replay > to llvmdev or to you diractly ? > If i replay to you, me email will be routed to you? You should reply to the llvmdev mailing list. That way, others can answer your questions, others can read their responses if they are having problems similar to the ones that you are experiencing, and you don't become dependent upon a single person and his/her schedule (e.g., I'm fairly busy these days due to finals,so my time for answering llvmdev questions is limited). > > anyway i have question about your answare: > %3 = add i32 %1, 2 > So, now i know to get %1 and 2 from the instruction > but how do i get the %3 ? In LLVM, the instruction *is* the result that the instruction generates. So, when you have an Instruction *, that Instruction * is the result of that instruction. For example, if I have a pointer to the instruction: Instruction * I = Value * Op1 = I->getOperand(0); Value * Op2 = I->getOperand(1); ..., if the instruction is the add instruction above, Op1 points to the %1, Op2 points to the 2, and I points to the %3. > > > and one more Q: > when i call i->getOperand(0) i want to get 1 > but i am getting %1 = ... > is it possible? Yes. Values starting with a percent are LLVM virtual registers; they are either the results of instructions or are constants of some sort. > > Is LLVM supply a convenient API for instruction parsing ? Yes. LLVM provides libraries for parsing bitcode, manipulating the in-memory intermediate representation, running analysis and transform passes, etc. -- John T. > thanks. > > Hi, > > Let say i am writing a code inside basic block pass and iterating all > the instructions inside, > and i encountered in this instruction : > > %3 = add i32 %1, 2 > > I want to convert this instruction to something like this: > > add R1, 2, R3 > > I know the opocode, but i what i need is, the operands %1 and 2 (in > this example). > > I will be grateful if some one will tell me how to do so . From varonrotem at gmail.com Sun May 10 09:39:55 2009 From: varonrotem at gmail.com (Rotem Varon) Date: Sun, 10 May 2009 17:39:55 +0300 Subject: [LLVMdev] LLVM related question In-Reply-To: References: <4f5edbea0905090535k1d03e60eib9a5e7a48fc91894@mail.gmail.com> <4f5edbea0905090837x2e5ba382q3c10e51734d12763@mail.gmail.com> Message-ID: <4f5edbea0905100739o1ac655bfl77f5d815120a98d6@mail.gmail.com> Thank you you answer. On Sun, May 10, 2009 at 12:48 AM, Eli Friedman wrote: > On Sat, May 9, 2009 at 8:37 AM, Rotem Varon wrote: > > Its not x86 IR nor x86 assembly. I have x86 IR "like" instructions ( add > > R1, R2, R3 and so...) > >> > >> If it's really > >> x86 assembly, you can use LLVM's code generator to get x86 assembly, > > > > Do you mean the "llvm-gcc -S file.c" , or can i have the same effect with > > C++ code (API) ? > > Everything in LLVM is accessible through the C++ APIs. > > >> but it's extremely difficult to get back to LLVM IR. > > > > Please, its vary important for me that you elaborate why it will > > be extremely difficult ( i can imagine it would hard, but if you inlight > me > > i would probably create a better design...)? > > A lot of information gets lost when converting to assembly, like > types, switches, the SSA form, etc. It's not impossible, especially > if you make some assumptions about the compiler, but it's difficult > enough that I wouldn't suggest it. It looks like this doesn't apply > here, though. > > >> If it's > >> something higher-level, it might not be so bad. > > > > Do you mean, higher than IR ? like c or C++ code ... > > Your IR looks high-level enough that it wouldn't be so bad. It would > still be a pain to write, though. > > >> If you're going to need conversions both ways, my guess is that it'll > >> be faster to just rewrite the pass as an LLVM IR pass. > > > > Can you tall me where can i fined more information about the LLVM IR > pass? > > http://llvm.org/docs/WritingAnLLVMPass.html . Also, a bunch of other > stuff in http://llvm.org/docs/ is likely to be useful. > > >> It depends on > >> how complicated the pass is, though. > > > > Lets say its only a project (academic) ... > > Then it's probably easier to rewrite as an LLVM IR pass. There's less > to worry about when you're not converting back and forth. > > > If i have a pointer to Instruction, how can i get or set the VALUE > > of Instruction's operands ? > > I->getOperand(0) gets the first operand, I->setOperand(0) sets it, > etc. Note that in general, the best way to get used to the API is to > look at existing passes, espcecially if there's already a pass that's > does stuff that's related to what you're doing. > > -Eli > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090510/60338093/attachment.html From varonrotem at gmail.com Sun May 10 09:40:42 2009 From: varonrotem at gmail.com (Rotem Varon) Date: Sun, 10 May 2009 17:40:42 +0300 Subject: [LLVMdev] LLVM related question In-Reply-To: <4f5edbea0905100739o1ac655bfl77f5d815120a98d6@mail.gmail.com> References: <4f5edbea0905090535k1d03e60eib9a5e7a48fc91894@mail.gmail.com> <4f5edbea0905090837x2e5ba382q3c10e51734d12763@mail.gmail.com> <4f5edbea0905100739o1ac655bfl77f5d815120a98d6@mail.gmail.com> Message-ID: <4f5edbea0905100740n622d1364he1d2e93774afa14e@mail.gmail.com> Thank your answer. On Sun, May 10, 2009 at 5:39 PM, Rotem Varon wrote: > Thank you you answer. > > > On Sun, May 10, 2009 at 12:48 AM, Eli Friedman wrote: > >> On Sat, May 9, 2009 at 8:37 AM, Rotem Varon wrote: >> > Its not x86 IR nor x86 assembly. I have x86 IR "like" instructions ( >> add >> > R1, R2, R3 and so...) >> >> >> >> If it's really >> >> x86 assembly, you can use LLVM's code generator to get x86 assembly, >> > >> > Do you mean the "llvm-gcc -S file.c" , or can i have the same effect >> with >> > C++ code (API) ? >> >> Everything in LLVM is accessible through the C++ APIs. >> >> >> but it's extremely difficult to get back to LLVM IR. >> > >> > Please, its vary important for me that you elaborate why it will >> > be extremely difficult ( i can imagine it would hard, but if you inlight >> me >> > i would probably create a better design...)? >> >> A lot of information gets lost when converting to assembly, like >> types, switches, the SSA form, etc. It's not impossible, especially >> if you make some assumptions about the compiler, but it's difficult >> enough that I wouldn't suggest it. It looks like this doesn't apply >> here, though. >> >> >> If it's >> >> something higher-level, it might not be so bad. >> > >> > Do you mean, higher than IR ? like c or C++ code ... >> >> Your IR looks high-level enough that it wouldn't be so bad. It would >> still be a pain to write, though. >> >> >> If you're going to need conversions both ways, my guess is that it'll >> >> be faster to just rewrite the pass as an LLVM IR pass. >> > >> > Can you tall me where can i fined more information about the LLVM IR >> pass? >> >> http://llvm.org/docs/WritingAnLLVMPass.html . Also, a bunch of other >> stuff in http://llvm.org/docs/ is likely to be useful. >> >> >> It depends on >> >> how complicated the pass is, though. >> > >> > Lets say its only a project (academic) ... >> >> Then it's probably easier to rewrite as an LLVM IR pass. There's less >> to worry about when you're not converting back and forth. >> >> > If i have a pointer to Instruction, how can i get or set the VALUE >> > of Instruction's operands ? >> >> I->getOperand(0) gets the first operand, I->setOperand(0) sets it, >> etc. Note that in general, the best way to get used to the API is to >> look at existing passes, espcecially if there's already a pass that's >> does stuff that's related to what you're doing. >> >> -Eli >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090510/11aea643/attachment.html From npjohnso at cs.princeton.edu Sun May 10 12:11:49 2009 From: npjohnso at cs.princeton.edu (Nick Johnson) Date: Sun, 10 May 2009 13:11:49 -0400 Subject: [LLVMdev] Get the call graph SCCs from a function pass Message-ID: Hello, I'm writing a Function Pass. This function pass needs access to the CallGraph and CallGraph SCCs. Is there any way I can get CallGraph information without changing my pass to a CallGraphSCCPass ? Thanks, -- Nick Johnson From edwintorok at gmail.com Sun May 10 13:01:41 2009 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sun, 10 May 2009 21:01:41 +0300 Subject: [LLVMdev] Get the call graph SCCs from a function pass In-Reply-To: References: Message-ID: <4A071685.9080407@gmail.com> On 2009-05-10 20:11, Nick Johnson wrote: > Hello, > > I'm writing a Function Pass. This function pass needs access to the > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph > information without changing my pass to a CallGraphSCCPass ? Does getAnalysis() work? But I'm not sure if using a FunctionPass to access Callgraph data is a good idea, transformations can change it (for example dead code elimination can remove edges). Best regards, --Edwin From nicholas.paul.johnson at gmail.com Sun May 10 13:18:51 2009 From: nicholas.paul.johnson at gmail.com (Nick Johnson) Date: Sun, 10 May 2009 14:18:51 -0400 Subject: [LLVMdev] Get the call graph SCCs from a function pass In-Reply-To: <4A071685.9080407@gmail.com> References: <4A071685.9080407@gmail.com> Message-ID: On 5/10/09, T?r?k Edwin wrote: > On 2009-05-10 20:11, Nick Johnson wrote: > > Hello, > > > > I'm writing a Function Pass. This function pass needs access to the > > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph > > information without changing my pass to a CallGraphSCCPass ? > > > Does getAnalysis() work? > AFAIK, it's not a pass. > But I'm not sure if using a FunctionPass to access Callgraph data is a > good idea, transformations can > change it (for example dead code elimination can remove edges). > I'm just using it to interpret profiling information correctly; in that respect, it doesn't matter if transformations change the IR, so long as the CallGraph data reflects the IR against which profiling was done. Nick From edwintorok at gmail.com Sun May 10 13:26:54 2009 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sun, 10 May 2009 21:26:54 +0300 Subject: [LLVMdev] Get the call graph SCCs from a function pass In-Reply-To: References: <4A071685.9080407@gmail.com> Message-ID: <4A071C6E.3040906@gmail.com> On 2009-05-10 21:18, Nick Johnson wrote: > On 5/10/09, T?r?k Edwin wrote: > >> On 2009-05-10 20:11, Nick Johnson wrote: >> > Hello, >> > >> > I'm writing a Function Pass. This function pass needs access to the >> > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph >> > information without changing my pass to a CallGraphSCCPass ? >> >> >> Does getAnalysis() work? >> >> > AFAIK, it's not a pass. > > It is, see lib/Analysis/IPA/CallGraph.cpp: static RegisterAnalysisGroup X("Call Graph"); static RegisterPass Y("basiccg", "Basic CallGraph Construction", false, true); static RegisterAnalysisGroup Z(Y); I know that using getAnalysis works in a ModulePass, but never tried it in a FunctionPass. >> But I'm not sure if using a FunctionPass to access Callgraph data is a >> good idea, transformations can >> change it (for example dead code elimination can remove edges). >> >> > I'm just using it to interpret profiling information correctly; in > that respect, it doesn't matter if transformations change the IR, so > long as the CallGraph data reflects the IR against which profiling was > done. > Ok. Best regards, --Edwin From santosh.nagarakatte at gmail.com Sun May 10 13:44:14 2009 From: santosh.nagarakatte at gmail.com (Santosh Nagarakatte) Date: Sun, 10 May 2009 14:44:14 -0400 Subject: [LLVMdev] Loss of Type information Message-ID: <131036460905101144q5dd0e2efmf40e8011845b73be@mail.gmail.com> I have a struct node with three fields {size_t, size_t, struct node *}. When I allocate such a node, malloc allocates [3* i64] i.e allocates an array of 3 i64's but not a structure. Thus any store to the pointer field in the structures involves a cast from a pointer to an integer. So a pointer is cast to a integer and then stored into the third field of this structure. This happens only when I use llvm-gcc -O3 to generate the bitcode? why does llvm-gcc do this with -O3? Sample bitcode illustrating the same is shown below. %2 = malloc [3 x i64] ; <[3 x i64]*> [#uses=6] %.sub = getelementptr [3 x i64]* %2, i64 0, i64 0 ; [#uses=\ 1] store i64 %i.0.reg2mem.0, i64* %.sub, align 8 %3 = getelementptr [3 x i64]* %2, i64 0, i64 1 ; [#uses=1] %.c = add i64 %i.0.reg2mem.0, 1 ; [#uses=3] store i64 %.c, i64* %3 %4 = getelementptr [3 x i64]* %2, i64 0, i64 2 ; [#uses=1] %ptr.0.c = ptrtoint [3 x i64]* %ptr.0.in.in.reg2mem.0 to i64 ; \ [#uses=1] store i64 %ptr.0.c, i64* %4 Santosh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090510/784fb278/attachment.html From nicholas.paul.johnson at gmail.com Sun May 10 13:52:13 2009 From: nicholas.paul.johnson at gmail.com (Nick Johnson) Date: Sun, 10 May 2009 14:52:13 -0400 Subject: [LLVMdev] Get the call graph SCCs from a function pass In-Reply-To: <4A071C6E.3040906@gmail.com> References: <4A071685.9080407@gmail.com> <4A071C6E.3040906@gmail.com> Message-ID: >>> Does getAnalysis() work? Thanks Edwin, that works! What about the CallGraphSCC ? It looks like one can declare a CallGraphSCCPass, but I don't see any other way to get the SCCs of the call graph. -- Nick Johnson From edwintorok at gmail.com Sun May 10 14:06:16 2009 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sun, 10 May 2009 22:06:16 +0300 Subject: [LLVMdev] Get the call graph SCCs from a function pass In-Reply-To: References: <4A071685.9080407@gmail.com> <4A071C6E.3040906@gmail.com> Message-ID: <4A0725A8.9090602@gmail.com> On 2009-05-10 21:52, Nick Johnson wrote: >>>> Does getAnalysis() work? >>>> > > Thanks Edwin, that works! > > What about the CallGraphSCC ? It looks like one can declare a > CallGraphSCCPass, but I don't see any other way to get the SCCs of the > call graph. You can use scc_iterator from ADT/SCCIterator.h, that gives you a std::vector of functions that are part of the same SCC, on each iteration. Have a look at tools/opt/PrintSCC.cpp for an example, or at the implementation of CallGraphSCCPass in lib/Analysis/IPA/ Best regards, --Edwin From varonrotem at gmail.com Sun May 10 14:17:26 2009 From: varonrotem at gmail.com (Rotem Varon) Date: Sun, 10 May 2009 22:17:26 +0300 Subject: [LLVMdev] llvm to x86 IR conversion Message-ID: <4f5edbea0905101217ra8c6522g3cde5bc205d12bcb@mail.gmail.com> Hi, I am running a basic block pass (and iterating through each instruction). Is it possible to convert the basic block instruction form llvm IR to x86 IRWITHIN the path ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090510/9c636a9a/attachment.html From me22.ca at gmail.com Sun May 10 14:30:25 2009 From: me22.ca at gmail.com (me22) Date: Sun, 10 May 2009 15:30:25 -0400 Subject: [LLVMdev] llvm to x86 IR conversion In-Reply-To: <4f5edbea0905101217ra8c6522g3cde5bc205d12bcb@mail.gmail.com> References: <4f5edbea0905101217ra8c6522g3cde5bc205d12bcb@mail.gmail.com> Message-ID: On Sun, May 10, 2009 at 15:17, Rotem Varon wrote: > I am running a basic block pass (and iterating through each instruction). > Is it possible to convert the basic block instruction form llvm IR to x86 IR > WITHIN the path ? > It seems to me that phi nodes would mean that you can't convert any unit smaller than a function to native code. ~ Scott From varonrotem at gmail.com Sun May 10 14:58:41 2009 From: varonrotem at gmail.com (Rotem Varon) Date: Sun, 10 May 2009 22:58:41 +0300 Subject: [LLVMdev] llvm to x86 IR conversion In-Reply-To: References: <4f5edbea0905101217ra8c6522g3cde5bc205d12bcb@mail.gmail.com> Message-ID: <4f5edbea0905101258i6ad5fa88ha66de79c64b56622@mail.gmail.com> Hi, I believe that my question isn't clear. So, please let me rephrase : I am running a basic block pass (and iterating through each instruction). Is it possible to convert the basic block instruction form llvm IR to x86 IRWITHIN the path ? I mean: is LLVM API exists for this purpose ? Again, thanks. On Sun, May 10, 2009 at 10:30 PM, me22 wrote: > On Sun, May 10, 2009 at 15:17, Rotem Varon wrote: > > I am running a basic block pass (and iterating through each instruction). > > Is it possible to convert the basic block instruction form llvm IR to x86 > IR > > WITHIN the path ? > > > > It seems to me that phi nodes would mean that you can't convert any > unit smaller than a function to native code. > > ~ Scott > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090510/fe57ef61/attachment.html From me22.ca at gmail.com Sun May 10 16:20:24 2009 From: me22.ca at gmail.com (me22) Date: Sun, 10 May 2009 17:20:24 -0400 Subject: [LLVMdev] llvm to x86 IR conversion In-Reply-To: <4f5edbea0905101258i6ad5fa88ha66de79c64b56622@mail.gmail.com> References: <4f5edbea0905101217ra8c6522g3cde5bc205d12bcb@mail.gmail.com> <4f5edbea0905101258i6ad5fa88ha66de79c64b56622@mail.gmail.com> Message-ID: On Sun, May 10, 2009 at 15:58, Rotem Varon wrote: > I believe that my question isn't clear. So, please let me rephrase : > I am running a basic block pass (and iterating through each instruction). > Is it possible to convert the basic block instruction form llvm IR to x86 IR > WITHIN the path ? > I mean: is LLVM API exists for this purpose ? > My point was that BasicBlockPass's runOnBasicBlock "is not allowed to inspect or modify basic blocks other than the parameter," and thus you don't have enough information to convert general LLVM IR to x86 IR, so there cannot be an LLVM API to do it. (I think.) From zhangzhengjian at gmail.com Mon May 11 01:40:54 2009 From: zhangzhengjian at gmail.com (zhengjian zhang) Date: Mon, 11 May 2009 14:40:54 +0800 Subject: [LLVMdev] Exception handling Message-ID: <8e3538210905102340t12ddc4bahe9d9e37f517b2650@mail.gmail.com> Hi, >On the other hand, it's not completely possible to separate it from >the front end either since different languages can have different >semantics. Ada, C++, Objective C, etc.. Sometimes these can be handled >the same way under the hood, but it's dangerous for the compiler to >assume that to be true. At least some knowledge needs to be in the >front end code-gen. what knowledge should be needs in the front end code-gen ? are the exception handling semantics of the llvm-gcc ? I have read the llvm-gcc 's except.c source file, I didn't get any idea about the gcc's sjlj-eh semantics! bestregards zhangzw From Christian.Sayer at dibcom.fr Mon May 11 10:03:36 2009 From: Christian.Sayer at dibcom.fr (Christian Sayer) Date: Mon, 11 May 2009 17:03:36 +0200 Subject: [LLVMdev] Instruction categories in the backend Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4AFA7EFF5E16@FRPAR1CL009.coe.adi.dibcom.com> Dear all, I would like to classify all target specific instructions in a set of categories. The category of each instruction would then be available in the backend. Just to illustrate what I am trying to do, the first thing I thought about how to achieve this was to group instruction definitions in InstrInfo.td in the order of categories, and to put pseudo instructions in between to mark category boundaries. However, the Target Instruction Enum in GenInstrNames.inc does not follow the definition order of the .td, but is in fact ordered alphabetically. Thanks for any suggestions! Christian -- CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you. From pejic at ualberta.ca Mon May 11 10:42:40 2009 From: pejic at ualberta.ca (Slobodan Pejic) Date: Mon, 11 May 2009 09:42:40 -0600 Subject: [LLVMdev] Introduction to the Profiling Infrastructure Message-ID: <4A084770.8080005@ualberta.ca> Dear LLVM Developers: I am an undergraduate summer research student supervised by Jos? Nelson Amaral at the University of Alberta. My work will primarily involve value profiling and path profiling. Andreas Neustifter is planning some changes to the profiling related code in LLVM (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html). Are any of these changes in yet? Which transforms that use profiling information should I pay attention in order to learn the code related to profiling? Based on the overview of analyses and transformations, profile guided basic block placement (http://llvm.org/docs/Passes.html#block-placement) seems to be my best bet. From mjr at cs.wisc.edu Mon May 11 12:02:08 2009 From: mjr at cs.wisc.edu (Matt Renzelmann) Date: Mon, 11 May 2009 12:02:08 -0500 Subject: [LLVMdev] Assign symbol the address of a section Message-ID: <001901c9d25a$3af40510$b0dc0f30$@wisc.edu> Hello, The binaries produced by LLVM and other compilers divide code up into various sections, e.g. the .text section. What is the recommended approach to assigning a symbol the address of a section using LLVM? Using GCC/LD, you can do this with a linker script, e.g. in a linker script you can do: _text = .; _stext = .; These symbols are then available in the corresponding C code using an "extern" definition. But, LLVM doesn't support linker scripts--so what's the trick? Thanks and regards, Matt From eli.friedman at gmail.com Mon May 11 12:21:44 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 11 May 2009 10:21:44 -0700 Subject: [LLVMdev] Assign symbol the address of a section In-Reply-To: <001901c9d25a$3af40510$b0dc0f30$@wisc.edu> References: <001901c9d25a$3af40510$b0dc0f30$@wisc.edu> Message-ID: On Mon, May 11, 2009 at 10:02 AM, Matt Renzelmann wrote: > These symbols are then available in the corresponding C code using an > "extern" definition. ?But, LLVM doesn't support linker scripts--so what's > the trick? There is no "trick"; llvm-gcc and gcc should work in exactly the same way in this regard. -Eli From clattner at apple.com Mon May 11 12:23:57 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 11 May 2009 10:23:57 -0700 Subject: [LLVMdev] Instruction categories in the backend In-Reply-To: <57C38DA176A0A34A9B9F3CCCE33D3C4AFA7EFF5E16@FRPAR1CL009.coe.adi.dibcom.com> References: <57C38DA176A0A34A9B9F3CCCE33D3C4AFA7EFF5E16@FRPAR1CL009.coe.adi.dibcom.com> Message-ID: On May 11, 2009, at 8:03 AM, Christian Sayer wrote: > Dear all, > > I would like to classify all target specific instructions in a set > of categories. The category of each instruction would then be > available in the backend. > Just to illustrate what I am trying to do, the first thing I thought > about how to achieve this was to group instruction definitions in > InstrInfo.td in the order of categories, and to put pseudo > instructions in between to mark category boundaries. However, the > Target Instruction Enum in GenInstrNames.inc does not follow the > definition order of the .td, but is in fact ordered alphabetically. Hi Christian, This is supported directly: TargetInstrDesc has 32-bits per instruction that your target can do whatever it wants with (TSFlags). tblgen has support for populating these directly. The X86 backend uses this for various encoding and other purposes. See X86InstrInfo.h (the X86II namespace) and related stuff for an example. tblgen is informed about the encoding of the 32-bit field with the TSFlagsFields/ TSFlagsShifts entries in X86InstrInfo in X86.td. -Chris From clattner at apple.com Mon May 11 12:24:37 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 11 May 2009 10:24:37 -0700 Subject: [LLVMdev] Assign symbol the address of a section In-Reply-To: <001901c9d25a$3af40510$b0dc0f30$@wisc.edu> References: <001901c9d25a$3af40510$b0dc0f30$@wisc.edu> Message-ID: On May 11, 2009, at 10:02 AM, Matt Renzelmann wrote: > Hello, > > The binaries produced by LLVM and other compilers divide code up into > various sections, e.g. the .text section. > > What is the recommended approach to assigning a symbol the address > of a > section using LLVM? Using GCC/LD, you can do this with a linker > script, > e.g. in a linker script you can do: > > _text = .; > _stext = .; > > These symbols are then available in the corresponding C code using an > "extern" definition. But, LLVM doesn't support linker scripts--so > what's > the trick? Hi Matt, I don't know of a straight-forward way to do this. However, you can probably use module-level inline asm to do the trick. -Chris From clattner at apple.com Mon May 11 12:26:25 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 11 May 2009 10:26:25 -0700 Subject: [LLVMdev] Question on register class In-Reply-To: <68c4c3e20905091320x198049e0y54e754ad5d9c5b6d@mail.gmail.com> References: <68c4c3e20905091320x198049e0y54e754ad5d9c5b6d@mail.gmail.com> Message-ID: <26DD6A83-0272-4330-AD7B-F750F73CD61E@apple.com> On May 9, 2009, at 1:20 PM, Manjunath Kudlur wrote: > Hello, > > Given a TargetRegisterClass *RC, I was wondering if there is a way to > find out what register class it is directly, instead of comparing it > against all the &mytarget::Class1, &mytarget::Class2 etc. Sure, just use RC->getID(), which returns an enum. > define them for each one the classes in the set. It will be nice if > there is a way to build a hierarchy of register classes, and dispatch > handlers by finding what class a given RC is. I will appreciate > suggestions on how to do this, or alternative ways to solve this > problem. I don't think that there is a visitor mechanism set up, but you can build one base on "switching on the enum". -Chris From clattner at apple.com Mon May 11 12:27:08 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 11 May 2009 10:27:08 -0700 Subject: [LLVMdev] Codegen error with instrinsic In-Reply-To: <13da638f0905090805h758758b0t863e75d39a05a37b@mail.gmail.com> References: <13da638f0905090805h758758b0t863e75d39a05a37b@mail.gmail.com> Message-ID: On May 9, 2009, at 8:05 AM, Kshitiz Garg wrote: > I am getting the following error when i am trying to generate the > code. In the optimization pass I have inserted some calls > llvm.annotation.i32 class to provide indentification tags to loops to > be used in subsequent passes. > Codegen is complaining about these annotations. > > llc -march=c ham1_seq.bc3 > Error: Code generator does not support intrinsic function > 'llvm.annotation.i32'! > > llc -march=x86 ham1_seq.bc3 > Cannot yet select: intrinsic %llvm.annotation > > As per the language reference codegen simply ignores the intrinsics. > The value returned by these intrinsics is not being used anywhere > inside the code. > Am i missing something or is this a bug?? This shouldn't happen, please file a bug. -Chris From clattner at apple.com Mon May 11 12:47:25 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 11 May 2009 10:47:25 -0700 Subject: [LLVMdev] inserting #pragmas and comments? In-Reply-To: <13da638f0905082138i14aa55b0k6b803a2a650e0ae0@mail.gmail.com> References: <13da638f0905082138i14aa55b0k6b803a2a650e0ae0@mail.gmail.com> Message-ID: <564F5BCF-0036-4261-8485-739B4B36A226@apple.com> On May 8, 2009, at 9:38 PM, Kshitiz Garg wrote: > Hello, > Is there a way such that one can insert #pragmas and /or comments > in the IR such that the C code produced by llc has those pragmas which > can be used later by another tool?. > Say for example I have a pass that shall do some analysis and > modifications to provided source code. Then I wish to parallelize the > modified loop using open-MP by inserting openmp pragmas in the > generated c code. The llvm.annotate intrinsic is a good way to go. -Chris From clattner at apple.com Mon May 11 12:48:24 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 11 May 2009 10:48:24 -0700 Subject: [LLVMdev] TableGen List Manipulation In-Reply-To: <200905081918.01152.dag@cray.com> References: <200905081918.01152.dag@cray.com> Message-ID: <2A155CDA-8908-4899-86E1-E505D3BA1038@apple.com> On May 8, 2009, at 5:18 PM, David Greene wrote: > I see that one can take slices of lists, but is there > any way to conditionally take a slice? > > For example, let's say I have this (fictitious) code: > > class FOO names> { > string First = names[0]; > string Middle = !if(!eq(!length(names), 3), names[1], ""); > string Last = !last(names); > } > > Is there currently a way to implement this behavior or should I > code up some new operators? There isn't a good way to do this right now. Would it make more sense to add a high level operator that does what you want, instead of a bunch of primitives? -Chris From jyasskin at google.com Mon May 11 12:56:25 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Mon, 11 May 2009 10:56:25 -0700 Subject: [LLVMdev] Mapping field names to GEP indices in clang-compiled C Message-ID: I'm using clang to compile functions and types written in C into LLVM IR so that I can inline calls and avoid hand-writing the StructType definitions. The types clang generates are packed structs instead of ordinary structs. So for struct Foo { char x; int* y; }; clang produces the type <{i8, i8, i8, i8, i32*}> instead of {i8, i32*}. To extract the 'y' field from the unpacked struct, I'd use "GEP ..., 1", and it'd be right on all architectures. To extract 'y' from the packed struct that clang produces, I have to use "GEP ..., 4" on x86-32, "GEP ..., 8" on x86-64, and who knows what on other architectures. Is there a way to get clang to emit a C++-readable mapping from field names to GEP offsets? Or some other way to avoid special-casing these offsets for each architecture? If not, what would be the easiest way to add such an ability? Thanks, Jeffrey (and the Unladen Swallow team) From eli.friedman at gmail.com Mon May 11 13:56:29 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 11 May 2009 11:56:29 -0700 Subject: [LLVMdev] Mapping field names to GEP indices in clang-compiled C In-Reply-To: References: Message-ID: On Mon, May 11, 2009 at 10:56 AM, Jeffrey Yasskin wrote: > Is there a way to get clang to emit a C++-readable mapping from field > names to GEP offsets? Or some other way to avoid special-casing these > offsets for each architecture? If not, what would be the easiest way > to add such an ability? First-off, this sort of question is more appropriate for cfe-dev; please direct any follow-up questions there. clang's current behavior here is a bug, but it's a low priority to fix because the generated IR isn't incorrect, just somewhat difficult to read. The only completely reliable solution I can think of is generating something like "int Foo_offsets[] = { offsetof(struct Foo, x), offsetof(struct Foo, y)};", then use some bitcasting to do the arithmetic. -Eli From sricketts at maxentric.com Mon May 11 14:30:03 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Mon, 11 May 2009 12:30:03 -0700 Subject: [LLVMdev] Using non-system compiler to build llvm and llvm-gcc front end In-Reply-To: <200905091932.48508.baldrick@free.fr> References: <6d9073030905011414v53318915l788dc20cac2f9901@mail.gmail.com> <200905090938.28318.baldrick@free.fr> <6d9073030905090942k75d88da4p4d22280a558ed019@mail.gmail.com> <200905091932.48508.baldrick@free.fr> Message-ID: <6d9073030905111230n61b25814lfa83d7f027c2283a@mail.gmail.com> OK, updated from svn (revision 71457) and got a successful installation. For the record: 1) Installed gcc 4.3.2 in /pkg/bin/gcc-4.3.2 (to insulate it from the system compiler) 2) Added /pkg/bin/gcc-4.3.2/bin to my PATH 3) Added /pkg/bin/gcc-4.3.2/lib and /pkg/bin/gcc-4.3.2/lib64 to /etc/ld.so.conf and ran ldconfig 4) More or less followed README.LLVM: Configure llvm: $ ../configure --prefix=/pkg/bin/llvm Build llvm: $ make -j10 Configure llvm-gcc: $ ../llvm-gcc/configure --prefix=/pkg/build/llvm-svn-updated/install --program-prefix=llvm- --enable-llvm=/pkg/build/llvm-svn-updated/llvm-obj --enable-languages=c,c++ Build llvm-gcc: $ make -j10 Install (run make install in object directories for both llvm and llvm-gcc) "make check" in llvm-obj fails one of the tests unexpectedly if I build with ENABLE_OPTIMIZED=1. It looks for some file in Debug and doesn't find it (LLVMHello.so). Thanks to Duncan, Anton, and Christian for helping me through this. Scott From dag at cray.com Mon May 11 14:53:06 2009 From: dag at cray.com (David Greene) Date: Mon, 11 May 2009 14:53:06 -0500 Subject: [LLVMdev] TableGen List Manipulation In-Reply-To: <2A155CDA-8908-4899-86E1-E505D3BA1038@apple.com> References: <200905081918.01152.dag@cray.com> <2A155CDA-8908-4899-86E1-E505D3BA1038@apple.com> Message-ID: <200905111453.07305.dag@cray.com> On Monday 11 May 2009 12:48, Chris Lattner wrote: > There isn't a good way to do this right now. Would it make more sense > to add a high level operator that does what you want, instead of a > bunch of primitives? That's what I'm looking into. -Dave From npjohnso at cs.princeton.edu Mon May 11 15:01:12 2009 From: npjohnso at cs.princeton.edu (Nick Johnson) Date: Mon, 11 May 2009 16:01:12 -0400 Subject: [LLVMdev] Pass Manager hangs with CallGraph and LoopSimplify Message-ID: Hello, I have discovered a situation in which the pass manager will infinite loop. The minimal test case is below this message. The required structure of these passes is; Before requires CallGraph After requires LoopSimplify and Before I can observe this through opt: opt -load ./libBug.so -after input.bc -o output.bc I built my copy of llvm from svn revision 68820 using gcc 4.1.2 Any suggestions? -- Nick Johnson #include "llvm/Pass.h" #include "llvm/Transforms/Scalar.h" #include "llvm/Analysis/CallGraph.h" using namespace llvm; class Before : public ModulePass { public: static char ID; Before() : ModulePass(&ID) {} void getAnalysisUsage(AnalysisUsage &au) const { au.addRequired< CallGraph >(); au.setPreservesAll(); } bool runOnModule(Module &m) { return false; } }; class After : public FunctionPass { public: static char ID; After() : FunctionPass(&ID) {} void getAnalysisUsage(AnalysisUsage &au) const { au.addRequiredID( LoopSimplifyID ); au.addRequired< Before >(); au.setPreservesAll(); } bool runOnFunction(Function &f) { return false; } }; char Before::ID = 0; char After::ID = 0; namespace { RegisterPass< Before > x("before", "before"); RegisterPass< After > y("after", "after"); } From samuraileumas at yahoo.com Mon May 11 15:16:41 2009 From: samuraileumas at yahoo.com (Samuel Crow) Date: Mon, 11 May 2009 13:16:41 -0700 (PDT) Subject: [LLVMdev] Pass Manager hangs with CallGraph and LoopSimplify In-Reply-To: References: Message-ID: <459212.41832.qm@web62007.mail.re1.yahoo.com> See http://llvm.org/docs/GettingStarted.html#brokengcc and then try building with something OTHER than GCC 4.1.2 . ----- Original Message ---- > From: Nick Johnson > To: LLVM Developers Mailing List > Sent: Monday, May 11, 2009 3:01:12 PM > Subject: [LLVMdev] Pass Manager hangs with CallGraph and LoopSimplify > > Hello, > > I have discovered a situation in which the pass manager will infinite > loop. The minimal test case is below this message. The required > structure of these passes is; > > Before requires CallGraph > After requires LoopSimplify and Before > > I can observe this through opt: > > opt -load ./libBug.so -after input.bc -o output.bc > > I built my copy of llvm from svn revision 68820 using gcc 4.1.2 > > Any suggestions? > -- > Nick Johnson > > > > > #include "llvm/Pass.h" > #include "llvm/Transforms/Scalar.h" > #include "llvm/Analysis/CallGraph.h" > > > using namespace llvm; > > class Before : public ModulePass { > public: > static char ID; > Before() : ModulePass(&ID) {} > > void getAnalysisUsage(AnalysisUsage &au) const { > au.addRequired< CallGraph >(); > au.setPreservesAll(); > } > > bool runOnModule(Module &m) { return false; } > }; > > class After : public FunctionPass { > public: > static char ID; > > After() : FunctionPass(&ID) {} > > void getAnalysisUsage(AnalysisUsage &au) const { > au.addRequiredID( LoopSimplifyID ); > au.addRequired< Before >(); > au.setPreservesAll(); > } > > bool runOnFunction(Function &f) { return false; } > }; > > char Before::ID = 0; > char After::ID = 0; > namespace { > RegisterPass< Before > x("before", "before"); > RegisterPass< After > y("after", "after"); > } > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From nicholas.paul.johnson at gmail.com Mon May 11 15:27:01 2009 From: nicholas.paul.johnson at gmail.com (Nick Johnson) Date: Mon, 11 May 2009 16:27:01 -0400 Subject: [LLVMdev] Pass Manager hangs with CallGraph and LoopSimplify In-Reply-To: <459212.41832.qm@web62007.mail.re1.yahoo.com> References: <459212.41832.qm@web62007.mail.re1.yahoo.com> Message-ID: > See http://llvm.org/docs/GettingStarted.html#brokengcc and then try building with something OTHER than GCC 4.1.2 . I have confirmed this bug with GCC v 4.2.4, which is NOT on your list. Nick > > > > ----- Original Message ---- >> From: Nick Johnson >> To: LLVM Developers Mailing List >> Sent: Monday, May 11, 2009 3:01:12 PM >> Subject: [LLVMdev] Pass Manager hangs with CallGraph and LoopSimplify >> >> Hello, >> >> I have discovered a situation in which the pass manager will infinite >> loop. The minimal test case is below this message. The required >> structure of these passes is; >> >> Before requires CallGraph >> After requires LoopSimplify and Before >> >> I can observe this through opt: >> >> opt -load ./libBug.so -after input.bc -o output.bc >> >> I built my copy of llvm from svn revision 68820 using gcc 4.1.2 >> >> Any suggestions? >> -- >> Nick Johnson >> >> >> >> >> #include "llvm/Pass.h" >> #include "llvm/Transforms/Scalar.h" >> #include "llvm/Analysis/CallGraph.h" >> >> >> using namespace llvm; >> >> class Before : public ModulePass { >> public: >> static char ID; >> Before() : ModulePass(&ID) {} >> >> void getAnalysisUsage(AnalysisUsage &au) const { >> au.addRequired< CallGraph >(); >> au.setPreservesAll(); >> } >> >> bool runOnModule(Module &m) { return false; } >> }; >> >> class After : public FunctionPass { >> public: >> static char ID; >> >> After() : FunctionPass(&ID) {} >> >> void getAnalysisUsage(AnalysisUsage &au) const { >> au.addRequiredID( LoopSimplifyID ); >> au.addRequired< Before >(); >> au.setPreservesAll(); >> } >> >> bool runOnFunction(Function &f) { return false; } >> }; >> >> char Before::ID = 0; >> char After::ID = 0; >> namespace { >> RegisterPass< Before > x("before", "before"); >> RegisterPass< After > y("after", "after"); >> } >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Nick Johnson From andrewl at lenharth.org Mon May 11 15:33:00 2009 From: andrewl at lenharth.org (Andrew Lenharth) Date: Mon, 11 May 2009 15:33:00 -0500 Subject: [LLVMdev] Compiling user mode linux with LLVM In-Reply-To: <002d01c9cf34$8c20f930$a462eb90$@wisc.edu> References: <002d01c9cf34$8c20f930$a462eb90$@wisc.edu> Message-ID: <85dfcd7f0905111333w7164e1c7kc3dcc0c3acfe86b6@mail.gmail.com> On Thu, May 7, 2009 at 11:54 AM, Matt Renzelmann wrote: > I've recently started working on compiling UML with LLVM: ?the goal is to > produce a bitcode version of vmlinux. I haven't tried UML, but I've produced (and run) native kernels with LVLM. > As an experiment, I've tried using llc to convert the vmlinux.bc output into > native assembly, then use "as" and "ld" to produce a native vmlinux, but the > ld step fails with: > > ld: ./vmlinux_native.o: bad reloc symbol index (0x9c113c >= 0x4af6) for > offset 0x18585 in section `.text' > ./vmlinux_native.o: could not read symbols: Bad value I'm not sure what this is about. > I've not pursued this specific issue further since my goal is to run the > bitcode directly, e.g. via lli. You might contact Will Dietz (CC'ed) who has JITed the kernel. > I'm also aware of the clever tricks the kernel uses that need to be > addressed, mentioned in the second paragraph of Andrew's above reply. ?As an > example, the symbol __initcall_start is defined in a linker script > (vmlinux.lds) and is used in the kernel as part of the initialization. > > Has anyone successfully modified the kernel initialization code to get UML > working with LLVM? ?If so, I'm interested in the approach taken so as to > avoid wasting time. You can easily write a script that walks the init sections and creates a global array of function points that would normally be constructed by the linker script. Andrew From evan.cheng at apple.com Mon May 11 19:07:43 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 11 May 2009 17:07:43 -0700 Subject: [LLVMdev] [PATH] Fixes for the amd64 JIT code In-Reply-To: <295e750a0905051519q23b2c6c3je437fc200e037fe8@mail.gmail.com> References: <295e750a0905010840y7850549cp23bbbeeaf409735c@mail.gmail.com> <01051155-8E3D-4D6B-BDAE-C6ADA590192B@apple.com> <23362528.post@talk.nabble.com> <98A26E3E-2CD5-47B7-A36D-E73C3A262DAF@apple.com> <86439649-E5C6-4F48-AD3D-33A7D0B56523@apple.com> <295e750a0905051417p6690df13r4ae656e9ad74dbc4@mail.gmail.com> <295e750a0905051519q23b2c6c3je437fc200e037fe8@mail.gmail.com> Message-ID: <9FE71AF7-8F2A-4EF8-8894-861A1F57CCE0@apple.com> Committed. Thanks! Evan On May 5, 2009, at 3:19 PM, Zoltan Varga wrote: > Hi, > > It looks like the problem was with the RIP relative addressing. > The original patch mistakenly > removed the || DispForReloc part because I tough that the RIP > relative addressing was done > by the SIB encodings, but it is actually done by the shorter ones. > The attached patch seems to work for me on linux and when simulating > darwin by forcing some variables in X86TargetMachine.cpp to their > darwin values. > > Zoltan > > On Tue, May 5, 2009 at 11:17 PM, Zoltan Varga > wrote: > Hi, > > I can't reproduce these failures on my linux machine. The test > machine seems to be > running darwin. I suspect that the problem might be with RIP > relative addressing, or with > the encoding of R12/R13, but the code seems to handle the latter, > since it checks for > ESP/EBP which is the same as R12/R13. > > Zoltan > > > On Tue, May 5, 2009 at 8:18 PM, Evan Cheng > wrote: > Hi Zoltan, > > The part that determines whether SIB byte is needed caused a lot of > regressions last night (see Geryon-X86-64 etc.). I've reverted it for > now. Please take a look. > > Thanks, > > Evan > > On May 4, 2009, at 3:49 PM, Evan Cheng wrote: > > > Committed as revision 70929. Thanks. > > > > Evan > > > > On May 3, 2009, at 8:29 PM, vargaz wrote: > > > >> > >> Hi, > >> > >> If this looks ok, could somebody check it in ? > >> > >> thanks > >> > >> Zoltan > >> > >> > >> Evan Cheng-2 wrote: > >>> > >>> Looks good. Thanks. > >>> > >>> Evan > >>> > >>> On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: > >>> > >>>> Hi, > >>>> > >>>> The attached patch contains the following changes: > >>>> > >>>> * X86InstrInfo.cpp: Synchronize a few places with the code in > >>>> X86CodeEmitter.cpp > >>>> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if > it > >>>> is not neeed. > >>>> > >>>> Zoltan > >>>> _______________________________________________ > >>>> LLVM Developers mailing list > >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >>> > >>> > >> > >> -- > >> View this message in context: http://www.nabble.com/-PATH--Fixes-for-the-amd64-JIT-code-tp23335910p23362528.html > >> Sent from the LLVM - Dev mailing list archive at Nabble.com. > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090511/6f14703b/attachment.html From viridia at gmail.com Tue May 12 00:46:17 2009 From: viridia at gmail.com (Talin) Date: Mon, 11 May 2009 22:46:17 -0700 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <4A03CCC1.6040001@mxc.ca> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> <4A03C7FE.5000206@gmail.com> <4A03CCC1.6040001@mxc.ca> Message-ID: <4A090D29.1020104@gmail.com> Nick Lewycky wrote: > Hi Talin, thanks for looking in to this. > > I think there's already a lot of code that makes the assumption that the > different members of a StructType represent distinct storage. Why is it > easier to co-opt StructType than to create a new 'UnionType' under > CompositeType? What's the tradeoff? > > So, I'm not sure what path to take now, or how to proceed on this. Anyone have an opinion as to whether unions should be a brand new type, or a variation of struct? The union class will share a lot of the same internal stuff as struct, such as the methods for serializing and managing the memory for the member list. In the mean time, I've decided to use an evil hack to get around the lack of proper union support. What I do is to examine all of the types in the union and estimate which one will be the largest. However, since my compiler is platform-independent, and doesn't know how big a pointer is, my calculation for "largest" is fairly complex - I calculate the size of all of the union members based on the assumption that pointers are 32-bits, and then filter out all members which are smaller than some other member in the set. I then do the same calculation but this time assume that pointers are 64 bits. Now I have two "largest" sets, I then intersect them to see if they have any entries in common. If they do, I pick one, and create a struct containing that type. This struct is guaranteed to be large enough to hold any union member on either a 32-bit or 64-bit platform. If the two sets don't have any entries in common, then I just fail and print a message saying wait until proper union support is done :) This hack at least gets me far enough so that in my language I can now compile and run code that looks like this: def testSimpleUnionType() { var x:int or float; x = 1; Debug.assertTrue(x isa int); Debug.assertFalse(x isa float); Debug.assertFalse(x isa String); x = 1.0; Debug.assertTrue(x isa float); Debug.assertFalse(x isa int); Debug.assertFalse(x isa String); } -- Talin From zhangzhengjian at gmail.com Tue May 12 02:03:00 2009 From: zhangzhengjian at gmail.com (zhengjian zhang) Date: Tue, 12 May 2009 15:03:00 +0800 Subject: [LLVMdev] How distinguish Catch all llvm-IR from other catch type ? Message-ID: <8e3538210905120003pe130ceeveba8d47cb17f1c6e@mail.gmail.com> Hi, catch_all.cpp: 1 int main() 2 { 3 try { 4 throw 34; 5 } 6 catch (...) {} 7 } llvm-gcc -O3 -S -emit-llvm catch_all.cpp -o catch_all.ll: 1 ; ModuleID = 'catch_all.cpp' 2 target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" 3 target triple = "i386-pc-linux-gnu" 4 %struct.__fundamental_type_info_pseudo = type { %struct.__type_info_pseudo } 5 %struct.__type_info_pseudo = type { i8*, i8* } 6 @_ZTIi = external constant %struct.__fundamental_type_info_pseudo ; <%struct.__fundamental_type_info_pseudo*> [#uses=1] 7 8 define i32 @main() { 9 entry: 10 %0 = tail call i8* @__cxa_allocate_exception(i32 4) nounwind ; [#uses=2] 11 %1 = bitcast i8* %0 to i32* ; [#uses=1] 12 store i32 34, i32* %1, align 4 13 invoke void @__cxa_throw(i8* %0, i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* null) noreturn 14 to label %invcont unwind label %lpad 15 16 invcont: ; preds = %entry 17 unreachable 18 19 lpad: ; preds = %entry 20 %eh_ptr = tail call i8* @llvm.eh.exception() ; [#uses=2] 21 %eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*)) ; [#uses=0] 22 %2 = tail call i8* @__cxa_begin_catch(i8* %eh_ptr) nounwind ; [#uses=0] 23 tail call void @__cxa_end_catch() 24 ret i32 0 25 } 26 27 declare i8* @__cxa_allocate_exception(i32) nounwind 28 29 declare void @__cxa_throw(i8*, i8*, void (i8*)*) noreturn 30 31 declare i8* @__cxa_begin_catch(i8*) nounwind 32 33 declare i8* @llvm.eh.exception() nounwind 34 35 declare i32 @llvm.eh.selector.i32(i8*, i8*, ...) nounwind 36 37 declare void @__cxa_end_catch() 38 39 declare i32 @__gxx_personality_sj0(...) from the LLVM-IR, catch all was translated to LLVM-IR : %eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*)) here llvm.eh.selector.i32 has only two args, but from the doc, it says llvm.eh.selector takes a minimum of three arguments. The first argument is the reference to the exception structure. The second argument is a reference to the personality function to be used for this try catch sequence. Each of the remaining arguments is either a reference to the type info for a catch statement, a filter expression, or the number zero representing a cleanup. are llvm.eh.selector.i32 has other semantics ? may be llvm-gcc deal call all as a special case ? best regards zhangzw From edwintorok at gmail.com Tue May 12 02:13:19 2009 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Tue, 12 May 2009 10:13:19 +0300 Subject: [LLVMdev] How distinguish Catch all llvm-IR from other catch type ? In-Reply-To: <8e3538210905120003pe130ceeveba8d47cb17f1c6e@mail.gmail.com> References: <8e3538210905120003pe130ceeveba8d47cb17f1c6e@mail.gmail.com> Message-ID: <4A09218F.1060808@gmail.com> On 2009-05-12 10:03, zhengjian zhang wrote: > Hi, > > catch_all.cpp: > > 1 int main() > 2 { > 3 try { > 4 throw 34; > 5 } > 6 catch (...) {} > 7 } > > > llvm-gcc -O3 -S -emit-llvm catch_all.cpp -o catch_all.ll: > > 1 ; ModuleID = 'catch_all.cpp' > 2 target datalayout = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" > 3 target triple = "i386-pc-linux-gnu" > 4 %struct.__fundamental_type_info_pseudo = type { > %struct.__type_info_pseudo } > 5 %struct.__type_info_pseudo = type { i8*, i8* } > 6 @_ZTIi = external constant > %struct.__fundamental_type_info_pseudo ; > <%struct.__fundamental_type_info_pseudo*> [#uses=1] > 7 > 8 define i32 @main() { > 9 entry: > 10 %0 = tail call i8* @__cxa_allocate_exception(i32 4) > nounwind ; [#uses=2] > 11 %1 = bitcast i8* %0 to i32* ; [#uses=1] > 12 store i32 34, i32* %1, align 4 > 13 invoke void @__cxa_throw(i8* %0, i8* bitcast > (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* > null) noreturn > 14 to label %invcont unwind label %lpad > 15 > 16 invcont: ; preds = %entry > 17 unreachable > 18 > 19 lpad: ; preds = %entry > 20 %eh_ptr = tail call i8* @llvm.eh.exception() > ; [#uses=2] > 21 %eh_select = tail call i32 (i8*, i8*, ...)* > @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* > @__gxx_personality_sj0 to i8*)) ; [#uses=0] > 22 %2 = tail call i8* @__cxa_begin_catch(i8* %eh_ptr) > nounwind ; [#uses=0] > 23 tail call void @__cxa_end_catch() > 24 ret i32 0 > 25 } > 26 > 27 declare i8* @__cxa_allocate_exception(i32) nounwind > 28 > 29 declare void @__cxa_throw(i8*, i8*, void (i8*)*) noreturn > 30 > 31 declare i8* @__cxa_begin_catch(i8*) nounwind > 32 > 33 declare i8* @llvm.eh.exception() nounwind > 34 > 35 declare i32 @llvm.eh.selector.i32(i8*, i8*, ...) nounwind > 36 > 37 declare void @__cxa_end_catch() > 38 > 39 declare i32 @__gxx_personality_sj0(...) > > > from the LLVM-IR, catch all was translated to LLVM-IR : > %eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* > %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*)) > here llvm.eh.selector.i32 has only two args, but from the doc, it > says llvm.eh.selector takes a minimum of three arguments. > I get an extra null arg, I don't know why you don't: %eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; [#uses=0] Compare it with the IR generated for catch(int) or catch(someOtherType). Here is how catch(int) looks like for me, notice the additional @_ZTIi parameter, and the icmp for the typeid: bb: ; preds = %lpad %2 = tail call i8* @__cxa_begin_catch(i8* %eh_ptr) nounwind ; [#uses=0] tail call void @__cxa_end_catch() ret i32 0 lpad: %eh_ptr = tail call i8* @llvm.eh.exception() ; [#uses=3] %eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), i8* null) ; [#uses=1] %eh_typeid = tail call i32 @llvm.eh.typeid.for.i32(i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*)) ; [#uses=1] %3 = icmp eq i32 %eh_select, %eh_typeid ; [#uses=1] br i1 %3, label %bb, label %Unwind Unwind: ; preds = %lpad tail call void @_Unwind_Resume(i8* %eh_ptr) unreachable Best regards, --Edwin From e0325716 at student.tuwien.ac.at Tue May 12 03:50:39 2009 From: e0325716 at student.tuwien.ac.at (Andreas Neustifter) Date: Tue, 12 May 2009 10:50:39 +0200 Subject: [LLVMdev] Introduction to the Profiling Infrastructure In-Reply-To: <4A084770.8080005@ualberta.ca> References: <4A084770.8080005@ualberta.ca> Message-ID: <4A09385F.5010406@student.tuwien.ac.at> Hi all! Slobodan Pejic wrote: > My work will primarily involve value profiling and path profiling. > Andreas Neustifter is planning some changes to the profiling related > code in LLVM > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html). > Are any of these changes in yet? I spent some time learning C++ and llvm so there is nothing finished yet. The only thing that is finished is a patch that bugfixes the profiling code a little: The ProfileInfoLoaderPass that feeds back the profiling information recorded during a profiling run back into llvm only uses the edge count information. This is fine since from edge counts the other information (block counts, function counts) can be derived. Unfortunately for functions with only one block, there are no edges so no information is recorded or feed back at all. In include/llvm/Analysis/ProfileInfo.h and lib/Analysis/ProfileInfo.cpp there is the assumption that a virtual edge (0,) exists which counts the number of executions of the entry block (and consequently of the function). My patch expands this concept of a (0,) edge to the whole profiling infrastructure: For each entry block an edge counter is generated and this counter is also feed back into llvm into the appropriate data structures. The patch applies cleanly to latest SVN. Since I haven't seen the profiler-loader used in the llvm-test suite, I tested my patch against the SPECCPU2000 benchmark with the use of a pass that verifies the profiles fed back against Kirchhoff flow constraints. (Sum of counts of incoming edges equals node count equals sum of counts of outgoing edges.) I also attach this verifier as patch. > Which transforms that use profiling > information should I pay attention in order to learn the code related to > profiling? Based on the overview of analyses and transformations, > profile guided basic block placement > (http://llvm.org/docs/Passes.html#block-placement) seems to be my best bet. Yes, as far as I saw this is the only pass that uses profiling information. The other thing is passes that _destroy_ profiling information due to changes made in a functions CFG. I will have to address this issue in the next weeks. -- Andi -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-van.edge0.patch Type: text/x-patch Size: 7357 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090512/a6ebbc0b/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-van.profileverifier.patch Type: text/x-patch Size: 11346 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090512/a6ebbc0b/attachment-0003.bin From zhangzhengjian at gmail.com Tue May 12 04:38:17 2009 From: zhangzhengjian at gmail.com (zhengjian zhang) Date: Tue, 12 May 2009 17:38:17 +0800 Subject: [LLVMdev] catch all Message-ID: <8e3538210905120238u71c099a5xb1eaba99bda90cc2@mail.gmail.com> Hi, that's right ! catch(all) has extra null arg, eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; [#uses=0] I have doubt that : the llvm-IR like above are all translated from catch(all) statement . zhangzw From baldrick at free.fr Tue May 12 07:27:55 2009 From: baldrick at free.fr (Duncan Sands) Date: Tue, 12 May 2009 14:27:55 +0200 Subject: [LLVMdev] catch all In-Reply-To: <8e3538210905120238u71c099a5xb1eaba99bda90cc2@mail.gmail.com> References: <8e3538210905120238u71c099a5xb1eaba99bda90cc2@mail.gmail.com> Message-ID: <200905121427.55790.baldrick@free.fr> > that's right ! catch(all) has extra null arg, > > eh_select = tail call i32 (i8*, i8*, ...)* > @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* > @__gxx_personality_v0 to i8*), i8* null) ; [#uses=0] > > I have doubt that : > the llvm-IR like above are all translated from catch(all) statement . I'm not sure what you are saying... Ciao, Duncan. From zhangzhengjian at gmail.com Tue May 12 07:39:51 2009 From: zhangzhengjian at gmail.com (zhengjian zhang) Date: Tue, 12 May 2009 20:39:51 +0800 Subject: [LLVMdev] catch all In-Reply-To: <200905121427.55790.baldrick@free.fr> References: <8e3538210905120238u71c099a5xb1eaba99bda90cc2@mail.gmail.com> <200905121427.55790.baldrick@free.fr> Message-ID: <8e3538210905120539nee2d001ge66371c74b353d61@mail.gmail.com> 2009/5/12 Duncan Sands : >> ?that's ?right ! ?catch(all) has extra null arg, >> >> eh_select = tail call i32 (i8*, i8*, ...)* >> @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* >> @__gxx_personality_v0 to i8*), i8* null) ? ? ? ?; [#uses=0] >> >> I have doubt ?that ?: >> the llvm-IR like above are ?all translated from catch(all) statement . > > I'm not sure what you are saying... > > Ciao, > > Duncan. > Hi, sorry for my terible english ! I mean there are only the catch(...) statement can be translate to the LLVM-IR : eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) are there any other case can be translate to the same above LLVM-IR ? best regards zhangzw From baldrick at free.fr Tue May 12 07:43:02 2009 From: baldrick at free.fr (Duncan Sands) Date: Tue, 12 May 2009 14:43:02 +0200 Subject: [LLVMdev] catch all In-Reply-To: <8e3538210905120539nee2d001ge66371c74b353d61@mail.gmail.com> References: <8e3538210905120238u71c099a5xb1eaba99bda90cc2@mail.gmail.com> <200905121427.55790.baldrick@free.fr> <8e3538210905120539nee2d001ge66371c74b353d61@mail.gmail.com> Message-ID: <200905121443.02636.baldrick@free.fr> Hi zhangzw, > I mean > there are only the catch(...) statement can be translate to the LLVM-IR : > eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* > %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* > null) > > are there any other case can be translate to the same above LLVM-IR ? currently llvm-gcc uses a horrible hack and *always* puts null (catch all) at the end of the selector (if it wasn't already there) IIRC. This is needed to get rethrowing of exceptions working properly when invokes are inlined into other functions. I have a plan to fix this, and while it's not complete I expect to commit some initial code this week sometime. Ciao, Duncan. From andrewl at lenharth.org Tue May 12 07:44:30 2009 From: andrewl at lenharth.org (Andrew Lenharth) Date: Tue, 12 May 2009 07:44:30 -0500 Subject: [LLVMdev] Suggestion: Support union types in IR In-Reply-To: <1187D7FA-1A46-404C-B506-9F1349203AD0@apple.com> References: <7F7009AC-D582-4391-A9B7-69DBCADBE95C@apple.com> <4A00FF67.4090500@gmail.com> <0B6805BD-85B8-460F-B35C-8656D26C01A2@apple.com> <4A011842.3030702@gmail.com> <1187D7FA-1A46-404C-B506-9F1349203AD0@apple.com> Message-ID: <85dfcd7f0905120544i196643deu10cde62061e66b45@mail.gmail.com> On Fri, May 8, 2009 at 12:25 PM, Chris Lattner wrote: > On May 5, 2009, at 9:55 PM, Talin wrote: >> Suppose I have an STL-like container that has a 'begin' and 'end' >> pointer. Now I want to find the size() of the container. Since you >> cannot subtract pointers in LLVM IR, you have to cast them to an >> integer >> type first. But what integer type do you cast them to? I suppose you >> could simply always cast them to i64, and hope that the backend will >> generate efficient code for the subtraction, but I have no way of >> knowing this. > > What do you intend to do with this size? ?At some point you have to do > an operation that depends on the size. ?The problem with adding an > intptr_t is that at some point you have to convert it to another > datatype, and you don't know whether it will be a zext/trunc/bitcast > etc. You may want to feed it back into GEP. If size() for the container is the first step in calculating a pivot point for qsort, then as long as GEP takes in intptr_t you are set. In fact, if intptr_t existed, it would be all a GEP or malloc had to take and those instructions wouldn't need the current bi-version approach (nor any other thing that takes a size, like the mem* intrinsics). I would go so far as to say that ptr->int and int->ptr cases should only be possible to an intptr type, and then the target knowledge which currently is embedded in the ptr cast is embedded in the int cast if you need to cast to a known size. Andrew From Chareos at gmx.de Tue May 12 08:29:45 2009 From: Chareos at gmx.de (Ralf Karrenberg) Date: Tue, 12 May 2009 15:29:45 +0200 Subject: [LLVMdev] optimization passes through c++ Message-ID: <4A0979C9.90004@gmx.de> Hey all, I am trying to run llvm's optimzation passes (basically as many as possible :p), but apparently there is no effect (dumped .ll-file before and after optimization -> identical). I am wondering if the method is just not optimizable in *any* way or if I am not invoking the stuff correctly. The system setup on a broad scale looks as follows: - custom LLVM-module pass - at some point inside the runOnModule(), it instantiates a PassManager, adds all kinds of optimizations ( PM.add(createXYZPass()) ) and runs them on a provided module. - the module is provided by a bitcode file that is generated with llvm-g++ from a c++-file. There are several problems with the bitcode generated by llvm-g++: - I understand that in LLVM 2.5 all optimizations of gcc are disabled. this leads to horrible code with a lot of unnecessary alloc/gep/load/store stuff - however, there seems to be one optimization that is particularly nasty and I do not know how to disable it: at certain points where a struct with three floats is supplied, the struct is split into a double and a float (for loading/storing, but this also affects function signatures!) the functions I am running this on look like the following: struct Point { float x; float y; float z; } extern "C" void test ( int a, float f, Point p0, Point p1, float x, Point & result ); only the result should be stored back (and is usually only used once at the end of the function), all other values should not invoke any allocations or loads/stores... I hope someone can help me out here. Regards, Ralf From fvbommel at wxs.nl Tue May 12 09:24:10 2009 From: fvbommel at wxs.nl (Frits van Bommel) Date: Tue, 12 May 2009 16:24:10 +0200 Subject: [LLVMdev] optimization passes through c++ In-Reply-To: <4A0979C9.90004@gmx.de> References: <4A0979C9.90004@gmx.de> Message-ID: <4A09868A.4060602@wxs.nl> Ralf Karrenberg wrote: > - however, there seems to be one optimization that is particularly nasty > and I do not know how to disable it: at certain points where a struct > with three floats is supplied, the struct is split into a double and a > float (for loading/storing, but this also affects function signatures!) I don't think this is an optimization. It does this (at least, for functions signatures) to be compatible with regular (non-llvm) gcc/g++. For example, this would generate the appropriate code if your llvm-g++ is targeted at x86-64. (So would using { <2 x float>, float } instead, probably, but that's another matter...) From dag at cray.com Tue May 12 10:55:41 2009 From: dag at cray.com (David Greene) Date: Tue, 12 May 2009 10:55:41 -0500 Subject: [LLVMdev] Machine-level Memory Dependence Message-ID: <200905121055.42528.dag@cray.com> Is anyone working on adding a memory dependence analysis that works on MachineInstructions? The PseudoSourceValue code makes reference to some MachineInstruction-level alias analysis but I can't find it. I'm seeing the spiller do stupid things and it would be nice to be able to run a peep that cleans things up. Unfortunately, I need at least memory dependence information to make it safe in the simple cases. I need full loop dependence for the general case but I don't think that's as pressing. I don't have the bandwidth to write this kind of analysis at the moment. It's something I have on my long-term TODO list. Just wondering if anyone else is working on it. -Dave From dag at cray.com Tue May 12 11:21:57 2009 From: dag at cray.com (David Greene) Date: Tue, 12 May 2009 11:21:57 -0500 Subject: [LLVMdev] TableGen Object Ownership Message-ID: <200905121121.57542.dag@cray.com> I'm adding some new operators to TableGen and I've run into a memory ownership issue. We have all of these Inits and RecTys flying around but I don't see any scheme to assign ownership. It looks like we're leaking memory all over. This is getting worse as I'm adding operators because I need to create new objects on-the-fly and/or return operands of operators as the result of the folding of the operation. Is there an ownership scheme or should we consider smart pointers or a similar mechanism? -Dave From clattner at apple.com Tue May 12 11:45:30 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 12 May 2009 09:45:30 -0700 Subject: [LLVMdev] TableGen Object Ownership In-Reply-To: <200905121121.57542.dag@cray.com> References: <200905121121.57542.dag@cray.com> Message-ID: On May 12, 2009, at 9:21 AM, David Greene wrote: > I'm adding some new operators to TableGen and I've run into a memory > ownership > issue. > > We have all of these Inits and RecTys flying around but I don't see > any scheme > to assign ownership. It looks like we're leaking memory all over. > > This is getting worse as I'm adding operators because I need to > create new > objects on-the-fly and/or return operands of operators as the result > of > the folding of the operation. Yes, this is horrible. It would be really nice (tm) if C++ allowed you to say "anything derived from this class should be garbage collected". Alas, that doesn't exist. :) > Is there an ownership scheme or should we consider smart pointers or > a similar > mechanism? I think smart pointers would make sense, though I generally prefer an explicit ownership model. I'm happy with whatever you think is best, -Chris From sricketts at maxentric.com Tue May 12 13:16:47 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Tue, 12 May 2009 11:16:47 -0700 Subject: [LLVMdev] Tutorial 1: casting cout Message-ID: <6d9073030905121116vcd84f07p5710fd132f009fe3@mail.gmail.com> To get Tutorial 1 to compile, I had to cast cout as a raw_osstream, as in: PM.add(createPrintModulePass(&llvm::cout)); ----> PM.add(createPrintModulePass((raw_ostream*)&llvm::cout)); I was getting the following error: $ c++ -g tut1.cpp `llvm-config --cxxflags --ldflags --libs core` -o tut1 tut1.cpp: In function ?int main(int, char**)?: tut1.cpp:19: error: cannot convert ?llvm::OStream*? to ?llvm::raw_ostream*? for argument ?1? to ?llvm::ModulePass* llvm::createPrintModulePass(llvm::raw_ostream*, bool)? Anyway, just wanted to mark the record in case this is a bug in the tutorial or an inconsistency with the revision of llvm I am running (71457). Still, it is likely that the error is a result of me overlooking something. From isanbard at gmail.com Tue May 12 13:29:58 2009 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 12 May 2009 11:29:58 -0700 Subject: [LLVMdev] Tutorial 1: casting cout In-Reply-To: <6d9073030905121116vcd84f07p5710fd132f009fe3@mail.gmail.com> References: <6d9073030905121116vcd84f07p5710fd132f009fe3@mail.gmail.com> Message-ID: <16e5fdf90905121129r2e4a3b9fv62db296f3d4fc10e@mail.gmail.com> Fixed. Thanks! :-) -bw On Tue, May 12, 2009 at 11:16 AM, Scott Ricketts wrote: > To get Tutorial 1 to compile, I had to cast cout as a raw_osstream, as in: > > PM.add(createPrintModulePass(&llvm::cout)); > > ----> > > PM.add(createPrintModulePass((raw_ostream*)&llvm::cout)); > > > I was getting the following error: > > $ c++ -g tut1.cpp `llvm-config --cxxflags --ldflags --libs core` -o tut1 > tut1.cpp: In function ?int main(int, char**)?: > tut1.cpp:19: error: cannot convert ?llvm::OStream*? to > ?llvm::raw_ostream*? for argument ?1? to ?llvm::ModulePass* > llvm::createPrintModulePass(llvm::raw_ostream*, bool)? > > Anyway, just wanted to mark the record in case this is a bug in the > tutorial or an inconsistency with the revision of llvm I am running > (71457). Still, it is likely that the error is a result of me > overlooking something. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From overminddl1 at gmail.com Tue May 12 16:14:06 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 15:14:06 -0600 Subject: [LLVMdev] MSVC cstdint Message-ID: <3f49a9f40905121414t6bf22586mca3dc0e0b92de303@mail.gmail.com> In the llvm file include/llvm/Support/DataTypes.h (.in/.cmake), for MSVCit defines some macros that are defined in the cstdint.hpp file in boost (and boost does it better, detailed below): The basic error is: R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(347) : warning C4005: 'INT8_C' : macro redefinition R:\SDKs\llvm\trunk_VC8_building\include\llvm/Support/DataTypes.h(116) : see previous definition of 'INT8_C' R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(348) : warning C4005: 'INT16_C' : macro redefinition R:\SDKs\llvm\trunk_VC8_building\include\llvm/Support/DataTypes.h(118) : see previous definition of 'INT16_C' R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(349) : warning C4005: 'INT32_C' : macro redefinition R:\SDKs\llvm\trunk_VC8_building\include\llvm/Support/DataTypes.h(120) : see previous definition of 'INT32_C' R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(350) : warning C4005: 'INT64_C' : macro redefinition R:\SDKs\llvm\trunk_VC8_building\include\llvm/Support/DataTypes.h(122) : see previous definition of 'INT64_C' R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(355) : warning C4005: 'UINT8_C' : macro redefinition R:\SDKs\llvm\trunk_VC8_building\include\llvm/Support/DataTypes.h(117) : see previous definition of 'UINT8_C' R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(357) : warning C4005: 'UINT16_C' : macro redefinition R:\SDKs\llvm\trunk_VC8_building\include\llvm/Support/DataTypes.h(119) : see previous definition of 'UINT16_C' R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(358) : warning C4005: 'UINT32_C' : macro redefinition R:\SDKs\llvm\trunk_VC8_building\include\llvm/Support/DataTypes.h(121) : see previous definition of 'UINT32_C' R:\SDKs\boost\built_head\include\boost-1_38\boost/cstdint.hpp(359) : warning C4005: 'UINT64_C' : macro redefinition R:\SDKs\llvm\trunk_VC8_building\include\llvm/Support/DataTypes.h(123) : see previous definition of 'UINT64_C' LLVMs definitions look like this: #define INT8_C(C) C #define UINT8_C(C) C #define INT16_C(C) C #define UINT16_C(C) C #define INT32_C(C) C #define UINT32_C(C) C ## U #define INT64_C(C) ((int64_t) C ## LL) #define UINT64_C(C) ((uint64_t) C ## ULL) Boosts look like this: # define INT8_C(value) value##i8 # define INT16_C(value) value##i16 # define INT32_C(value) value##i32 # define INT64_C(value) value##i64 # define UINT8_C(value) value##ui8 # define UINT16_C(value) value##ui16 # define UINT32_C(value) value##ui32 # define UINT64_C(value) value##ui64 # define INTMAX_C(value) value##i64 # define UINTMAX_C(value) value##ui64 Which is more correct due to MSVC suffix (boost also defines appropriate ones for appropriate compilers). My main thing is the warnings, which were not there earlier, although I have had boost for far longer. looking in the log it appears this was broke on revision 58048, where before it only defined UINT64_C, but it had a guard around it, the exact lines where: #if !defined(INT64_C) # define INT64_C(val) val##LL #endif Since these are rather well used defines, would it be possible to use the MSVC specific suffixes since these are in the MSVC specific section, as well as putting include guards around each of them? See the attached patch that does both. -------------- next part -------------- A non-text attachment was scrubbed... Name: stdint_fix.patch Type: application/octet-stream Size: 2424 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090512/03232d5b/attachment.obj From overminddl1 at gmail.com Tue May 12 16:31:06 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 15:31:06 -0600 Subject: [LLVMdev] Integer casting warning, and another set of warnings Message-ID: <3f49a9f40905121431y61a2bb58vc83d51dfd1863614@mail.gmail.com> I have a warning when building with MSVC2k5, a benign warning, but I am trying to get rid of them. ..\..\..\..\trunk\lib\Transforms\Utils\AddrModeMatcher.cpp(208) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The line of code is: Scale = 1 << Scale; Where Scale is an int64_t, however, 1 is an int32_t (since it is a non-suffixed constant). Regarding the email I *just* send about the INT64_C macros and so forth, the 1 should actually be INT64_C(1) and that should fix it. Also, getting another set of warning, but the file looks fine, so do not know... R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54113) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54121) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54167) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54175) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54211) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54430) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54515) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54565) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54706) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54767) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54860) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54894) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54902) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54937) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54963) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54986) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55070) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55089) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55097) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55105) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55144) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55187) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55195) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55331) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55339) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55347) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55355) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55426) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55434) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55442) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55450) : warning C4065: switch statement contains 'default' but no 'case' labels From overminddl1 at gmail.com Tue May 12 16:31:12 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 15:31:12 -0600 Subject: [LLVMdev] Integer casting warning, and another set of warnings Message-ID: <3f49a9f40905121431t7c65c6fexeb623a5d3e100ea7@mail.gmail.com> I have a warning when building with MSVC2k5, a benign warning, but I am trying to get rid of them. ..\..\..\..\trunk\lib\Transforms\Utils\AddrModeMatcher.cpp(208) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The line of code is: Scale = 1 << Scale; Where Scale is an int64_t, however, 1 is an int32_t (since it is a non-suffixed constant). Regarding the email I *just* send about the INT64_C macros and so forth, the 1 should actually be INT64_C(1) and that should fix it. Also, getting another set of warning, but the file looks fine, so do not know... R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54113) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54121) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54167) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54175) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54211) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54430) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54515) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54565) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54706) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54767) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54860) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54894) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54902) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54937) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54963) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(54986) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55070) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55089) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55097) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55105) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55144) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55187) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55195) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55331) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55339) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55347) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55355) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55426) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55434) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55442) : warning C4065: switch statement contains 'default' but no 'case' labels R:\SDKs\llvm\trunk_VC8_building\lib\Target\X86\X86GenDAGISel.inc(55450) : warning C4065: switch statement contains 'default' but no 'case' labels From overminddl1 at gmail.com Tue May 12 16:43:09 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 15:43:09 -0600 Subject: [LLVMdev] SparseBitVector compile warning Message-ID: <3f49a9f40905121443q680cd574gc5eaa6f037974a1b@mail.gmail.com> The warning is: R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(58) : warning C4099: 'llvm::ilist_sentinel_traits>' : type name first seen using 'struct' now seen using 'class' R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(275) : see reference to class template instantiation 'llvm::SparseBitVectorElement' being compiled R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(58) : warning C4099: 'llvm::ilist_sentinel_traits' : type name first seen using 'struct' now seen using 'class' with [ NodeTy=llvm::SparseBitVectorElement<128> ] R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(283) : see reference to class template instantiation 'llvm::SparseBitVectorElement' being compiled with [ ElementSize=128 ] ..\..\..\..\trunk\lib\Analysis\IPA\Andersens.cpp(108) : see reference to class template instantiation 'llvm::SparseBitVector<>' being compiled The problem is in the SpareBitVector.h file, line 58: friend class ilist_sentinel_traits; It should be struct, not class, as ilist_sentinel_traits is a struct, not a class: friend struct ilist_sentinel_traits; From overminddl1 at gmail.com Tue May 12 16:44:52 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 15:44:52 -0600 Subject: [LLVMdev] LibCallAliasAnalysis.h Message-ID: <3f49a9f40905121444m471d9b7y52aafcb39c7713a@mail.gmail.com> A warning: R:\SDKs\llvm\trunk\include\llvm/Analysis/LibCallSemantics.h(63) : warning C4099: 'llvm::LibCallFunctionInfo' : type name first seen using 'class' now seen using 'struct' R:\SDKs\llvm\trunk\include\llvm/Analysis/LibCallAliasAnalysis.h(22) : see declaration of 'llvm::LibCallFunctionInfo' The problem line appears to be in file LibCallAliasAnalysis.h on line 21: class LibCallFunctionInfo; LibCallFunctionInfo is actually a struct, not a class, thus the forward declaration should be: struct LibCallFunctionInfo; From overminddl1 at gmail.com Tue May 12 16:48:22 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 15:48:22 -0600 Subject: [LLVMdev] MachineJumpTableInfo.h Warning Message-ID: <3f49a9f40905121448tdf6ffe9oe55dcb7cc0e72976@mail.gmail.com> Another warning: r:\sdks\llvm\trunk\lib\target\x86\asmprinter\X86ATTAsmPrinter.h(29) : warning C4099: 'llvm::MachineJumpTableInfo' : type name first seen using 'class' now seen using 'struct' R:\SDKs\llvm\trunk\include\llvm/CodeGen/MachineFunction.h(34) : see declaration of 'llvm::MachineJumpTableInfo' The problem appears to be in file MachineJumpTableInfo.h on line 29: struct MachineJumpTableInfo; MachineJumpTableInfo is actually a class, not a struct, hence the forward declaration should be: class MachineJumpTableInfo; From eli.friedman at gmail.com Tue May 12 16:50:41 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 12 May 2009 14:50:41 -0700 Subject: [LLVMdev] [llvm-commits] MSVC cstdint In-Reply-To: <3f49a9f40905121414t6bf22586mca3dc0e0b92de303@mail.gmail.com> References: <3f49a9f40905121414t6bf22586mca3dc0e0b92de303@mail.gmail.com> Message-ID: On Tue, May 12, 2009 at 2:14 PM, OvermindDL1 wrote: > Which is more correct due to MSVC suffix (boost also defines > appropriate ones for appropriate compilers). The LLVM version is equally correct, as far as I can tell. Adding ifdefs seems reasonable, though. -Eli From isanbard at gmail.com Tue May 12 16:50:50 2009 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 12 May 2009 14:50:50 -0700 Subject: [LLVMdev] SparseBitVector compile warning In-Reply-To: <3f49a9f40905121443q680cd574gc5eaa6f037974a1b@mail.gmail.com> References: <3f49a9f40905121443q680cd574gc5eaa6f037974a1b@mail.gmail.com> Message-ID: <16e5fdf90905121450p6fb89555yfb1694136274ef4@mail.gmail.com> Done. Thanks! -bw On Tue, May 12, 2009 at 2:43 PM, OvermindDL1 wrote: > The warning is: > R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(58) : warning > C4099: 'llvm::ilist_sentinel_traits>' > : type name first seen using 'struct' now seen using 'class' > ? ? ? ?R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(275) : > see reference to class template instantiation > 'llvm::SparseBitVectorElement' being compiled > R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(58) : warning > C4099: 'llvm::ilist_sentinel_traits' : type name first seen > using 'struct' now seen using 'class' > ? ? ? ?with > ? ? ? ?[ > ? ? ? ? ? ?NodeTy=llvm::SparseBitVectorElement<128> > ? ? ? ?] > ? ? ? ?R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(283) : > see reference to class template instantiation > 'llvm::SparseBitVectorElement' being compiled > ? ? ? ?with > ? ? ? ?[ > ? ? ? ? ? ?ElementSize=128 > ? ? ? ?] > ? ? ? ?..\..\..\..\trunk\lib\Analysis\IPA\Andersens.cpp(108) : see > reference to class template instantiation 'llvm::SparseBitVector<>' > being compiled > > > The problem is in the SpareBitVector.h file, line 58: > ?friend class ilist_sentinel_traits; > It should be struct, not class, as ilist_sentinel_traits is a struct, > not a class: > ?friend struct ilist_sentinel_traits; > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From isanbard at gmail.com Tue May 12 16:55:39 2009 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 12 May 2009 14:55:39 -0700 Subject: [LLVMdev] MachineJumpTableInfo.h Warning In-Reply-To: <3f49a9f40905121448tdf6ffe9oe55dcb7cc0e72976@mail.gmail.com> References: <3f49a9f40905121448tdf6ffe9oe55dcb7cc0e72976@mail.gmail.com> Message-ID: <16e5fdf90905121455s4f15036g55adcc50da34d4a6@mail.gmail.com> Done for this and the previous. Thanks! -bw On Tue, May 12, 2009 at 2:48 PM, OvermindDL1 wrote: > Another warning: > > r:\sdks\llvm\trunk\lib\target\x86\asmprinter\X86ATTAsmPrinter.h(29) : > warning C4099: 'llvm::MachineJumpTableInfo' : type name first seen > using 'class' now seen using 'struct' > ? ? ? ?R:\SDKs\llvm\trunk\include\llvm/CodeGen/MachineFunction.h(34) > : see declaration of 'llvm::MachineJumpTableInfo' > > > The problem appears to be in file MachineJumpTableInfo.h on line 29: > struct MachineJumpTableInfo; > MachineJumpTableInfo is actually a class, not a struct, hence the > forward declaration should be: > class MachineJumpTableInfo; > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From overminddl1 at gmail.com Tue May 12 17:09:56 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 16:09:56 -0600 Subject: [LLVMdev] Compiler error: LoopStrengthReduce.cpp Message-ID: <3f49a9f40905121509s7b619c18tf1e426017b8d19cb@mail.gmail.com> The error given: ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : error C2668: 'abs' : ambiguous call to overloaded function f:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(539): could be 'long double abs(long double)' f:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(491): or 'float abs(float)' f:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(487): or 'double abs(double)' f:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(485): or 'long abs(long)' f:\Program Files\Microsoft Visual Studio 8\VC\include\stdlib.h(415): or 'int abs(int)' while trying to match the argument list '(int64_t)' It should be rather obvious from the message. The error is in LoopStrengthReduce.cpp on line 1016: (unsigned(abs(SInt)) < SSInt || (SInt % SSInt) != 0)) >From looking at the code and what it looks like it should be doing, I cannot really tell whether it should use the 32-bit override, or if it should use something like the long double override, considering this is a 64-bit integer. Either way, will not compile until a specific type override is given of the form (just an example, I do not know if the 32-bit version is what is wanted here): (unsigned(abs((int)SInt)) < SSInt || (SInt % SSInt) != 0)) From dalej at apple.com Tue May 12 18:01:45 2009 From: dalej at apple.com (Dale Johannesen) Date: Tue, 12 May 2009 16:01:45 -0700 Subject: [LLVMdev] Compiler error: LoopStrengthReduce.cpp In-Reply-To: <3f49a9f40905121509s7b619c18tf1e426017b8d19cb@mail.gmail.com> References: <3f49a9f40905121509s7b619c18tf1e426017b8d19cb@mail.gmail.com> Message-ID: <5152210A-A3E8-4933-AB68-510026474899@apple.com> On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > The error given: > > ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : > error C2668: 'abs' : ambiguous call to overloaded function > > It should be rather obvious from the message. The error is in > LoopStrengthReduce.cpp on line 1016: > (unsigned(abs(SInt)) < SSInt || (SInt % SSInt) != 0)) > >> From looking at the code and what it looks like it should be doing, I > cannot really tell whether it should use the 32-bit override, or if it > should use something like the long double override, considering this > is a 64-bit integer. It should be a 64-bit integer abs, although gcc seems to be generating code for 32-bit integer (which, in this code, would give the expected answer in any reasonable example). There are 4 occurrences of this usage in that file (with 3 different authors) so I think we need to write one; apparently nobody realized there wasn't one in the standard libraries (I didn't either). > Either way, will not compile until a specific type override is given > of the form (just an example, I do not know if the 32-bit version is > what is wanted here): > (unsigned(abs((int)SInt)) < SSInt || (SInt % SSInt) != 0)) > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From overminddl1 at gmail.com Tue May 12 19:01:31 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 18:01:31 -0600 Subject: [LLVMdev] Compiler error: LoopStrengthReduce.cpp In-Reply-To: <5152210A-A3E8-4933-AB68-510026474899@apple.com> References: <3f49a9f40905121509s7b619c18tf1e426017b8d19cb@mail.gmail.com> <5152210A-A3E8-4933-AB68-510026474899@apple.com> Message-ID: <3f49a9f40905121701k139cc4c7q168e9305ef82b530@mail.gmail.com> On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen wrote: > > On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > >> The error given: >> >> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : >> error C2668: 'abs' : ambiguous call to overloaded function >> >> It should be rather obvious from the message. ?The error is in >> LoopStrengthReduce.cpp on line 1016: >> ? ? ? ? ?(unsigned(abs(SInt)) < SSInt || (SInt % SSInt) != 0)) >> >>> From looking at the code and what it looks like it should be doing, I >> cannot really tell whether it should use the 32-bit override, or if it >> should use something like the long double override, considering this >> is a 64-bit integer. > > It should be a 64-bit integer abs, although gcc seems to be generating > code for 32-bit integer (which, in this code, would give the expected > answer in any reasonable example). ?There are 4 occurrences of this > usage in that file (with 3 different authors) so I think we need to > write one; apparently nobody realized there wasn't one in the standard > libraries (I didn't either). Ah, I mentioned it before, but was told that the error was not appearing with GCC and they were busy at the time, so I just have been inserting an (int) in my version ever since, but it reappeared when I synced back to trunk today since I deleted my version, and I have just been reporting random things I have been crossing. I noticed a few other warnings about struct/class forward declarations as well, but did not catch them in time, I intend to look through it closely later and report more. So, for now, just keep using (int) in my version until it is fixed in trunk? From omineo at gmail.com Tue May 12 19:03:46 2009 From: omineo at gmail.com (Mark A. Lyan) Date: Tue, 12 May 2009 17:03:46 -0700 Subject: [LLVMdev] LLVM and use-after-free Message-ID: <82665d1e0905121703p456a1e89pb8a56534f5ba667d@mail.gmail.com> Gurus- Do llvm-gcc or clang provide a way to catch use-after-free types of issues? Thanks, -KC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090512/0118d2b1/attachment.html From overminddl1 at gmail.com Tue May 12 19:07:32 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 18:07:32 -0600 Subject: [LLVMdev] LLVM is deleting an array pointer without using array notation Message-ID: <3f49a9f40905121707l208da516sad6f867cabfc97c7@mail.gmail.com> Here is the warning I am getting: PseudoSourceValue.cpp R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(23) : warning C4156: deletion of an array expression without using the array form of 'delete'; array form substituted R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(72) : see reference to function template instantiation 'void llvm::object_deleter(void *)' being compiled with [ C=llvm::PseudoSourceValue [4] ] R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(71) : while compiling class template member function 'void llvm::ManagedStatic::LazyInit(void) const' with [ C=llvm::PseudoSourceValue [4] ] ..\..\..\trunk\lib\CodeGen\PseudoSourceValue.cpp(23) : see reference to class template instantiation 'llvm::ManagedStatic' being compiled with [ C=llvm::PseudoSourceValue [4] ] The deleter is in the file ManagedStatic.h on line 21: template void object_deleter(void *Ptr) { delete (C*)Ptr; } And it is being passed an array to delete in file PseudoSourceValue.cpp on line 23: static ManagedStatic PSVs; A template specialization for array types will work, the tr1::type_traits or boost::type_traits (same thing and you can include the parts you wish to use with LLVM, the license encourages that) can detect an array type like that and specialize based on it. If you do not mind including a few boost files with LLVM for the Boost.Type_Traits and Boost.Enable_If then I can specialize based on an array, or you could always pass another template parameter to ManagedStatic and hope that the user of it remembers to set it when they pass an array type (safer to specialize it based on the array type obviously). Either way, MSVC is replacing the templated delete with delete[], but throwing that warning in the process since this is *very*wrong* code. From dalej at apple.com Tue May 12 19:26:00 2009 From: dalej at apple.com (Dale Johannesen) Date: Tue, 12 May 2009 17:26:00 -0700 Subject: [LLVMdev] Compiler error: LoopStrengthReduce.cpp In-Reply-To: <3f49a9f40905121701k139cc4c7q168e9305ef82b530@mail.gmail.com> References: <3f49a9f40905121509s7b619c18tf1e426017b8d19cb@mail.gmail.com> <5152210A-A3E8-4933-AB68-510026474899@apple.com> <3f49a9f40905121701k139cc4c7q168e9305ef82b530@mail.gmail.com> Message-ID: <30F4A73D-119C-4562-BA6C-4C062C80AB88@apple.com> On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen > wrote: >> >> On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: >> >>> The error given: >>> >>> ..\..\..\..\trunk\lib\Transforms\Scalar >>> \LoopStrengthReduce.cpp(1016) : >>> error C2668: 'abs' : ambiguous call to overloaded function >>> >>> It should be rather obvious from the message. The error is in >>> LoopStrengthReduce.cpp on line 1016: >>> (unsigned(abs(SInt)) < SSInt || (SInt % SSInt) != 0)) >>> >>>> From looking at the code and what it looks like it should be >>>> doing, I >>> cannot really tell whether it should use the 32-bit override, or >>> if it >>> should use something like the long double override, considering this >>> is a 64-bit integer. >> >> It should be a 64-bit integer abs, although gcc seems to be >> generating >> code for 32-bit integer (which, in this code, would give the expected >> answer in any reasonable example). There are 4 occurrences of this >> usage in that file (with 3 different authors) so I think we need to >> write one; apparently nobody realized there wasn't one in the >> standard >> libraries (I didn't either). > > Ah, I mentioned it before, but was told that the error was not > appearing with GCC and they were busy at the time, so I just have been > inserting an (int) in my version ever since, but it reappeared when I > synced back to trunk today since I deleted my version, and I have just > been reporting random things I have been crossing. I noticed a few > other warnings about struct/class forward declarations as well, but > did not catch them in time, I intend to look through it closely later > and report more. > > So, for now, just keep using (int) in my version until it is fixed > in trunk? I checked in a fix. From isanbard at gmail.com Tue May 12 19:46:17 2009 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 12 May 2009 17:46:17 -0700 Subject: [LLVMdev] RFC: Code Gen Change! Message-ID: <16e5fdf90905121746i7fcb56bbj17ae755308aa82d2@mail.gmail.com> I just finished coding up a change to how code generation builds machine instructions. The change is in include/llvm/CodeGen/MachineInstrBuilder.h, where when you want to add a register, you have to specify a long list of booleans indicating if it's defined, implicit, killed, dead, or early clobbered. I don't know about you, but it was hard for me to read the source and understand what was going on without looking at the header file. So, I made these changes. Instead of all of the booleans, you pass in a flag that has bits set to indicate what state the register is in: namespace RegState { enum { Define = 0x1, Implicit = 0x2, Kill = 0x4, Dead = 0x8, EarlyClobber = 0x10, ImplicitDefine = Implicit | Define, ImplicitKill = Implicit | Kill }; } class MachineInstrBuilder { MachineInstr *MI; public: explicit MachineInstrBuilder(MachineInstr *mi) : MI(mi) {} /// addReg - Add a new virtual register operand... /// const MachineInstrBuilder &addReg(unsigned RegNo, unsigned flags = 0, unsigned SubReg = 0) const { MI->addOperand(MachineOperand::CreateReg(RegNo, flags & RegState::Define, flags & RegState::Implicit, flags & RegState::Kill, flags & RegState::Dead, SubReg, flags & RegState::EarlyClobber)); return *this; } To use this, you would do something like: BuildMI(...).addReg(Reg, RegState::Kill); etc. In a lot of cases, an explicit true/false isn't passed into the addReg method. I added some helper functions to help make this less of a pain: inline unsigned getDefRegState(bool B) { return B ? RegState::Define : 0; } inline unsigned getImplRegState(bool B) { return B ? RegState::Implicit : 0; } inline unsigned getKillRegState(bool B) { return B ? RegState::Kill : 0; } inline unsigned getDeadRegState(bool B) { return B ? RegState::Dead : 0; } So you can use them like this: BuildMI(...).addReg(Reg, getKillRegState(isKill); My hope is that this is a cleaner way of building these machine instructions. Comments and suggestions are welcome. -bw From isanbard at gmail.com Tue May 12 19:47:30 2009 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 12 May 2009 17:47:30 -0700 Subject: [LLVMdev] LLVM and use-after-free In-Reply-To: <82665d1e0905121703p456a1e89pb8a56534f5ba667d@mail.gmail.com> References: <82665d1e0905121703p456a1e89pb8a56534f5ba667d@mail.gmail.com> Message-ID: <16e5fdf90905121747sbb86884nef60250ae1135292@mail.gmail.com> On Tue, May 12, 2009 at 5:03 PM, Mark A. Lyan wrote: > Gurus- > > Do?llvm-gcc or clang provide a way to catch use-after-free types of issues? > llvm-gcc and clang don't. But I believe that the static analyzer has facilities for this. http://clang.llvm.org/StaticAnalysis.html -bw From lefever at crhc.illinois.edu Tue May 12 20:23:19 2009 From: lefever at crhc.illinois.edu (Ryan M. Lefever) Date: Tue, 12 May 2009 20:23:19 -0500 Subject: [LLVMdev] using bugpoint Message-ID: <4A0A2107.3060809@crhc.illinois.edu> I am trying to use bugpoint to reduce the bytecode for a bug in one of my transformations. Normally I run opt as such: opt -load=libmine.so -mypass -param1 -param2 -o b.bc a.bc Here, -mypass specifies a pass and -param1 and -param2 are just parameters that -mypass uses. I added them using the command line parsing library that llvm supports. I tried running bugpoint with the following: bugpoint -load=libmine.so a.bc -mypass -param1 -param2 However, bugpoint always eliminates -param1 and -param2 from the list and runs into an assertion that will currently always happen if -param1 and -param2 are not specified. I have also tried to put --args -- in front of -param1 -param2 and --tool-args -- in front of -param1 -param2, and neither have helped. How do I force bugpoint to keep the -param1 and -param2? Regards, Ryan From sunisg123 at gmail.com Tue May 12 08:21:28 2009 From: sunisg123 at gmail.com (sunitac) Date: Tue, 12 May 2009 06:21:28 -0700 (PDT) Subject: [LLVMdev] Data Dependency graph In-Reply-To: References: Message-ID: <23502478.post@talk.nabble.com> Hi I too need to generate a data dependency graph. Have not been able to generate so far. I have tried using Dragon tool of Open64, but it is specific to arrays only. I am looking for some detailed dependency graph, that would show me the true, anti and output dependencies. I have played around with Rose compiler and its associated graphic tools, but again, they are too clustered and cannot see any such explicit dependencies. Any suggestions ? Thank you. Sunita Chris Lattner-2 wrote: > > > On Dec 4, 2008, at 3:07 PM, Nipun Arora wrote: > >> Hi, >> >> I need to generate a data dependancy graph. Is there any >> functionality available in LLVM which can help me? Or if anyone can >> point to the correct place? > > There are many different forms of dependency graph, do you mean for > loop dependencies, load and store dependencies, def/use dependencies, > etc? > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- View this message in context: http://www.nabble.com/Data-Dependency-graph-tp20844677p23502478.html Sent from the LLVM - Dev mailing list archive at Nabble.com. From stoklund at 2pi.dk Wed May 13 00:10:08 2009 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Wed, 13 May 2009 07:10:08 +0200 Subject: [LLVMdev] RFC: Code Gen Change! In-Reply-To: <16e5fdf90905121746i7fcb56bbj17ae755308aa82d2@mail.gmail.com> References: <16e5fdf90905121746i7fcb56bbj17ae755308aa82d2@mail.gmail.com> Message-ID: On 13/05/2009, at 02.46, Bill Wendling wrote: > Instead of all of the booleans, you pass in a flag that has bits set > to indicate what state the register is in: > > namespace RegState { > enum { > Define = 0x1, > Implicit = 0x2, > Kill = 0x4, > Dead = 0x8, > EarlyClobber = 0x10, > ImplicitDefine = Implicit | Define, > ImplicitKill = Implicit | Kill > }; > } [...] > MachineInstrBuilder &addReg(unsigned RegNo, unsigned flags = 0, > unsigned SubReg = 0) const { Hi Bill, I definitely like this change. The staccato bool arguments are impossible to read. One comment: If I forget to update an addReg(Reg, true) call, it will still compile and work by accident. If you leave bit 0 unused by the enum and assert(flags&1 == 0), you make sure I have updated all my addReg calls. Humans being human, we are going to fix addReg calls until everything compiles and passes 'make check'. I don't think addReg(Reg, true) should be allowed to survive the API change. /jakob From overminddl1 at gmail.com Wed May 13 00:24:28 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 23:24:28 -0600 Subject: [LLVMdev] MSVC compile error with trunk Message-ID: <3f49a9f40905122224oba97a9av3c1635e4133dc2ff@mail.gmail.com> Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall llvm::IVUsers::AddUsersIfInteresting(class llvm::Instruction *)" (?AddUsersIfInteresting at IVUsers@llvm@@QAE_NPAVInstruction at 2@@Z) referenced in function "public: virtual bool __thiscall `anonymous namespace'::IndVarSimplify::runOnLoop(class llvm::LoopBase *,class llvm::LPPassManager &)" (?runOnLoop at IndVarSimplify@?A0xe882fe7a@@UAE_NPAV?$LoopBase at VBasicBlock@llvm@@@llvm@@AAVLPPassManager at 4@@Z) 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: class llvm::SCEVHandle __thiscall llvm::IVUsers::getReplacementExpr(class llvm::IVStrideUse const &)const " (?getReplacementExpr at IVUsers@llvm@@QBE?AVSCEVHandle at 2@ABVIVStrideUse at 2@@Z) referenced in function "private: void __thiscall `anonymous namespace'::IndVarSimplify::RewriteIVExpressions(class llvm::LoopBase *,class llvm::Type const *,struct llvm::SCEVExpander &)" (?RewriteIVExpressions at IndVarSimplify@?A0xe882fe7a@@AAEXPAV?$LoopBase at VBasicBlock@llvm@@@llvm@@PBVType at 4@AAUSCEVExpander at 4@@Z) 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 30>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 30>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "private: virtual void __thiscall llvm::IVStrideUse::deleted(void)" (?deleted at IVStrideUse@llvm@@EAEXXZ) 30>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\opt.exe : fatal error LNK1120: 4 unresolved externals llc: 33> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\llc.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\llc.exp 33>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "private: virtual void __thiscall llvm::IVStrideUse::deleted(void)" (?deleted at IVStrideUse@llvm@@EAEXXZ) 33>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 33>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\llc.exe : fatal error LNK1120: 2 unresolved externals lli: 40> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\lli.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\lli.exp 40>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "private: virtual void __thiscall llvm::IVStrideUse::deleted(void)" (?deleted at IVStrideUse@llvm@@EAEXXZ) 40>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 40>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\lli.exe : fatal error LNK1120: 2 unresolved externals BrainF: 46> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\BrainF.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\BrainF.exp 46>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "private: virtual void __thiscall llvm::IVStrideUse::deleted(void)" (?deleted at IVStrideUse@llvm@@EAEXXZ) 46>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 46>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\BrainF.exe : fatal error LNK1120: 2 unresolved externals bugpoint: 43> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\bugpoint.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\bugpoint.exp 43>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "private: virtual void __thiscall llvm::IVStrideUse::deleted(void)" (?deleted at IVStrideUse@llvm@@EAEXXZ) 43>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 43>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 43>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall llvm::IVUsers::AddUsersIfInteresting(class llvm::Instruction *)" (?AddUsersIfInteresting at IVUsers@llvm@@QAE_NPAVInstruction at 2@@Z) referenced in function "public: virtual bool __thiscall `anonymous namespace'::IndVarSimplify::runOnLoop(class llvm::LoopBase *,class llvm::LPPassManager &)" (?runOnLoop at IndVarSimplify@?A0xe882fe7a@@UAE_NPAV?$LoopBase at VBasicBlock@llvm@@@llvm@@AAVLPPassManager at 4@@Z) 43>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: class llvm::SCEVHandle __thiscall llvm::IVUsers::getReplacementExpr(class llvm::IVStrideUse const &)const " (?getReplacementExpr at IVUsers@llvm@@QBE?AVSCEVHandle at 2@ABVIVStrideUse at 2@@Z) referenced in function "private: void __thiscall `anonymous namespace'::IndVarSimplify::RewriteIVExpressions(class llvm::LoopBase *,class llvm::Type const *,struct llvm::SCEVExpander &)" (?RewriteIVExpressions at IndVarSimplify@?A0xe882fe7a@@AAEXPAV?$LoopBase at VBasicBlock@llvm@@@llvm@@PBVType at 4@AAUSCEVExpander at 4@@Z) 43>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\bugpoint.exe : fatal error LNK1120: 4 unresolved externals Fibonacci: 48>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "private: virtual void __thiscall llvm::IVStrideUse::deleted(void)" (?deleted at IVStrideUse@llvm@@EAEXXZ) 48>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 48>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\Fibonacci.exe : fatal error LNK1120: 2 unresolved externals HowToUseJIT: 49> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\HowToUseJIT.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\HowToUseJIT.exp 49>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "private: virtual void __thiscall llvm::IVStrideUse::deleted(void)" (?deleted at IVStrideUse@llvm@@EAEXXZ) 49>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 49>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\HowToUseJIT.exe : fatal error LNK1120: 2 unresolved externals Kaleidoscope: 50> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\Kaleidoscope.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\Kaleidoscope.exp 50>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "private: virtual void __thiscall llvm::IVStrideUse::deleted(void)" (?deleted at IVStrideUse@llvm@@EAEXXZ) 50>LLVMScalarOpts.lib(LoopStrengthReduce.obj) : error LNK2001: unresolved external symbol "public: static char llvm::IVUsers::ID" (?ID at IVUsers@llvm@@2DA) 50>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\Kaleidoscope.exe : fatal error LNK1120: 2 unresolved externals Yes, I know they are mostly duplicated linking errors, but this also shows all the apps that fail as well, since not all fail. This was with MSVC2k5 in debug build, happens in all build types though. From clattner at apple.com Wed May 13 00:40:47 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 12 May 2009 22:40:47 -0700 Subject: [LLVMdev] MSVC compile error with trunk In-Reply-To: <3f49a9f40905122224oba97a9av3c1635e4133dc2ff@mail.gmail.com> References: <3f49a9f40905122224oba97a9av3c1635e4133dc2ff@mail.gmail.com> Message-ID: <3A62D0AB-AFC1-4778-888D-D35F7BED8195@apple.com> On May 12, 2009, at 10:24 PM, OvermindDL1 wrote: > Does not seem to be a straight error with LLVM itself, but rather the > tools, linking issues, here are the errors: Please prepare a patch, thanks! -Chris From isanbard at gmail.com Wed May 13 00:42:47 2009 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 12 May 2009 22:42:47 -0700 Subject: [LLVMdev] RFC: Code Gen Change! In-Reply-To: References: <16e5fdf90905121746i7fcb56bbj17ae755308aa82d2@mail.gmail.com> Message-ID: On May 12, 2009, at 10:10 PM, Jakob Stoklund Olesen wrote: > On 13/05/2009, at 02.46, Bill Wendling wrote: >> Instead of all of the booleans, you pass in a flag that has bits set >> to indicate what state the register is in: >> >> namespace RegState { >> enum { >> Define = 0x1, >> Implicit = 0x2, >> Kill = 0x4, >> Dead = 0x8, >> EarlyClobber = 0x10, >> ImplicitDefine = Implicit | Define, >> ImplicitKill = Implicit | Kill >> }; >> } > [...] >> MachineInstrBuilder &addReg(unsigned RegNo, unsigned flags = 0, >> unsigned SubReg = 0) const { > > Hi Bill, > > I definitely like this change. The staccato bool arguments are > impossible to read. One comment: > > If I forget to update an addReg(Reg, true) call, it will still compile > and work by accident. If you leave bit 0 unused by the enum and > assert(flags&1 == 0), you make sure I have updated all my addReg > calls. > > Humans being human, we are going to fix addReg calls until everything > compiles and passes 'make check'. I don't think addReg(Reg, true) > should be allowed to survive the API change. > True. I went over all of the "addReg()" calls and tried to cover all of them. Your suggestion would be a good way to stop errors from sneaking back in. :-) -bw From overminddl1 at gmail.com Wed May 13 00:59:51 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Tue, 12 May 2009 23:59:51 -0600 Subject: [LLVMdev] Compiler error: LoopStrengthReduce.cpp In-Reply-To: <30F4A73D-119C-4562-BA6C-4C062C80AB88@apple.com> References: <3f49a9f40905121509s7b619c18tf1e426017b8d19cb@mail.gmail.com> <5152210A-A3E8-4933-AB68-510026474899@apple.com> <3f49a9f40905121701k139cc4c7q168e9305ef82b530@mail.gmail.com> <30F4A73D-119C-4562-BA6C-4C062C80AB88@apple.com> Message-ID: <3f49a9f40905122259m21263486qb8410c12bcbb0857@mail.gmail.com> On Tue, May 12, 2009 at 6:26 PM, Dale Johannesen wrote: > > On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > >> On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen >> wrote: >>> >>> On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: >>> >>>> The error given: >>>> >>>> ..\..\..\..\trunk\lib\Transforms\Scalar >>>> \LoopStrengthReduce.cpp(1016) : >>>> error C2668: 'abs' : ambiguous call to overloaded function >>>> >>>> It should be rather obvious from the message. ?The error is in >>>> LoopStrengthReduce.cpp on line 1016: >>>> ? ? ? ? ?(unsigned(abs(SInt)) < SSInt || (SInt % SSInt) != 0)) >>>> >>>>> From looking at the code and what it looks like it should be >>>>> doing, I >>>> cannot really tell whether it should use the 32-bit override, or >>>> if it >>>> should use something like the long double override, considering this >>>> is a 64-bit integer. >>> >>> It should be a 64-bit integer abs, although gcc seems to be >>> generating >>> code for 32-bit integer (which, in this code, would give the expected >>> answer in any reasonable example). ?There are 4 occurrences of this >>> usage in that file (with 3 different authors) so I think we need to >>> write one; apparently nobody realized there wasn't one in the >>> standard >>> libraries (I didn't either). >> >> Ah, I mentioned it before, but was told that the error was not >> appearing with GCC and they were busy at the time, so I just have been >> inserting an (int) in my version ever since, but it reappeared when I >> synced back to trunk today since I deleted my version, and I have just >> been reporting random things I have been crossing. ?I noticed a few >> other warnings about struct/class forward declarations as well, but >> did not catch them in time, I intend to look through it closely later >> and report more. >> >> So, for now, just keep using (int) in my version until it is fixed >> in trunk? > > I checked in a fix. Also, IndVarSimplify.cpp has the same problem, only one abs usage in it, line 700: if (Max.getZExtValue() > static_cast(abs(intEV - intIV))) Following your style change: if (Max.getZExtValue() > static_cast(abs64(intEV - intIV))) Also, why make an abs64, why not just override abs with 64 bit parameters? From overminddl1 at gmail.com Wed May 13 01:19:31 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Wed, 13 May 2009 00:19:31 -0600 Subject: [LLVMdev] MSVC compile error with trunk In-Reply-To: References: <3f49a9f40905122224oba97a9av3c1635e4133dc2ff@mail.gmail.com> <3A62D0AB-AFC1-4778-888D-D35F7BED8195@apple.com> <3f49a9f40905122254m6af01f15ja6fc38c97326afdb@mail.gmail.com> Message-ID: <3f49a9f40905122319x7d7b1c56x1a0287708426fcec@mail.gmail.com> On Tue, May 12, 2009 at 11:55 PM, Chris Lattner wrote: > Dan, can you add IVUsers.cpp to the appropriate cmakefile? > > -chris > > > On May 12, 2009, at 10:54 PM, OvermindDL1 wrote: > >> On Tue, May 12, 2009 at 11:40 PM, Chris Lattner >> wrote: >>> >>> On May 12, 2009, at 10:24 PM, OvermindDL1 wrote: >>> >>>> Does not seem to be a straight error with LLVM itself, but rather the >>>> tools, linking issues, here are the errors: >>> >>> Please prepare a patch, thanks! >> >> >> Still trying to hunt it down, but from what it seems so far, the file >> IVUsers.cpp does not seem to be compiled into any library, not >> compiled at all (using cmake). ?I am not sure which library it is >> supposed to be compiled into, LLVMAnalysis? ?If so then IVUsers.cpp >> needs to be added to the CMakeLists.txt in the lib/analysis/ >> directory. ?And just checked, the IVStrideUse::deleter error is also >> defined in the IVUser.cpp file as well, so including that will >> probably fix it. ?Going to resync to trunk again just to make sure, >> add that to the analysis CMakeLists.txt file, and compile to see if >> that works, if so I will submit a patch. Confirmed, once IVUsers.cpp is added to the LLVMAnalysis library, fixed some of those errors, but there are more still. Patch is attached for the IVUsers.cpp add to the CMakeLists.txt file. 32> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\llc.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\llc.exp 32>LLVMCodeGen.lib(PrologEpilogInserter.obj) : error LNK2001: unresolved external symbol "public: virtual void __thiscall llvm::PEI::getAnalysisUsage(class llvm::AnalysisUsage &)const " (?getAnalysisUsage at PEI@llvm@@UBEXAAVAnalysisUsage at 2@@Z) 32>LLVMCodeGen.lib(PrologEpilogInserter.obj) : error LNK2019: unresolved external symbol "private: void __thiscall llvm::PEI::clearAllSets(void)" (?clearAllSets at PEI@llvm@@AAEXXZ) referenced in function "public: virtual bool __thiscall llvm::PEI::runOnMachineFunction(class llvm::MachineFunction &)" (?runOnMachineFunction at PEI@llvm@@UAE_NAAVMachineFunction at 2@@Z) 32>LLVMCodeGen.lib(PrologEpilogInserter.obj) : error LNK2019: unresolved external symbol "private: void __thiscall llvm::PEI::placeCSRSpillsAndRestores(class llvm::MachineFunction &)" (?placeCSRSpillsAndRestores at PEI@llvm@@AAEXAAVMachineFunction at 2@@Z) referenced in function "public: virtual bool __thiscall llvm::PEI::runOnMachineFunction(class llvm::MachineFunction &)" (?runOnMachineFunction at PEI@llvm@@UAE_NAAVMachineFunction at 2@@Z) 32>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\llc.exe : fatal error LNK1120: 3 unresolved externals Do note, this linking error appears a few times, but they are all identical to this one, looks like the last. -------------- next part -------------- A non-text attachment was scrubbed... Name: IVUsers_cpp_to_CMakeLists.patch Type: application/octet-stream Size: 363 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090513/ea76cf9a/attachment.obj From overminddl1 at gmail.com Wed May 13 01:23:36 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Wed, 13 May 2009 00:23:36 -0600 Subject: [LLVMdev] MSVC compile error with trunk In-Reply-To: <3f49a9f40905122319x7d7b1c56x1a0287708426fcec@mail.gmail.com> References: <3f49a9f40905122224oba97a9av3c1635e4133dc2ff@mail.gmail.com> <3A62D0AB-AFC1-4778-888D-D35F7BED8195@apple.com> <3f49a9f40905122254m6af01f15ja6fc38c97326afdb@mail.gmail.com> <3f49a9f40905122319x7d7b1c56x1a0287708426fcec@mail.gmail.com> Message-ID: <3f49a9f40905122323o4133798bn80bf69328f114503@mail.gmail.com> On Wed, May 13, 2009 at 12:19 AM, OvermindDL1 wrote: > On Tue, May 12, 2009 at 11:55 PM, Chris Lattner wrote: >> Dan, can you add IVUsers.cpp to the appropriate cmakefile? >> >> -chris >> >> >> On May 12, 2009, at 10:54 PM, OvermindDL1 wrote: >> >>> On Tue, May 12, 2009 at 11:40 PM, Chris Lattner >>> wrote: >>>> >>>> On May 12, 2009, at 10:24 PM, OvermindDL1 wrote: >>>> >>>>> Does not seem to be a straight error with LLVM itself, but rather the >>>>> tools, linking issues, here are the errors: >>>> >>>> Please prepare a patch, thanks! >>> >>> >>> Still trying to hunt it down, but from what it seems so far, the file >>> IVUsers.cpp does not seem to be compiled into any library, not >>> compiled at all (using cmake). ?I am not sure which library it is >>> supposed to be compiled into, LLVMAnalysis? ?If so then IVUsers.cpp >>> needs to be added to the CMakeLists.txt in the lib/analysis/ >>> directory. ?And just checked, the IVStrideUse::deleter error is also >>> defined in the IVUser.cpp file as well, so including that will >>> probably fix it. ?Going to resync to trunk again just to make sure, >>> add that to the analysis CMakeLists.txt file, and compile to see if >>> that works, if so I will submit a patch. > > > Confirmed, once IVUsers.cpp is added to the LLVMAnalysis library, > fixed some of those errors, but there are more still. ?Patch is > attached for the IVUsers.cpp add to the CMakeLists.txt file. > > 32> ? Creating library > R:\SDKs\llvm\trunk_VC8_building\lib\Debug\llc.lib and object > R:\SDKs\llvm\trunk_VC8_building\lib\Debug\llc.exp > 32>LLVMCodeGen.lib(PrologEpilogInserter.obj) : error LNK2001: > unresolved external symbol "public: virtual void __thiscall > llvm::PEI::getAnalysisUsage(class llvm::AnalysisUsage &)const " > (?getAnalysisUsage at PEI@llvm@@UBEXAAVAnalysisUsage at 2@@Z) > 32>LLVMCodeGen.lib(PrologEpilogInserter.obj) : error LNK2019: > unresolved external symbol "private: void __thiscall > llvm::PEI::clearAllSets(void)" (?clearAllSets at PEI@llvm@@AAEXXZ) > referenced in function "public: virtual bool __thiscall > llvm::PEI::runOnMachineFunction(class llvm::MachineFunction &)" > (?runOnMachineFunction at PEI@llvm@@UAE_NAAVMachineFunction at 2@@Z) > 32>LLVMCodeGen.lib(PrologEpilogInserter.obj) : error LNK2019: > unresolved external symbol "private: void __thiscall > llvm::PEI::placeCSRSpillsAndRestores(class llvm::MachineFunction &)" > (?placeCSRSpillsAndRestores at PEI@llvm@@AAEXAAVMachineFunction at 2@@Z) > referenced in function "public: virtual bool __thiscall > llvm::PEI::runOnMachineFunction(class llvm::MachineFunction &)" > (?runOnMachineFunction at PEI@llvm@@UAE_NAAVMachineFunction at 2@@Z) > 32>R:\SDKs\llvm\trunk_VC8_building\bin\Debug\llc.exe : fatal error > LNK1120: 3 unresolved externals > > > Do note, this linking error appears a few times, but they are all > identical to this one, looks like the last. > Yep, missing ShrinkWrapping.cpp in the lib\CodeGen\CMakeLists.txt file. Have not tested (out of time, need to stop this), but I am rather certain that it is just that problem now. From llvm at assumetheposition.nl Wed May 13 05:35:04 2009 From: llvm at assumetheposition.nl (Paul Melis) Date: Wed, 13 May 2009 12:35:04 +0200 (CEST) Subject: [LLVMdev] Slightly OT: LLVM in NVidia OpenCL Message-ID: <43196.146.50.22.50.1242210904.squirrel@www.assumetheposition.nl> Well well, LLVM seems to be everywhere these days :) >From the OpenCL SDK release notes: NOTICE: Portions of the NVIDIA system software contain components licensed from third parties under the following terms: Clang & LLVM: Copyright (c) 2003-2008 University of Illinois at Urbana-Champaign. All rights reserved. Portions of LLVM's System library: Copyright (C) 2004 eXtensible Systems, Inc. Developed by: LLVM Team University of Illinois at Urbana-Champaign http://llvm.org Can anyone shed some light on how exactly NVidia is using LLVM? Thanks, Paul From e0325716 at student.tuwien.ac.at Wed May 13 08:04:17 2009 From: e0325716 at student.tuwien.ac.at (Andreas Neustifter) Date: Wed, 13 May 2009 15:04:17 +0200 Subject: [LLVMdev] ModulePass using BreakCriticalEdges Message-ID: <4A0AC551.7000000@student.tuwien.ac.at> Hi, I'm writing a ModulePass that needs critical edges split up. I have the statement AU.addRequiredID(BreakCriticalEdgesID); in my getAnalysisUsage() but the pass never gets executed. I guess I have to request pass execution for each function, but I can't get behind how to do that, since there is no analysis group for that kind of transformation. Thanks, Andi From Timo.Stripf at itiv.uni-karlsruhe.de Wed May 13 09:22:27 2009 From: Timo.Stripf at itiv.uni-karlsruhe.de (Stripf, Timo) Date: Wed, 13 May 2009 16:22:27 +0200 Subject: [LLVMdev] TableGen: NumResults <= 1 restriction Message-ID: <041DD5ACCD9F824BB2273B9421CA13D2FCF485@RZ-EX-06.rz.uni-karlsruhe.de> Hi all, i'm working atm on a backend for a processor architecture that is capable of storing the carry flag of ADDC in an 1-bit register class. So I tried to lower the ADDC instruction to generate two register values as result. On the tablegen description of the instruction i came across the tablegen restriction that only one output result of one instruction is possible: assert(NumResults <= 1 && "We only work with nodes with zero or one result so far!"); So my question is now how much work it would be to remove this restriction in tablegen. What do I have to take into consideration? Thanks, Timo Stripf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090513/48e9ae71/attachment.html From tynarex at gmail.com Wed May 13 09:30:36 2009 From: tynarex at gmail.com (Wenhao Jia) Date: Wed, 13 May 2009 10:30:36 -0400 Subject: [LLVMdev] Loop-carried Dependence Message-ID: <2015205e0905130730j233c8535o5b0cfe03ed844f00@mail.gmail.com> Hi, Does anyone know if there is any existing code I can use to do a loop-carried dependence analysis for LLVM IR programs? I searched the mailing-list archive and it seems like someone planned to implement a loop dependence analysis pass in March. I'm just wondering if this project is ongoing/finished or if there is other projects that may have the code I'm interested in. Thanks! Wenhao Jia From e0325716 at student.tuwien.ac.at Wed May 13 09:39:20 2009 From: e0325716 at student.tuwien.ac.at (Andreas Neustifter) Date: Wed, 13 May 2009 16:39:20 +0200 Subject: [LLVMdev] ModulePass using BreakCriticalEdges [Followup] In-Reply-To: <4A0AC551.7000000@student.tuwien.ac.at> References: <4A0AC551.7000000@student.tuwien.ac.at> Message-ID: <4A0ADB98.1030902@student.tuwien.ac.at> Hi, Andreas Neustifter wrote: > I'm writing a ModulePass that needs critical edges split up. I have the > statement > > AU.addRequiredID(BreakCriticalEdgesID); > > in my getAnalysisUsage() but the pass never gets executed. > > I guess I have to request pass execution for each function, but I can't > get behind how to do that, since there is no analysis group for that > kind of transformation. I now also added a (selfwritten) FunctionPass with is member of the analysis group ProfileInfo AU.addRequiredID(ProfileEstimatorID); AU.addRequired(); and fetching the ProfileInfo by executing ProfileInfo *PI = &getAnalysis(*F); and now the BreakCriticalEdge pass gets also executed. Seems to me that the FunctionPassManager generated when requesting the ProfileInfo also executes the BreakCriticalEdges pass. Andi From Timo.Stripf at itiv.uni-karlsruhe.de Wed May 13 09:37:19 2009 From: Timo.Stripf at itiv.uni-karlsruhe.de (Stripf, Timo) Date: Wed, 13 May 2009 16:37:19 +0200 Subject: [LLVMdev] TableGen: NumResults <= 1 restriction In-Reply-To: <4A0AC551.7000000@student.tuwien.ac.at> References: <4A0AC551.7000000@student.tuwien.ac.at> Message-ID: <041DD5ACCD9F824BB2273B9421CA13D2FCF489@RZ-EX-06.rz.uni-karlsruhe.de> Hi all, i'm working atm on a backend for a processor architecture that is capable of storing the carry flag of ADDC in an 1-bit register class. So I tried to lower the ADDC instruction to generate two register values as result. On the tablegen description of the instruction i came across the tablegen restriction that only one output result of one instruction is possible: assert(NumResults <= 1 && "We only work with nodes with zero or one result so far!"); So my question is now how much work it would be to remove this restriction in tablegen. What do I have to take into consideration? Thanks, Timo Stripf From Timo.Stripf at itiv.uni-karlsruhe.de Wed May 13 09:46:01 2009 From: Timo.Stripf at itiv.uni-karlsruhe.de (Stripf, Timo) Date: Wed, 13 May 2009 16:46:01 +0200 Subject: [LLVMdev] WG: TableGen: NumResults <= 1 restriction Message-ID: <041DD5ACCD9F824BB2273B9421CA13D2FCF48A@RZ-EX-06.rz.uni-karlsruhe.de> Hi all, i'm working atm on a backend for a processor architecture that is capable of storing the carry flag of ADDC in an 1-bit register class. So I tried to lower the ADDC instruction to generate two register values as result. On the tablegen description of the instruction i came across the tablegen restriction that only one output result of one instruction is possible: assert(NumResults <= 1 && "We only work with nodes with zero or one result so far!"); So my question is now how much work it would be to remove this restriction in tablegen. What do I have to take into consideration? Thanks, Timo Stripf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090513/e24c4bda/attachment.html From rdogra at earthlink.net Wed May 13 10:45:48 2009 From: rdogra at earthlink.net (=?UTF-8?B?4KSw4KSc4KSo4KWA4KS2?=) Date: Wed, 13 May 2009 08:45:48 -0700 Subject: [LLVMdev] Slightly OT: LLVM in NVidia OpenCL Message-ID: <2A8CF654-CE44-4D91-B866-28BFA63F750A@earthlink.net> Nothing to get excited about. OpenCL == JITted C code. How many c99 compiler do you know that can jit C code? Its been open secret for long time in fact first entry of opencl in wikipedia mentioned clang/llvm but was removed after sometime. Intel podcast mentioned it. gcc mailing list pondered it. etc... Apple has used LLVM to jit OpenGL. so it is natural progression with OpenCL. In fact why do you think all the interpreted languages are jumping to using LLVM. free JIT and multicore support. > Well well, LLVM seems to be everywhere these days :) > >From the OpenCL SDK release notes: > > NOTICE: Portions of the NVIDIA system software contain components > licensed > from third parties under the following terms: > > Clang & LLVM: > Copyright (c) 2003-2008 University of Illinois at Urbana-Champaign. > All rights reserved. > > Portions of LLVM's System library: > Copyright (C) 2004 eXtensible Systems, Inc. > > Developed by: > LLVM Team > University of Illinois at Urbana-Champaign > http://llvm.org > Can anyone shed some light on how exactly NVidia is using LLVM? > Thanks, > Paul > From clattner at apple.com Wed May 13 12:13:59 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 13 May 2009 10:13:59 -0700 Subject: [LLVMdev] ModulePass using BreakCriticalEdges [Followup] In-Reply-To: <4A0ADB98.1030902@student.tuwien.ac.at> References: <4A0AC551.7000000@student.tuwien.ac.at> <4A0ADB98.1030902@student.tuwien.ac.at> Message-ID: <2F263070-7909-4B63-B701-1A4E1654BBE6@apple.com> On May 13, 2009, at 7:39 AM, Andreas Neustifter wrote: > Hi, > > Andreas Neustifter wrote: >> I'm writing a ModulePass that needs critical edges split up. I have >> the >> statement >> >> AU.addRequiredID(BreakCriticalEdgesID); >> >> in my getAnalysisUsage() but the pass never gets executed. >> >> I guess I have to request pass execution for each function, but I >> can't >> get behind how to do that, since there is no analysis group for that >> kind of transformation. > > I now also added a (selfwritten) FunctionPass with is member of the > analysis group ProfileInfo This isn't an answer to your question, but you can also use the SplitCriticalEdge family of functions from your pass, without using the BreakCriticalEdges pass. -Chris From clattner at apple.com Wed May 13 12:14:26 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 13 May 2009 10:14:26 -0700 Subject: [LLVMdev] TableGen: NumResults <= 1 restriction In-Reply-To: <041DD5ACCD9F824BB2273B9421CA13D2FCF485@RZ-EX-06.rz.uni-karlsruhe.de> References: <041DD5ACCD9F824BB2273B9421CA13D2FCF485@RZ-EX-06.rz.uni-karlsruhe.de> Message-ID: <0B94D2F6-D5C2-4F39-BA2F-BA9A81DCB982@apple.com> On May 13, 2009, at 7:22 AM, Stripf, Timo wrote: > Hi all, > > i?m working atm on a backend for a processor architecture that is > capable of storing the carry flag of ADDC in an 1-bit register > class. So I tried to lower the ADDC instruction to generate two > register values as result. On the tablegen description of the > instruction i came across the tablegen restriction that only one > output result of one instruction is possible: > > assert(NumResults <= 1 && > "We only work with nodes with zero or one result so far!"); > > So my question is now how much work it would be to remove this > restriction in tablegen. What do I have to take into consideration? > I don't know offhand, but this would be a very welcome improvement! -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090513/be35e999/attachment.html From hc2428 at columbia.edu Wed May 13 13:36:32 2009 From: hc2428 at columbia.edu (hc2428 at columbia.edu) Date: Wed, 13 May 2009 14:36:32 -0400 Subject: [LLVMdev] DataStructure Analysis ds-aa can not stop when passing mysqld In-Reply-To: <0B94D2F6-D5C2-4F39-BA2F-BA9A81DCB982@apple.com> References: <041DD5ACCD9F824BB2273B9421CA13D2FCF485@RZ-EX-06.rz.uni-karlsruhe.de> <0B94D2F6-D5C2-4F39-BA2F-BA9A81DCB982@apple.com> Message-ID: <20090513143632.pq8gvq8ksok8oo48@cubmail.cc.columbia.edu> Quoting Chris Lattner : Dear staff, I am using the ds-aa to pass mysqld. I compile mysqld 4.0.12 statically (compile all libraries statically to the executable) and got the bc file, named it as mysqld.bc3. I use the command to pass: opt -load /lib/libLLVMDataStructure.so -ds-aa mysqld.bc3 -print-alias-sets -disable-output However, I got a lot of "cast in ... " on output screen like this: cast in strxnmov %13 = inttoptr i32 %10 to i8* ; [#uses=1] In addition, and pass can not stop for a long time, and the last output is the "cast in ... " as above. Thanks, Heming > > On May 13, 2009, at 7:22 AM, Stripf, Timo wrote: > >> Hi all, >> >> i?m working atm on a backend for a processor architecture that is >> capable of storing the carry flag of ADDC in an 1-bit register >> class. So I tried to lower the ADDC instruction to generate two >> register values as result. On the tablegen description of the >> instruction i came across the tablegen restriction that only one >> output result of one instruction is possible: >> >> assert(NumResults <= 1 && >> "We only work with nodes with zero or one result so far!"); >> >> So my question is now how much work it would be to remove this >> restriction in tablegen. What do I have to take into consideration? >> > > I don't know offhand, but this would be a very welcome improvement! > > -Chris From hc2428 at columbia.edu Wed May 13 13:39:17 2009 From: hc2428 at columbia.edu (hc2428 at columbia.edu) Date: Wed, 13 May 2009 14:39:17 -0400 Subject: [LLVMdev] DataStructure Analysis ds-aa can not stop when passing mysqld In-Reply-To: <20090513143632.pq8gvq8ksok8oo48@cubmail.cc.columbia.edu> References: <041DD5ACCD9F824BB2273B9421CA13D2FCF485@RZ-EX-06.rz.uni-karlsruhe.de> <0B94D2F6-D5C2-4F39-BA2F-BA9A81DCB982@apple.com> <20090513143632.pq8gvq8ksok8oo48@cubmail.cc.columbia.edu> Message-ID: <20090513143917.84b0n83qhcsc8sco@cubmail.cc.columbia.edu> Quoting hc2428 at columbia.edu: Dear staff, Here is the bc file. Heming > Quoting Chris Lattner : > > Dear staff, > I am using the ds-aa to pass mysqld. I compile mysqld 4.0.12 > statically (compile all libraries statically to the executable) and > got the bc file, named it as mysqld.bc3. > I use the command to pass: > > opt -load /lib/libLLVMDataStructure.so -ds-aa > mysqld.bc3 -print-alias-sets -disable-output > > However, I got a lot of "cast in ... " on output screen like this: > > cast in strxnmov > %13 = inttoptr i32 %10 to i8* ; [#uses=1] > > In addition, and pass can not stop for a long time, and the last > output is the "cast in ... " as above. > > Thanks, > Heming > > >> >> On May 13, 2009, at 7:22 AM, Stripf, Timo wrote: >> >>> Hi all, >>> >>> i?m working atm on a backend for a processor architecture that is >>> capable of storing the carry flag of ADDC in an 1-bit register >>> class. So I tried to lower the ADDC instruction to generate two >>> register values as result. On the tablegen description of the >>> instruction i came across the tablegen restriction that only one >>> output result of one instruction is possible: >>> >>> assert(NumResults <= 1 && >>> "We only work with nodes with zero or one result so far!"); >>> >>> So my question is now how much work it would be to remove this >>> restriction in tablegen. What do I have to take into consideration? >>> >> >> I don't know offhand, but this would be a very welcome improvement! >> >> -Chris > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- A non-text attachment was scrubbed... Name: mysqld.bc3.tar.gz Type: application/x-gzip-compressed Size: 2797817 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090513/a702fae3/attachment-0001.bin From npjohnso at cs.princeton.edu Wed May 13 19:29:13 2009 From: npjohnso at cs.princeton.edu (Nick Johnson) Date: Wed, 13 May 2009 20:29:13 -0400 Subject: [LLVMdev] Chaining analyses from an analysis group Message-ID: Hello, Two questions regarding analysis groups that ``chain'' their results, like AliasAnalysis. (1) I have an analysis group, let's call it Provider. I also have two implementations of it: ProviderA and ProviderB. The "writing a pass" document suggests using: au.addRequiredTransitive< Provider >(); Within the getAnalysisUsage() method of both ProviderA and ProviderB. But... I'm doing something wrong, and I get an infinite recursion. (2) ALSO, I'm confused. Should I get the previous results using: Provider &previous = getAnalysis< Provider >(); But that returns a reference, so how could the last pass in the chain call it if it doesn't exist? Or, am I supposed to implement a terminal pass, similar to NoAA? -- Nick Johnson From holm at liacs.nl Thu May 14 05:25:07 2009 From: holm at liacs.nl (Mattias Holm) Date: Thu, 14 May 2009 12:25:07 +0200 Subject: [LLVMdev] Fusing GEPIs Message-ID: Hi, Is there any standard pass or something that can fuse chained GEPIs? I.e. turning b = getelementptr a, 10, 1 c = getelementptr b, 0, 3 d = getelementptr c, 0, 5 into: d = getelementptr a, 10, 1, 3, 5 In our case this would greatly simplify some analysis passes, at the moment we have to trace back a gepi-chain and extract all the indices manually (the original object is available through the getUnderlyingObject method, so that doesn't pose any problems). Kind regards, Mattias From baldrick at free.fr Thu May 14 06:11:33 2009 From: baldrick at free.fr (Duncan Sands) Date: Thu, 14 May 2009 13:11:33 +0200 Subject: [LLVMdev] Fusing GEPIs In-Reply-To: References: Message-ID: <200905141311.34137.baldrick@free.fr> > Is there any standard pass or something that can fuse chained GEPIs? > > I.e. turning > b = getelementptr a, 10, 1 > c = getelementptr b, 0, 3 > d = getelementptr c, 0, 5 > into: > d = getelementptr a, 10, 1, 3, 5 I think instcombine does this. Ciao, Duncan. From jay.foad at gmail.com Thu May 14 06:56:56 2009 From: jay.foad at gmail.com (Jay Foad) Date: Thu, 14 May 2009 12:56:56 +0100 Subject: [LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray) Message-ID: 2009/4/1 Chris Lattner : > As far API design goes, we're in a mixed state. ?I'd strongly prefer > to get rid of std::vector from the various interfaces, f.e. creating a > constant array currently requires passing in an std::vector. ?For > these sorts of interfaces, we should migrate to passing in a "Constant > *const* / unsigned" pair. ?This allows use with a C array, a > SmallVector, std::vector, or any other container with sequential > storage. I've made a start on this for the constructors of StructType and FunctionType. I've attached the patch so far, which is just enough to build lib/VMCore/. Before I continue with it: 1. Is this still the way you want to go? 2. Do you care about breaking out-of-tree code that creates struct or function types? I'm happy to convert cfe and llvm-gcc myself. 3. Are there any logistical problems with committing a wide-reaching patch like this? 3. Any comments on the patch itself? Thanks, Jay. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.novector Type: application/octet-stream Size: 11186 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090514/1716a3d2/attachment.obj From dberlin at dberlin.org Thu May 14 09:20:07 2009 From: dberlin at dberlin.org (Daniel Berlin) Date: Thu, 14 May 2009 10:20:07 -0400 Subject: [LLVMdev] Slightly OT: LLVM in NVidia OpenCL In-Reply-To: <43196.146.50.22.50.1242210904.squirrel@www.assumetheposition.nl> References: <43196.146.50.22.50.1242210904.squirrel@www.assumetheposition.nl> Message-ID: <4aca3dc20905140720k2d612b15nca5acf405b5f03f6@mail.gmail.com> On Wed, May 13, 2009 at 6:35 AM, Paul Melis wrote: > Well well, LLVM seems to be everywhere these days :) > > >From the OpenCL SDK release notes: > > ?NOTICE: Portions of the NVIDIA system software contain components licensed > ?from third parties under the following terms: > > ? ?Clang & LLVM: > ? ?Copyright (c) 2003-2008 University of Illinois at Urbana-Champaign. > ? ?All rights reserved. > > ? ?Portions of LLVM's System library: > ? ?Copyright (C) 2004 eXtensible Systems, Inc. > > ? ?Developed by: > > ? ? ? ?LLVM Team > > ? ? ? ?University of Illinois at Urbana-Champaign > > ? ? ? ?http://llvm.org > Is it really missing the list of terms and conditions? If so, that would be sad ;) From llvm at assumetheposition.nl Thu May 14 11:21:00 2009 From: llvm at assumetheposition.nl (Paul Melis) Date: Thu, 14 May 2009 18:21:00 +0200 Subject: [LLVMdev] Slightly OT: LLVM in NVidia OpenCL In-Reply-To: <4aca3dc20905140720k2d612b15nca5acf405b5f03f6@mail.gmail.com> References: <43196.146.50.22.50.1242210904.squirrel@www.assumetheposition.nl> <4aca3dc20905140720k2d612b15nca5acf405b5f03f6@mail.gmail.com> Message-ID: <4A0C44EC.1000201@assumetheposition.nl> Daniel Berlin wrote: > On Wed, May 13, 2009 at 6:35 AM, Paul Melis wrote: > >> Well well, LLVM seems to be everywhere these days :) >> >> >From the OpenCL SDK release notes: >> >> NOTICE: Portions of the NVIDIA system software contain components licensed >> from third parties under the following terms: >> > > >> Clang & LLVM: >> Copyright (c) 2003-2008 University of Illinois at Urbana-Champaign. >> All rights reserved. >> >> Portions of LLVM's System library: >> Copyright (C) 2004 eXtensible Systems, Inc. >> >> Developed by: >> >> LLVM Team >> >> University of Illinois at Urbana-Champaign >> >> http://llvm.org >> >> > > Is it really missing the list of terms and conditions? > If so, that would be sad ;) > Nope, I didn't copy-paste all of it, as usually people are not interested in that stuff ;-) Paul From dalej at apple.com Thu May 14 11:48:57 2009 From: dalej at apple.com (Dale Johannesen) Date: Thu, 14 May 2009 09:48:57 -0700 Subject: [LLVMdev] Compiler error: LoopStrengthReduce.cpp In-Reply-To: <3f49a9f40905122259m21263486qb8410c12bcbb0857@mail.gmail.com> References: <3f49a9f40905121509s7b619c18tf1e426017b8d19cb@mail.gmail.com> <5152210A-A3E8-4933-AB68-510026474899@apple.com> <3f49a9f40905121701k139cc4c7q168e9305ef82b530@mail.gmail.com> <30F4A73D-119C-4562-BA6C-4C062C80AB88@apple.com> <3f49a9f40905122259m21263486qb8410c12bcbb0857@mail.gmail.com> Message-ID: On May 12, 2009, at 10:59 PMPDT, OvermindDL1 wrote: >>>>> The error given: >>>>> >>>>> ..\..\..\..\trunk\lib\Transforms\Scalar >>>>> \LoopStrengthReduce.cpp(1016) : >>>>> error C2668: 'abs' : ambiguous call to overloaded function >>>>> >> I checked in a fix. > > Also, IndVarSimplify.cpp has the same problem, only one abs usage in > it, line 700: > if (Max.getZExtValue() > static_cast(abs(intEV - intIV))) > Following your style change: > if (Max.getZExtValue() > static_cast(abs64(intEV - intIV))) Fixed, thanks. > Also, why make an abs64, why not just override abs with 64 bit > parameters? Because I think overloading standard functions is evil. ymmv. From clattner at apple.com Thu May 14 12:08:41 2009 From: clattner at apple.com (Chris Lattner) Date: Thu, 14 May 2009 10:08:41 -0700 Subject: [LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray) In-Reply-To: References: Message-ID: On May 14, 2009, at 4:56 AM, Jay Foad wrote: > 2009/4/1 Chris Lattner : >> As far API design goes, we're in a mixed state. I'd strongly prefer >> to get rid of std::vector from the various interfaces, f.e. >> creating a >> constant array currently requires passing in an std::vector. For >> these sorts of interfaces, we should migrate to passing in a >> "Constant >> *const* / unsigned" pair. This allows use with a C array, a >> SmallVector, std::vector, or any other container with sequential >> storage. > > I've made a start on this for the constructors of StructType and > FunctionType. I've attached the patch so far, which is just enough to > build lib/VMCore/. Before I continue with it: Great! > 1. Is this still the way you want to go? Yes > 2. Do you care about breaking out-of-tree code that creates struct or > function types? I'm happy to convert cfe and llvm-gcc myself. Nope, we expect people with out of tree code to update themselves. > 3. Are there any logistical problems with committing a wide-reaching > patch like this? I don't think so. > 3. Any comments on the patch itself? The one major thing to be aware of is that it isn't safe to use &V[0] when V is an empty std::vector (though it is safe for smallvector). When converting code, just be careful so that this doesn't break {} or void(). One minor thing is that StructType::get(NULL, 0) looks somewhat strange to me. How about adding a zero-argument version of "get" that returns the empty struct? That would allow code to use StructType::get(). Thanks for working on this Jay! -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090514/e0b51d25/attachment.html From gohman at apple.com Thu May 14 12:39:16 2009 From: gohman at apple.com (Dan Gohman) Date: Thu, 14 May 2009 10:39:16 -0700 Subject: [LLVMdev] Fusing GEPIs In-Reply-To: References: Message-ID: An alternative to manually analyzing GEPs is to use the ScalarEvolution pass. In TOT, ScalarEvolution will automatically analyze chains of GEPs and other things, and present them in a normalized form. One of the intentions of this is to support clients that want to understand memory access patterns. Given a LoadInst or StoreInst, ask ScalarEvolution for the SCEV expression for the address operand. Among other things, that indicates which loops affect the address' value and what the strides are from each loop. Dan On May 14, 2009, at 3:25 AM, Mattias Holm wrote: > Hi, > > Is there any standard pass or something that can fuse chained GEPIs? > > I.e. turning > b = getelementptr a, 10, 1 > c = getelementptr b, 0, 3 > d = getelementptr c, 0, 5 > into: > d = getelementptr a, 10, 1, 3, 5 > > In our case this would greatly simplify some analysis passes, at the > moment we have to trace back a gepi-chain and extract all the indices > manually (the original object is available through the > getUnderlyingObject method, so that doesn't pose any problems). > > > Kind regards, > Mattias > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From omineo at gmail.com Thu May 14 13:12:11 2009 From: omineo at gmail.com (Mark A. Lyan) Date: Thu, 14 May 2009 11:12:11 -0700 Subject: [LLVMdev] LLVM and use-after-free In-Reply-To: <16e5fdf90905121747sbb86884nef60250ae1135292@mail.gmail.com> References: <82665d1e0905121703p456a1e89pb8a56534f5ba667d@mail.gmail.com> <16e5fdf90905121747sbb86884nef60250ae1135292@mail.gmail.com> Message-ID: <82665d1e0905141112s6cab0947u38bdaa455aa8c961@mail.gmail.com> On Tue, May 12, 2009 at 5:47 PM, Bill Wendling wrote: > On Tue, May 12, 2009 at 5:03 PM, Mark A. Lyan wrote: > > Gurus- > > > > Do llvm-gcc or clang provide a way to catch use-after-free types of > issues? > > > llvm-gcc and clang don't. But I believe that the static analyzer has > facilities for this. > > http://clang.llvm.org/StaticAnalysis.html Ah! I will investigate this further. Thanks for the help. -KC > > -bw > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090514/f3491b45/attachment.html From mjr at cs.wisc.edu Thu May 14 13:47:05 2009 From: mjr at cs.wisc.edu (Matt Renzelmann) Date: Thu, 14 May 2009 13:47:05 -0500 Subject: [LLVMdev] Grouping related functions in a code section In-Reply-To: References: <001901c9d25a$3af40510$b0dc0f30$@wisc.edu> <001a01c9d261$1d8fe500$58afaf00$@wisc.edu> <002301c9d26a$338c2a40$9aa47ec0$@wisc.edu> <002a01c9d26e$4064e780$c12eb680$@wisc.edu> Message-ID: <005801c9d4c4$63d0da00$2b728e00$@wisc.edu> Andrew, Eli, thank you both for your help. You both proposed essentially the same idea at the same time and it works fine. I appreciate your assistance thus far. I'd set this aside for a few days to work on another thing, but am back now and have another question. User mode Linux contains a "__syscall_stub" code section. The linker script defines it to be page-aligned, and it contains several function definitions--not just pointers to functions, but the code itself. User mode Linux then memory maps this page into the address spaces of new processes. User mode Linux first calls "clone" to fork a new process, and then uses "mmap64" to map this page in. One purpose of this page of code is that it contains a SIGSEGV handler. The newly forked process promptly installs this signal handler, and uses a function stored in this code. Here's an outline of the whole process: // In the newly-cloned process, map in the magic page // __syscall_stub_start defined in linker script fd = phys_mapping(to_phys(&__syscall_stub_start), &offset); // Get executable permission: addr = mmap64((void *) STUB_CODE, UM_KERN_PAGE_SIZE, PROT_EXEC, MAP_FIXED | MAP_PRIVATE, fd, offset); The previous code maps the page of code into memory: the page address is stored in the linker-script-defined __syscall_stub_start symbol. Then we have: unsigned long v = STUB_CODE + (unsigned long) stub_segv_handler - // a function stored in this page (unsigned long) &__syscall_stub_start; // from linker script set_sigstack((void *) STUB_DATA, UM_KERN_PAGE_SIZE); sigemptyset(&sa.sa_mask); sa.sa_flags = SA_ONSTACK | SA_NODEFER; sa.sa_handler = (void *) v; // Use this function. The stub_segv_handler function is defined with: void __attribute__ ((__section__ (".__syscall_stub"))) stub_segv_handler(int sig) {...} I don't actually quite understand the reason all these gyrations are necessary and why it can't just use the signal handler function directly--since it should have been cloned too--but I presume there is a reason or it wouldn't be done this way. Is there a clean way to deal with this problem in LLVM? Again, using LD itself is straightforward because a linker script allows you to group these functions together into a single page--is some equivalent possible in LLVM? Thanks and regards, Matt From weihua.sheng at gmail.com Thu May 14 16:19:21 2009 From: weihua.sheng at gmail.com (Weihua Sheng) Date: Thu, 14 May 2009 23:19:21 +0200 Subject: [LLVMdev] alias analysis results Message-ID: <274670e50905141419h10ba95a5x7c7c6f83d4ace633@mail.gmail.com> Hi there, I am trying to understand how AliasAnalysis works out in LLVM. I used the following simple test-case (test4.c): -- void test() { int *jj, *kk; int aa = 100; jj = &aa; *jj = 300; } int main() { test(); return 0; } -- Then I did "llvm-gcc -emit-llvm -c -o test4.bc test4.c" to get bc. I tried the following 2 ways to get what I expect to get as "alias-sets": 1. opt -aa-eval -print-all-alias-modref-info test4.bc Function: test: 4 pointers, 0 call sites NoAlias: i32* %aa, i32** %kk NoAlias: i32* %aa, i32** %jj NoAlias: i32** %jj, i32** %kk MayAlias: i32* %0, i32* %aa MayAlias: i32* %0, i32** %kk MayAlias: i32* %0, i32** %jj Function: main: 2 pointers, 1 call sites NoAlias: i32* %0, i32* %retval NoModRef: Ptr: i32* %retval <-> call void @test() nounwind NoModRef: Ptr: i32* %0 <-> call void @test() nounwind This way at least I could see " aa <- (kk, jj)" results from mayalias. 2. opt -anders-aa -aa-eval -print-all-alias-modref-info test4.bc Function: test: 4 pointers, 0 call sites NoAlias: i32* %aa, i32** %kk NoAlias: i32* %aa, i32** %jj NoAlias: i32** %jj, i32** %kk MayAlias: i32* %0, i32* %aa NoAlias: i32* %0, i32** %kk NoAlias: i32* %0, i32** %jj Function: main: 2 pointers, 1 call sites NoAlias: i32* %0, i32* %retval NoModRef: Ptr: i32* %retval <-> call void @test() nounwind NoModRef: Ptr: i32* %0 <-> call void @test() nounwind I actullay would expect the more accurate results from applying anders-aa, but I could not interpret what has been returned - at least I should see something like jj->aa, right? Maybe I missed something out, could someone on the mailing list share some thoughts? Thanks a lot! Weihua From eli.friedman at gmail.com Thu May 14 18:33:57 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 14 May 2009 16:33:57 -0700 Subject: [LLVMdev] alias analysis results In-Reply-To: <274670e50905141419h10ba95a5x7c7c6f83d4ace633@mail.gmail.com> References: <274670e50905141419h10ba95a5x7c7c6f83d4ace633@mail.gmail.com> Message-ID: On Thu, May 14, 2009 at 2:19 PM, Weihua Sheng wrote: > I actullay would expect the more accurate results from applying > anders-aa, but I could not interpret what has been returned - at least > I should see something like jj->aa, right? I'm not quite following... jj and aa don't alias; both versions show that. The results returned for anders-aa are completely precise except that it doesn't know that "%0" and "%aa" must point to exactly the same object. -Eli From hc2428 at columbia.edu Thu May 14 20:36:06 2009 From: hc2428 at columbia.edu (hc2428 at columbia.edu) Date: Thu, 14 May 2009 21:36:06 -0400 Subject: [LLVMdev] DataStructure Analysis ds-aa can not stop when passing mysqld In-Reply-To: <20090513143917.84b0n83qhcsc8sco@cubmail.cc.columbia.edu> References: <041DD5ACCD9F824BB2273B9421CA13D2FCF485@RZ-EX-06.rz.uni-karlsruhe.de> <0B94D2F6-D5C2-4F39-BA2F-BA9A81DCB982@apple.com> <20090513143632.pq8gvq8ksok8oo48@cubmail.cc.columbia.edu> <20090513143917.84b0n83qhcsc8sco@cubmail.cc.columbia.edu> Message-ID: <20090514213606.bk1i91qom8gs80kg@cubmail.cc.columbia.edu> Quoting hc2428 at columbia.edu: Dear staff, I try to use anders-aa to pass the mysqld.bc3 in my previous email, but it does not work. Command: opt -anders-aa mysqld.bc3 -disable-output Output: Unknown instruction: %mrv4 = insertvalue %struct.ACL_ACCESS undef, i64 %mrv, 0 ; <%struct.ACL_ACCESS> [#uses=1] opt[0x9e886c] opt[0x9e898e] /lib/libc.so.6[0x7fb96ab8b100] /lib/libc.so.6(gsignal+0x35)[0x7fb96ab8b095] /lib/libc.so.6(abort+0x110)[0x7fb96ab8caf0] opt[0x875c8a] opt[0x876149] opt[0x876169] opt[0x87a331] opt[0x87a38f] opt[0x87a3e4] opt[0x87a429] opt[0x87a47e] opt[0x87a4a3] opt[0x87a8c8] opt[0x87ab50] opt(_ZN4llvm13MPPassManager11runOnModuleERNS_6ModuleE+0xba)[0x977982] opt(_ZN4llvm15PassManagerImpl3runERNS_6ModuleE+0x74)[0x979296] opt(_ZN4llvm11PassManager3runERNS_6ModuleE+0x21)[0x9792f9] opt(main+0xf7e)[0x6c4ae6] /lib/libc.so.6(__libc_start_main+0xf4)[0x7fb96ab771c4] opt(cos+0x119)[0x6b5089] Aborted > Quoting hc2428 at columbia.edu: > > Dear staff, > Here is the bc file. > > Heming > >> Quoting Chris Lattner : >> >> Dear staff, >> I am using the ds-aa to pass mysqld. I compile mysqld 4.0.12 >> statically (compile all libraries statically to the executable) and >> got the bc file, named it as mysqld.bc3. >> I use the command to pass: >> >> opt -load /lib/libLLVMDataStructure.so -ds-aa >> mysqld.bc3 -print-alias-sets -disable-output >> >> However, I got a lot of "cast in ... " on output screen like this: >> >> cast in strxnmov >> %13 = inttoptr i32 %10 to i8* ; [#uses=1] >> >> In addition, and pass can not stop for a long time, and the last >> output is the "cast in ... " as above. >> >> Thanks, >> Heming >> >> >>> >>> On May 13, 2009, at 7:22 AM, Stripf, Timo wrote: >>> >>>> Hi all, >>>> >>>> i?m working atm on a backend for a processor architecture that is >>>> capable of storing the carry flag of ADDC in an 1-bit register >>>> class. So I tried to lower the ADDC instruction to generate two >>>> register values as result. On the tablegen description of the >>>> instruction i came across the tablegen restriction that only one >>>> output result of one instruction is possible: >>>> >>>> assert(NumResults <= 1 && >>>> "We only work with nodes with zero or one result so far!"); >>>> >>>> So my question is now how much work it would be to remove this >>>> restriction in tablegen. What do I have to take into consideration? >>>> >>> >>> I don't know offhand, but this would be a very welcome improvement! >>> >>> -Chris >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> From overminddl1 at gmail.com Thu May 14 21:11:11 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Thu, 14 May 2009 20:11:11 -0600 Subject: [LLVMdev] Compiler error: LoopStrengthReduce.cpp In-Reply-To: References: <3f49a9f40905121509s7b619c18tf1e426017b8d19cb@mail.gmail.com> <5152210A-A3E8-4933-AB68-510026474899@apple.com> <3f49a9f40905121701k139cc4c7q168e9305ef82b530@mail.gmail.com> <30F4A73D-119C-4562-BA6C-4C062C80AB88@apple.com> <3f49a9f40905122259m21263486qb8410c12bcbb0857@mail.gmail.com> Message-ID: <3f49a9f40905141911w53f7b129v5e3611e368a0b286@mail.gmail.com> On Thu, May 14, 2009 at 10:48 AM, Dale Johannesen wrote: >> Also, why make an abs64, why not just override abs with 64 bit >> parameters? > > Because I think overloading standard functions is evil. ?ymmv. And yet operators >> amd << are great examples of overriding for ostream. :) From weihua.sheng at gmail.com Fri May 15 03:50:51 2009 From: weihua.sheng at gmail.com (Weihua Sheng) Date: Fri, 15 May 2009 10:50:51 +0200 Subject: [LLVMdev] alias analysis results In-Reply-To: References: <274670e50905141419h10ba95a5x7c7c6f83d4ace633@mail.gmail.com> Message-ID: <274670e50905150150g327f6d29vb9074bfeb3443d63@mail.gmail.com> Hi Eli, thanks for the answers helping out. I tried to understand further - got another example: void test() { int *jj, *kk; int aa = 100; jj = &aa; *jj = 300; kk = jj; *kk = 400; } int main() { test(); return 0; } bc looks like the following (only test() part) define void @test() nounwind { entry: %aa = alloca i32 ; [#uses=2] %kk = alloca i32* ; [#uses=2] %jj = alloca i32* ; [#uses=3] %"alloca point" = bitcast i32 0 to i32 ; [#uses=0] store i32 100, i32* %aa, align 4 store i32* %aa, i32** %jj, align 8 %0 = load i32** %jj, align 8 ; [#uses=1] store i32 300, i32* %0, align 4 %1 = load i32** %jj, align 8 ; [#uses=1] store i32* %1, i32** %kk, align 8 %2 = load i32** %kk, align 8 ; [#uses=1] store i32 400, i32* %2, align 4 br label %return return: ; preds = %entry ret void } the andersens-aa gives out the following results: Function: test: 6 pointers, 0 call sites NoAlias: i32* %aa, i32** %kk NoAlias: i32* %aa, i32** %jj NoAlias: i32** %jj, i32** %kk MayAlias: i32* %0, i32* %aa NoAlias: i32* %0, i32** %kk NoAlias: i32* %0, i32** %jj MayAlias: i32* %1, i32* %aa NoAlias: i32* %1, i32** %kk NoAlias: i32* %1, i32** %jj MayAlias: i32* %0, i32* %1 MayAlias: i32* %2, i32* %aa NoAlias: i32* %2, i32** %kk NoAlias: i32* %2, i32** %jj MayAlias: i32* %0, i32* %2 MayAlias: i32* %1, i32* %2 which I interpret as (%0, %1, %aa, %2) as the alias set. Here comes my beginner's question: will the AA give the result that kk and jj alias (that's what I understand from C and possibly could see from bc)? Thanks a lot again! Weihua On Fri, May 15, 2009 at 1:33 AM, Eli Friedman wrote: > On Thu, May 14, 2009 at 2:19 PM, Weihua Sheng wrote: >> I actullay would expect the more accurate results from applying >> anders-aa, but I could not interpret what has been returned - at least >> I should see something like jj->aa, right? > > I'm not quite following... jj and aa don't alias; both versions show > that. ?The results returned for anders-aa are completely precise > except that it doesn't know that "%0" and "%aa" must point to exactly > the same object. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From andreas.bolka at gmx.net Fri May 15 04:36:55 2009 From: andreas.bolka at gmx.net (Andreas Bolka) Date: Fri, 15 May 2009 11:36:55 +0200 Subject: [LLVMdev] Loop-carried Dependence In-Reply-To: <2015205e0905130730j233c8535o5b0cfe03ed844f00@mail.gmail.com> References: <2015205e0905130730j233c8535o5b0cfe03ed844f00@mail.gmail.com> Message-ID: <1242380207-sup-1623@strider> Hi Wenhao Jia, On Wed May 13 16:30:36 +0200 2009, Wenhao Jia wrote: > Does anyone know if there is any existing code I can use to do a > loop-carried dependence analysis for LLVM IR programs? I searched the > mailing-list archive and it seems like someone planned to implement a > loop dependence analysis pass in March. I'm just wondering if this > project is ongoing/finished or if there is other projects that may > have the code I'm interested in. Starting next week, I'll be working on a loop-dependence analysis pass. So nothing is done yet (except a few first scratch attempts), but I guess you can expect something by mid/end of June. What kind of results would you require? Plain dependence results, direction vectors, distance vectors? -- Regards, Andreas From eli.friedman at gmail.com Fri May 15 05:09:51 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 15 May 2009 03:09:51 -0700 Subject: [LLVMdev] alias analysis results In-Reply-To: <274670e50905150150g327f6d29vb9074bfeb3443d63@mail.gmail.com> References: <274670e50905141419h10ba95a5x7c7c6f83d4ace633@mail.gmail.com> <274670e50905150150g327f6d29vb9074bfeb3443d63@mail.gmail.com> Message-ID: On Fri, May 15, 2009 at 1:50 AM, Weihua Sheng wrote: > the andersens-aa gives out the following results: > Function: test: 6 pointers, 0 call sites > ?NoAlias: ? ? ?i32* %aa, i32** %kk > ?NoAlias: ? ? ?i32* %aa, i32** %jj > ?NoAlias: ? ? ?i32** %jj, i32** %kk [snip] > which I interpret as (%0, %1, %aa, %2) as the alias set. ?Here comes > my beginner's question: will the AA give the result that kk and jj > alias (that's what I understand from C and possibly could see from > bc)? Thanks a lot again! "%jj" and "%kk" don't alias... that's trivial, though, because they're the addresses of distinct stack allocations. If you're talking about the values loaded from those variables, they are "%0", "%1", and "%2", and the returned result is that they "MayAlias". A more precise analysis could return "MustAlias". -Eli From jay.foad at gmail.com Fri May 15 05:50:04 2009 From: jay.foad at gmail.com (Jay Foad) Date: Fri, 15 May 2009 11:50:04 +0100 Subject: [LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray) In-Reply-To: References: Message-ID: > 3. Any comments on the patch itself? > > The one major thing to be aware of is that it isn't safe to use &V[0] when V > is an empty std::vector Oh dear. That's a bit of a flaw in the plan. I suppose the solution is to switch to SmallVector whenever this might be a problem. I'm a bit concerned that any new &empty[0] problems that are introduced will go unnoticed. With GNU libstdc++ they aren't diagnosed unless you build with -D_GLIBCXX_DEBUG (or ENABLE_EXPENSIVE_CHECKS=1). For now I'm testing with ENABLE_EXPENSIVE_CHECKS=1, and it is indeed catching lots of errors! > (though it is safe for smallvector). DR 464 proposes a new data() method. I'd suggest implementing that in SmallVector, instead of relying on the relaxed checking in operator[](). http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464 GNU libstdc++'s vector already has this data() method, but I suppose we can't rely on in it being in std::vector in general. > One minor thing is that?StructType::get(NULL, 0)?looks somewhat strange to > me. ?How about adding a zero-argument version of "get" that returns the > empty struct? ?That would allow code to use?StructType::get(). OK, I've done this for both StructType and FunctionType. I'll post some patches on llvm-commits. Thanks, Jay. From tynarex at gmail.com Fri May 15 08:14:01 2009 From: tynarex at gmail.com (Wenhao Jia) Date: Fri, 15 May 2009 09:14:01 -0400 Subject: [LLVMdev] Loop-carried Dependence In-Reply-To: <1242380207-sup-1623@strider> References: <2015205e0905130730j233c8535o5b0cfe03ed844f00@mail.gmail.com> <1242380207-sup-1623@strider> Message-ID: <2015205e0905150614t7cc7ec5v10e599418967db12@mail.gmail.com> Hi Andreas, For the purpose of my project, as a first step I just need to tell if loop-carried dependence exists or not within a certain loop. So I guess what you mentioned may be too advanced for me at this stage. But I'll be looking forward to your results as my project progresses and as I need more information about loop dependence. Thanks! Wenhao On Fri, May 15, 2009 at 5:36 AM, Andreas Bolka wrote: > Hi Wenhao Jia, > > On Wed May 13 16:30:36 +0200 2009, Wenhao Jia wrote: >> Does anyone know if there is any existing code I can use to do a >> loop-carried dependence analysis for LLVM IR programs? I searched the >> mailing-list archive and it seems like someone planned to implement a >> loop dependence analysis pass in March. I'm just wondering if this >> project is ongoing/finished or if there is other projects that may >> have the code I'm interested in. > > Starting next week, I'll be working on a loop-dependence analysis pass. > So nothing is done yet (except a few first scratch attempts), but I > guess you can expect something by mid/end of June. > > What kind of results would you require? Plain dependence results, > direction vectors, distance vectors? > > -- > Regards, > Andreas > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From aaronngray.lists at googlemail.com Fri May 15 08:25:03 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Fri, 15 May 2009 14:25:03 +0100 Subject: [LLVMdev] IS anyone sucessfully sing the MachO backend Message-ID: <030DC89E19BD40F2ABAB7E396330BBEC@HPLAPTOP> Hi, I am working on the direct object module emission, and am wondering if anyone is successfully using the MachO backend. Thanks, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090515/b8b96813/attachment.html From dag at cray.com Fri May 15 09:26:07 2009 From: dag at cray.com (David Greene) Date: Fri, 15 May 2009 09:26:07 -0500 Subject: [LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray) In-Reply-To: References: Message-ID: <200905150926.08766.dag@cray.com> On Friday 15 May 2009 05:50, Jay Foad wrote: > > 3. Any comments on the patch itself? > > > > The one major thing to be aware of is that it isn't safe to use &V[0] > > when V is an empty std::vector > > Oh dear. That's a bit of a flaw in the plan. I suppose the solution is > to switch to SmallVector whenever this might be a problem. Or use iterators. That's why they're there. > For now I'm testing with ENABLE_EXPENSIVE_CHECKS=1, and it is indeed > catching lots of errors! Mm hmm. :) -Dave From jay.foad at gmail.com Fri May 15 09:40:55 2009 From: jay.foad at gmail.com (Jay Foad) Date: Fri, 15 May 2009 15:40:55 +0100 Subject: [LLVMdev] "Processed value not in any map!" failures Message-ID: When I build LLVM with ENABLE_EXPENSIVE_CHECKS=1, make check fails: Running /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/dg.exp ... FAIL: /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/2007-05-14-InlineAsmCstCrash.ll Failed with signal(SIGABRT) at line 1 while running: llvm-as < /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/2007-05-14-InlineAsmCstCrash.ll | llc -march=arm -mattr=+v6 Processed value not in any map! 0 llc 0x09222aa7 1 llc 0x09223146 2 0x4001c400 __kernel_sigreturn + 0 3 libc.so.6 0x4019d018 abort + 392 4 llc 0x08d832ff 5 llc 0x08d83598 6 llc 0x08d84197 llvm::SelectionDAG::LegalizeTypes() + 45 7 llc 0x08d0e8db llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1261 8 llc 0x08d11218 llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*, llvm::ilist_iterator, llvm::ilist_iterator) + 456 9 llc 0x08d11cca llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function&, llvm::MachineFunction&, llvm::MachineModuleInfo*, llvm::DwarfWriter*, llvm::TargetInstrInfo const&) + 2460 10 llc 0x08d12aa7 llvm::SelectionDAGISel::runOnFunction(llvm::Function&) + 905 11 llc 0x0916be36 llvm::FPPassManager::runOnFunction(llvm::Function&) + 288 12 llc 0x0916c924 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 124 13 llc 0x0916caf5 llvm::FunctionPassManager::run(llvm::Function&) + 159 14 llc 0x086807a3 main + 2830 15 libc.so.6 0x40186455 __libc_start_main + 229 16 llc 0x0867e991 Stack dump: 0. Program arguments: llc -march=arm -mattr=+v6 1. Running pass 'ARM Instruction Selection' on function '@test3' ... and many more similar failures. Jay. From manoel at fonetica.com.br Fri May 15 09:58:31 2009 From: manoel at fonetica.com.br (=?ISO-8859-1?Q?Manoel=20Teixeira?=) Date: Fri, 15 May 2009 11:58:31 -0300 Subject: [LLVMdev] LLVMdev Digest, Vol 59, Issue 25 In-Reply-To: References: Message-ID: <20090515145831.19870.qmail@hm885.locaweb.com.br> I'm trying to use exception control by LLVM. In the demo page, I got : declare i8* @llvm.eh.exception() nounwind But, when a try to emit the code by llvm engine, the name is generate with the sufix .132 ( llvm.eh.exception.132 ) and the Function::getIntrinsicID abort the program. Could some one help me? Manoel Teixeira From jay.foad at gmail.com Fri May 15 10:07:39 2009 From: jay.foad at gmail.com (Jay Foad) Date: Fri, 15 May 2009 16:07:39 +0100 Subject: [LLVMdev] "Processed value not in any map!" failures In-Reply-To: References: Message-ID: > FAIL: /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/2007-05-14-InlineAsmCstCrash.ll > Failed with signal(SIGABRT) at line 1 > while running: ?llvm-as < > /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/2007-05-14-InlineAsmCstCrash.ll > | ?llc -march=arm -mattr=+v6 > Processed value not in any map! If it helps, at this point I->dump() gives: 0xa21e504: i64 = TargetConstant <1> Thanks, Jay. From manoel at fonetica.com.br Fri May 15 11:50:13 2009 From: manoel at fonetica.com.br (=?ISO-8859-1?Q?Manoel=20Teixeira?=) Date: Fri, 15 May 2009 13:50:13 -0300 Subject: [LLVMdev] Intrinsic Message-ID: <20090515165013.8595.qmail@hm885.locaweb.com.br> Hi, I'm trying to use exception control by LLVM. In the demo page, I got : declare i8* @llvm.eh.exception() nounwind But, when a try to emit the code by llvm engine, the name is generate with the sufix .132 ( llvm.eh.exception.132 ) and the Function::getIntrinsicID abort the program. It was so : Intrinsic::getDeclaration(llvm_module,Intrinsic::memset,&Tys,1); Now, it's running with this calling : return cast llvm_module->getOrInsertFunction(std::string("llvm.eh.exception"), Intrinsic::getType(Intrinsic::eh_exception, &Tys,1)) ); Is that correct? Manoel Teixeira From clattner at apple.com Fri May 15 11:58:18 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 15 May 2009 09:58:18 -0700 Subject: [LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray) In-Reply-To: References: Message-ID: <4C6895A3-10A7-4CDE-839C-9F0E272CA523@apple.com> On May 15, 2009, at 3:50 AM, Jay Foad wrote: >> 3. Any comments on the patch itself? >> >> The one major thing to be aware of is that it isn't safe to use >> &V[0] when V >> is an empty std::vector > > Oh dear. That's a bit of a flaw in the plan. I suppose the solution is > to switch to SmallVector whenever this might be a problem. As David points out, another solution is to make an inline templated iterator version like CallInst::Create has. >> (though it is safe for smallvector). > > DR 464 proposes a new data() method. I'd suggest implementing that in > SmallVector, instead of relying on the relaxed checking in > operator[](). > > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464 > > GNU libstdc++'s vector already has this data() method, but I suppose > we can't rely on in it being in std::vector in general. Sure, adding .data() to smallvector would make sense. >> One minor thing is that StructType::get(NULL, 0) looks somewhat >> strange to >> me. How about adding a zero-argument version of "get" that returns >> the >> empty struct? That would allow code to use StructType::get(). > > OK, I've done this for both StructType and FunctionType. > > I'll post some patches on llvm-commits. Cool, thanks Jay! I'll be out on vacation for the next week, but other people are plenty capable of reviewing the patches. I'll take a look at anything remaining when I return. -Chris From clattner at apple.com Fri May 15 11:59:45 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 15 May 2009 09:59:45 -0700 Subject: [LLVMdev] Intrinsic In-Reply-To: <20090515165013.8595.qmail@hm885.locaweb.com.br> References: <20090515165013.8595.qmail@hm885.locaweb.com.br> Message-ID: On May 15, 2009, at 9:50 AM, Manoel Teixeira wrote: > > Hi, > > > I'm trying to use exception control by LLVM. > In the demo page, I got : > > declare i8* @llvm.eh.exception() nounwind > > But, when a try to emit the code by llvm engine, the name is > generate with the sufix .132 > ( llvm.eh.exception.132 ) and the Function::getIntrinsicID abort > the program. > > It was so : > > Intrinsic::getDeclaration(llvm_module,Intrinsic::memset,&Tys,1); Make sure that Tys[0] is set to Type::Int32Ty. -Chris > > > Now, it's running with this calling : > > return cast llvm_module- > >getOrInsertFunction(std::string("llvm.eh.exception"), > > Intrinsic::getType(Intrinsic::eh_exception, &Tys,1)) ); > > > Is that correct? > > Manoel Teixeira > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From clattner at apple.com Fri May 15 12:00:29 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 15 May 2009 10:00:29 -0700 Subject: [LLVMdev] IS anyone sucessfully sing the MachO backend In-Reply-To: <030DC89E19BD40F2ABAB7E396330BBEC@HPLAPTOP> References: <030DC89E19BD40F2ABAB7E396330BBEC@HPLAPTOP> Message-ID: On May 15, 2009, at 6:25 AM, Aaron Gray wrote: > Hi, > > I am working on the direct object module emission, and am wondering > if anyone is successfully using the MachO backend. > Nope, it's just as broken (if not more so) than the ELF writer, don't worry about breaking it. If you wanted to #if 0 it out, that would also be fine with me. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090515/76925267/attachment.html From baldrick at free.fr Fri May 15 12:07:24 2009 From: baldrick at free.fr (Duncan Sands) Date: Fri, 15 May 2009 19:07:24 +0200 Subject: [LLVMdev] "Processed value not in any map!" failures In-Reply-To: References: Message-ID: <4A0DA14C.9060008@free.fr> Hi Jay, > When I build LLVM with ENABLE_EXPENSIVE_CHECKS=1, make check fails: > > Running /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/dg.exp ... > FAIL: /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/2007-05-14-InlineAsmCstCrash.ll > Failed with signal(SIGABRT) at line 1 > while running: llvm-as < > /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/2007-05-14-InlineAsmCstCrash.ll > | llc -march=arm -mattr=+v6 > Processed value not in any map! building with ENABLE_EXPENSIVE_CHECKS=1 turns on a bunch of extra sanity checking in LegalizeTypes. "make check" used to pass all tests with this on. I notice that the failing node is a target constant. These are a special case, and the code dealing with them was tweaked a little while ago - probably that caused this. I will take a look. Ciao, Duncan. From andrelct at dcc.ufmg.br Fri May 15 12:27:33 2009 From: andrelct at dcc.ufmg.br (Andre Tavares) Date: Fri, 15 May 2009 14:27:33 -0300 Subject: [LLVMdev] SSI in LLVM Message-ID: <4A0DA605.3020501@dcc.ufmg.br> Dear LLVM Community, I am one of the summer of coders working on LLVM this year. My project is to implement the ABCD algorithm for array bounds checking, and also a bitwidth analysis that maps variables to an approximation of its size in bits. To implement this, I will have to simulate a intermediate representation called SSI (Static Single Information) form on top of LLVM SSA representation. The SSI form has the property that each use of a variable post-dominates its definition. Also, if there are two uses of the same variable, say, u(v1) and u(v2), then, either u(v1) dominates u(v2) or vice-versa. I would like to discuss my approach with you guys, so that you can redirect me if I am going through a bad path, so I am listing some points below: 1) I want to implement a very modular design. In this way, I will have an analysis that receives the intervals produced by LiveIntervalAnalysis, plus a list of variables, and creates a new set of intervals, so that each interval designates a new virtual variable, that is visible only inside my analysis. These variables have the SSI property. In this way, it is possible to map constraints such as (a > 10) to an interval. 2) Each client gives to my analysis the variables that it wants mapped to SSI. For instance, the ABCD client passes all the variables that are used as indexes of arrays, or as array sizes. A pass to eliminate dead code passes all the variables used inside conditionals, and the pass that does bitwidth analysis passes all the variables of type int, for instance. 3) This implies that each client will have to traverse the program representation harvesting the variables of interest. My analysis will take care of simulating the SSI representation for those variables. 4) Queries can be made given an instruction index, as computed by LiveIntervalAnalysis. For instance, a typical query would be: is a > x at program point 110. 5) Keeping the intervals ordered, we can answer queries in O(ln N), where N is the maximal program index. I would like to have critics on this approach so it can be well thought before implementation to reduce reimplementation. In particular, to use this technique, my analysis must work at the MachineFunction level, as it must run after LiveIntervalAnalysis. Do I miss essential information at this level, compared to the Function level? I mean, is it possible to analysis conditionals to discover things like a > 10, or a == 10, etc? Please, feel free to ask me any clarification you may think about. I would really appreciate any comments and thoughts you guys may have. Thanks, -- Andre Tavares Master Student in Computer Science - UFMG - Brasil http://dcc.ufmg.br/~andrelct From gordonhenriksen at me.com Fri May 15 12:52:04 2009 From: gordonhenriksen at me.com (Gordon Henriksen) Date: Fri, 15 May 2009 10:52:04 -0700 Subject: [LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray) In-Reply-To: <200905150926.08766.dag@cray.com> References: <200905150926.08766.dag@cray.com> Message-ID: <18FE97EF-AA24-420A-BF92-FB650F4565C1@me.com> On 2009-05-15, at 07:26, David Greene wrote: > On Friday 15 May 2009 05:50, Jay Foad wrote: >> > >>> The one major thing to be aware of is that it isn't safe to use >>> &V[0] when V is an empty std::vector >> >> Oh dear. That's a bit of a flaw in the plan. I suppose the solution >> is to switch to SmallVector whenever this might be a problem. > > Or use iterators. That's why they're there. The reason to use the pointer-length pair in preference to iterators is that iterators make templates of everything, causing code bloat. In my code, rather than pass the separate parameters I use a range class something like this: template class range { Iter Begin, End; public: range() : Begin(), End() { } template range(T &seq) : Begin(seq.begin()), End(seq.end()) { } Iter begin() { return Begin; } Iter end() { return End; } // ... other Sequence methods ... }; And encapsulate the logic to deal with the empty sequence problem in a function: template range ptr_range(ConvertibleToRange &seq) { typename ConvertibleToRange::iterator i = seq.begin(), e = seq.end(); if (i == e) return range(); return range(&*i, &*i + (e - i)); }; So that: StructType::get(v.empty()? 0 : &v[0], v.empty()? 0 : &v[0] + v.size()); // becomes StructType::get(ptr_range(v)); Two important refinements? First, the above can be made safer so that ptr_range will reject e.g. std::list with a bit of metaprogramming: template struct is_ptr { enum { value = false }; }; template struct is_ptr { enum { value = true }; }; template struct is_contiguous_sequence { enum { value = is_ptr::value }; }; template struct is_contiguous_sequence > { enum { value = true }; }; template struct is_contiguous_sequence > { enum { value = true }; }; template struct type_if { typedef T type; } template struct type_if { /* cause substitution failure */ } // New prototype for ptr_range. template typename type_if< range, is_contiguous_sequence::value >::type ptr_range(ConvertibleRange &seq); And secondly, range can be extended to convert from arrays in addition to objects with begin()/end() methods by (1) providing a partial specialization on T* which adds a template constructor: template template range::range(T (&arr)[N]) : Begin(arr), End(arr + N) { } or by (2a) using a traits type to look up ConvertibleToRange::iterator & -::value_type template struct range_traits { typedef typename T::value_type value_type; typedef typename T::iterator iterator; // .. etc ... }; template struct range_traits { typedef T value_type; typedef T *iterator; // .. etc ... }; and by (2b) indirecting calls to seq.begin() and seq.end() through template functions: template typename range_traits::iterator beginof(T &seq) { seq.begin(); } template typename range_traits::iterator beginof(T (&seq)[N]) { return seq; } template typename range_traits::iterator endof(T &seq) { seq.begin(); } template typename range_traits::iterator endof(T (&seq)[N]) { return seq + N; } This refines StructType::get(arr, arr + sizeof(arr) / sizeof(arr[0])); to just StructType::get(arr); ? Gordon From aaronngray.lists at googlemail.com Fri May 15 13:03:05 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Fri, 15 May 2009 19:03:05 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN Message-ID: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com> I am getting a bug building Cygwin on latest SVN :- llvm[1]: Compiling Process.cpp for Debug build In file included from /home/ang/git/workbench/lib/System/Process.cpp:29: /home/ang/git/workbench/lib/System/Unix/Process.inc: In function 'unsigned int g etColumns(int)': /home/ang/git/workbench/lib/System/Unix/Process.inc:209: error: aggregate 'winsi ze ws' has incomplete type and cannot be defined /home/ang/git/workbench/lib/System/Unix/Process.inc:210: error: 'TIOCGWINSZ' was not declared in this scope make[1]: *** [/home/ang/build/workbench/lib/System/Debug/Process.o] Error 1 make[1]: Leaving directory `/home/ang/build/workbench/lib/System' make: *** [all] Error 1 Having IOCTL.H does not seem to be a strict enough test for struct winsize'es presence. #ifdef HAVE_SYS_IOCTL_H // Try to determine the width of the terminal. struct winsize ws; if (ioctl(FileID, TIOCGWINSZ, &ws) == 0) Columns = ws.ws_col; #endif I could not see any changes in Process.cpp's SVN that could have caused this. Anyone got a clue ? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090515/91967465/attachment.html From dag at cray.com Fri May 15 13:09:15 2009 From: dag at cray.com (David Greene) Date: Fri, 15 May 2009 13:09:15 -0500 Subject: [LLVMdev] RFC: More AVX Experience Message-ID: <200905151309.16211.dag@cray.com> Ok, so I've been chugging away at AVX and added some new features in TableGen to facilitate writing generic patterns. Here's an example: //===----------------------------------------------------------------------===// // Dummy defs for writing generic patterns //===----------------------------------------------------------------------===// def SRCREGCLASS; def DSTREGCLASS; def MEMCLASS; def SRC1CLASS; def SRC2CLASS; def ADDRCLASS; def INTRINSIC; def TYPE; def INTTYPE; def MEMOP; // TYPE - The data type (f32 for SS, f64 for SD, etc.) // SRCREGCLASS - The source register class (VR128, FR32, etc.) // DSTREGCLASS - The destination register class // MEMCLASS - The memory classe (f32mem, f64mem, etc.) // SRC1CLASS - The first source object class (register or memory, depending) // SRC2CLASS - The second source object class (register or memory, depending) // DSTCLASS - The destination object class (register or memory, depending) // ADDRCLASS - Either 'addr' or REGCLASS, depending // MEMOP - Either 'memop' or 'srcvalue,' depending // Scalar defm FsANDN : sse1_sse2_avx_binary_scalar_xs_xd_node_pattern_rm_rrm< 0x55, "andn", [[(set DSTREGCLASS:$dst, (INTTYPE (and (not (INTTYPE (bitconvert (TYPE SRCREGCLASS:$src1)))), (INTTYPE (MEMOP ADDRCLASS:$src2)))))]]>; // Vector defm ANDN : sse1_sse2_avx_binary_vector_tb_ostb_node_pattern_rm_rrm< 0x55, "andn", [[(set DSTREGCLASS:$dst, (INTTYPE (and (vnot (INTTYPE (bitconvert (TYPE SRCREGCLASS:$src1)))), (INTTYPE (MEMOP ADDRCLASS:$src2)))))]]>; The "not" vs. "vnot" is unfortunate. I could add another class argument that says "instantiate with members of this list of operators" but see below about arguments and the combinatorial explosion problem. That and the fact that we have no "foreach for subclass specification" makes this difficult to do. (Thinking about this some more, a "cross product" operator [list x list] -> [list] could work.) In any case, the lower classes take care of substituting the appropriate symbols based on the specific instruction generated ([v]PS, [V]PD, etc.). I still don't know how to capture the hierarchy under sse1_sse2_avx_binary_scalar_xs_xd_node_pattern_rm_rrm and other such higher-level classes. Right now it's generated by a Perl script but Chris isn't enamored of that solution. I think it can be better as well. One thought I had was to implement a "copy arguments" feature in TableGen so we could do something like this: defm FsANDN : sse1_binary_scalar_xs_node_pattern_rm< 0x55, "andn", [[(set DSTREGCLASS:$dst, (INTTYPE (and (not (INTTYPE (bitconvert (TYPE SRCREGCLASS:$src1)))), (INTTYPE (MEMOP ADDRCLASS:$src2)))))]]>, sse2_binary_scalar_xd_node_pattern_rm<''>, avx_binary_scalar_xs_node_pattern_rm<''>, avx_binary_scalar_xd_node_pattern_rm<''>; where "''" (two apostrophes) is a mnemonic for the "ditto" mark used in English (and other languages?). This way we could define fewer base classes because we wouldn't have to define intermediate base classes that just serve to aggregate other classes in order to get us down to one class and thus one argument specification. But there would still be a lot of classes to manually define. Here's an incomplete list: sse1_unary_scalar_xs_node_rm; // For generic unary sse1_unary_scalar_xs_node_pattern_rm; // To use custom patterns sse1_unary_scalar_xd_node_intrinsic_rm; // With an intrinsic sse1_unary_scalar_xd_node_pattern_intrinsic_ipattern_rm; // Custom patterns sse1_binary_scalar_xs_node_rm; // Binary plus the rest of the sse1 "xs rm" classes, the mr encodings, all the binary operations, all the sse2 classes (which look like the sse1 classes except they use "xd", all the vector classes, all the AVX classes, LRBni, etc. We still have a combinatorial explosion problem. Of course, we only have to define the ones we actually use and that cuts down significantly on the numbers, but it's still large. So I'm still looking for a complete solution. Ideas welcome. -Dave From aaronngray.lists at googlemail.com Fri May 15 13:16:49 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Fri, 15 May 2009 19:16:49 +0100 Subject: [LLVMdev] IS anyone sucessfully sing the MachO backend References: <030DC89E19BD40F2ABAB7E396330BBEC@HPLAPTOP> Message-ID: HI Chris, Okay, I was just wondering its status. Do you know what is broken about it ? Thanks, Aaron ----- Original Message ----- From: Chris Lattner To: LLVM Developers Mailing List Sent: Friday, May 15, 2009 6:00 PM Subject: Re: [LLVMdev] IS anyone sucessfully sing the MachO backend On May 15, 2009, at 6:25 AM, Aaron Gray wrote: Hi, I am working on the direct object module emission, and am wondering if anyone is successfully using the MachO backend. Nope, it's just as broken (if not more so) than the ELF writer, don't worry about breaking it. If you wanted to #if 0 it out, that would also be fine with me. -Chris ------------------------------------------------------------------------------ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090515/3bb59483/attachment.html From clattner at apple.com Fri May 15 13:17:02 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 15 May 2009 11:17:02 -0700 Subject: [LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray) In-Reply-To: <18FE97EF-AA24-420A-BF92-FB650F4565C1@me.com> References: <200905150926.08766.dag@cray.com> <18FE97EF-AA24-420A-BF92-FB650F4565C1@me.com> Message-ID: On May 15, 2009, at 10:52 AM, Gordon Henriksen wrote: > On 2009-05-15, at 07:26, David Greene wrote: > >> On Friday 15 May 2009 05:50, Jay Foad wrote: >>> >> >>>> The one major thing to be aware of is that it isn't safe to use >>>> &V[0] when V is an empty std::vector >>> >>> Oh dear. That's a bit of a flaw in the plan. I suppose the solution >>> is to switch to SmallVector whenever this might be a problem. >> >> Or use iterators. That's why they're there. > > The reason to use the pointer-length pair in preference to iterators > is that iterators make templates of everything, causing code bloat. In > my code, rather than pass the separate parameters I use a range > class something like this: I tend to prefer ranges as well, but iterators don't cause bloat. Just have something like this: template ... create(iter start, iter end) { if (start != end) return create(&*start, end-start); return create(0,0); } which inlines away. This requires the iterators to be sequential in memory, which is perfectly reasonable IMO. -Chris From clattner at apple.com Fri May 15 13:20:35 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 15 May 2009 11:20:35 -0700 Subject: [LLVMdev] IS anyone sucessfully sing the MachO backend In-Reply-To: References: <030DC89E19BD40F2ABAB7E396330BBEC@HPLAPTOP> Message-ID: <6841390F-1163-4F87-B7B6-B35A46378AFB@apple.com> On May 15, 2009, at 11:16 AM, Aaron Gray wrote: > HI Chris, > > Okay, I was just wondering its status. Do you know what is broken > about it ? > No, I just know that noone is using it... so I'm sure it's broken :) -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090515/028a4a76/attachment.html From dgregor at apple.com Fri May 15 13:24:29 2009 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 15 May 2009 11:24:29 -0700 Subject: [LLVMdev] [Cygwin] bug on SVN In-Reply-To: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com> References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com> Message-ID: <01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com> On May 15, 2009, at 11:03 AM, Aaron Gray wrote: > I am getting a bug building Cygwin on latest SVN :- > > llvm[1]: Compiling Process.cpp for Debug build > In file included from /home/ang/git/workbench/lib/System/Process.cpp: > 29: > /home/ang/git/workbench/lib/System/Unix/Process.inc: In function > 'unsigned int g > etColumns(int)': > /home/ang/git/workbench/lib/System/Unix/Process.inc:209: error: > aggregate 'winsi > ze ws' has incomplete type and cannot be defined > /home/ang/git/workbench/lib/System/Unix/Process.inc:210: error: > 'TIOCGWINSZ' was > not declared in this scope > make[1]: *** [/home/ang/build/workbench/lib/System/Debug/Process.o] > Error 1 > make[1]: Leaving directory `/home/ang/build/workbench/lib/System' > make: *** [all] Error 1 > > Having IOCTL.H does not seem to be a strict enough test for struct > winsize'es presence. > > #ifdef HAVE_SYS_IOCTL_H > // Try to determine the width of the terminal. > struct winsize ws; > if (ioctl(FileID, TIOCGWINSZ, &ws) == 0) > Columns = ws.ws_col; > #endif > > I could not see any changes in Process.cpp's SVN that could have > caused this. > Anyone got a clue ? > It's my change, here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090511/077380.html Is struct winsize declared anywhere in the Cygwin headers? - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090515/6ca08589/attachment.html From aaronngray.lists at googlemail.com Fri May 15 14:13:44 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Fri, 15 May 2009 20:13:44 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com> <01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com> Message-ID: <6917E04590514A27BAE0BFC1F0394428@HPLAPTOP> ----- Original Message ----- From: Douglas Gregor To: LLVM Developers Mailing List Sent: Friday, May 15, 2009 7:24 PM Subject: Re: [LLVMdev] [Cygwin] bug on SVN On May 15, 2009, at 11:03 AM, Aaron Gray wrote: I am getting a bug building Cygwin on latest SVN :- llvm[1]: Compiling Process.cpp for Debug build In file included from /home/ang/git/workbench/lib/System/Process.cpp:29: /home/ang/git/workbench/lib/System/Unix/Process.inc: In function 'unsigned int g etColumns(int)': /home/ang/git/workbench/lib/System/Unix/Process.inc:209: error: aggregate 'winsi ze ws' has incomplete type and cannot be defined /home/ang/git/workbench/lib/System/Unix/Process.inc:210: error: 'TIOCGWINSZ' was not declared in this scope make[1]: *** [/home/ang/build/workbench/lib/System/Debug/Process.o] Error 1 make[1]: Leaving directory `/home/ang/build/workbench/lib/System' make: *** [all] Error 1 Having IOCTL.H does not seem to be a strict enough test for struct winsize'es presence. #ifdef HAVE_SYS_IOCTL_H // Try to determine the width of the terminal. struct winsize ws; if (ioctl(FileID, TIOCGWINSZ, &ws) == 0) Columns = ws.ws_col; #endif I could not see any changes in Process.cpp's SVN that could have caused this. Anyone got a clue ? >It's my change, here: >http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090511/077380.html >Is struct winsize declared anywhere in the Cygwin headers? Doug, It is declared in Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090515/4bf5a7c6/attachment.html From jay.foad at gmail.com Fri May 15 14:19:46 2009 From: jay.foad at gmail.com (Jay Foad) Date: Fri, 15 May 2009 20:19:46 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN In-Reply-To: <6917E04590514A27BAE0BFC1F0394428@HPLAPTOP> References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com> <01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com> <6917E04590514A27BAE0BFC1F0394428@HPLAPTOP> Message-ID: > It is declared in ... which is included by , which might be a bit more standard? At least, only is listed here: http://www.opengroup.org/onlinepubs/007908775/headix.html Cheers, Jay. From eli.friedman at gmail.com Fri May 15 14:39:48 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 15 May 2009 12:39:48 -0700 Subject: [LLVMdev] SSI in LLVM In-Reply-To: <4A0DA605.3020501@dcc.ufmg.br> References: <4A0DA605.3020501@dcc.ufmg.br> Message-ID: On Fri, May 15, 2009 at 10:27 AM, Andre Tavares wrote: > 1) I want to implement a very modular design. In this way, I will have > an analysis that receives the intervals produced by > LiveIntervalAnalysis, plus a list of variables, and creates a new set of > intervals, so that each interval designates a new virtual variable, that > is visible only inside my analysis. These variables have the SSI > property. In this way, it is possible to map constraints such as (a > > 10) to an interval. I would suggest writing the SSI pass to do some active transformations rather than providing virtual variables. You can use dummy PHI nodes to rename a variable. That seems a lot more straightforward than trying to provide virtual names for a value at multiple places in the program: this way, a variable always represents itself without any special lookups. In any case, I don't think you need liveness information to compute SSI form, so I don't see the need for LiveIntervalAnalysis. > I would like to have critics on this approach so it can be well thought > before implementation to reduce reimplementation. In particular, to use > this technique, my analysis must work at the MachineFunction level, as > it must run after LiveIntervalAnalysis. Do I miss essential information > at this level, compared to the Function level? I mean, is it possible to > analysis conditionals to discover things like a > 10, or a == 10, etc? Working at the MachineFunction level is really late; this sort of analysis should be working at the IR level. If you really need liveness information, I'd suggest writing a new IR-level pass for it; computing liveness on SSA form isn't very difficult. -Eli From greened at obbligato.org Fri May 15 18:27:53 2009 From: greened at obbligato.org (David Greene) Date: Fri, 15 May 2009 18:27:53 -0500 Subject: [LLVMdev] RFC: More AVX Experience In-Reply-To: <200905151309.16211.dag@cray.com> References: <200905151309.16211.dag@cray.com> Message-ID: <4A0DFA79.1010908@obbligato.org> > plus the rest of the sse1 "xs rm" classes, the mr encodings, all the binary > operations, all the sse2 classes (which look like the sse1 classes except they > use "xd", all the vector classes, all the AVX classes, LRBni, etc. We still > have a combinatorial explosion problem. > > Of course, we only have to define the ones we actually use and that cuts > down significantly on the numbers, but it's still large. > > So I'm still looking for a complete solution. Ideas welcome. Ah, what early '30's jazz can do to spur the creative juices. So I'm driving through south Minneapolis listening to some Fletcher Henderson (try it sometime!) and it dawns on me that all we need to handle customer patterns is some way to override the default behavior of the "default" pattern. I think we can do that with some of the new operations I added. I'm thinking we could have an optional final argument that contains a list of key:value pairs that specify which defaults to override. For example: def PATTERN : Key; // Scalar defm FsANDN : sse1_sse2_avx_binary_scalar_xs_xd_node_rm_rrm< 0x55, "andn", nop, // Or some dummy dag operator [[PATTERN [[(set DSTREGCLASS:$dst, (INTTYPE (and (not (INTTYPE (bitconvert (TYPE SRCREGCLASS:$src1)))), (INTTYPE (MEMOP ADDRCLASS:$src2)))))]]]]>; Now we pass a list of one pair: [PATTERN ]. This assumes that lists can be heterogeneous. I don't know if that's true but I'll try it out. Alternatively, we could define a new 'tuple' type to handle this. Actually, since we have to declare a list with only one element type, I'm pretty sure we will have to do this, unless it's possible to declare a list of typeless objects. Which would be preferable? Hmm...as I go through this it seems that even with tuples, we can't get a list of heterogeneous tuples so maybe we have to resort to multiple extra arguments. That would be too bad because if we wanted to override one default we might have to specify the other defaults that come before it. Unless we do named parameters, which I don't want to worry about if we don't have to (I was trying to address it with key:value pairs). Down in the guts of the class hierarchy we'd have something like this: class SomeBaseClass CustomPattern = []> : Inst, !if(!null(CustomPattern), , CustomPattern)>; Hmm, I think that will even work. Now there's an additional problem if we need different patterns for various encodings (rr, rm, etc.). I'm hoping we can write generic enough patterns that we can avoid problems most of the time and for the rest of the cases we may have to write special classes. By getting rid of the default/custom pattern classes we'll reduce the class space quite a bit. Maybe even to something tractable. I'll play around with this idea and see where it goes. Does anything look really wrong with this approach? -Dave From viridia at gmail.com Fri May 15 19:21:16 2009 From: viridia at gmail.com (Talin) Date: Fri, 15 May 2009 17:21:16 -0700 Subject: [LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray) In-Reply-To: References: <200905150926.08766.dag@cray.com> <18FE97EF-AA24-420A-BF92-FB650F4565C1@me.com> Message-ID: <4A0E06FC.3070502@gmail.com> Chris Lattner wrote: > On May 15, 2009, at 10:52 AM, Gordon Henriksen wrote: > >> On 2009-05-15, at 07:26, David Greene wrote: >> >>> On Friday 15 May 2009 05:50, Jay Foad wrote: >>> >>>>> The one major thing to be aware of is that it isn't safe to use >>>>> &V[0] when V is an empty std::vector >>>>> >>>> Oh dear. That's a bit of a flaw in the plan. I suppose the solution >>>> is to switch to SmallVector whenever this might be a problem. >>>> >>> Or use iterators. That's why they're there. >>> >> The reason to use the pointer-length pair in preference to iterators >> is that iterators make templates of everything, causing code bloat. In >> my code, rather than pass the separate parameters I use a range >> class something like this: >> > > I tend to prefer ranges as well, but iterators don't cause bloat. > Just have something like this: > I tend to prefer begin/end iterators (or first/last for subranges, following the naming conventions of STL) for things like this - if the argument types are declared correctly, you should be able to use std::vector, SmallVector, or just regular POD pointers. I tend to prefer iterators for the (admittedly minor) reason that converting from a SmallVector to a start+size pair involves taking size(), which requires a scaling operation, whereas converting to first/last is just a bitcast at most. > template > ... create(iter start, iter end) { > if (start != end) > return create(&*start, end-start); > return create(0,0); > } > > which inlines away. This requires the iterators to be sequential in > memory, which is perfectly reasonable IMO. > > -Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From rklaehn at googlemail.com Sat May 16 04:58:09 2009 From: rklaehn at googlemail.com (=?ISO-8859-1?Q?R=FCdiger_Klaehn?=) Date: Sat, 16 May 2009 11:58:09 +0200 Subject: [LLVMdev] VMKit: msil optimization Message-ID: <9dcd50a60905160258y4e45677hb59010a67224dd77@mail.gmail.com> Hello all. is it possible to use LLVM to optimize existing .NET assemblies? Basically doing the following: - read in MSIL and convert into LLVM internal representation - perform global optimizations on LLVM internal representation - write out optimized MSIL using the existing LLVM backend I presume that the capability to convert MSIL into LLVM internal representation exists somewhere in VMKit. The reason I need this is the following: I have a very large C# application that is in desperate need of some optimization. The problem is that the microsoft C# compiler does almost no optimization but relies on the MS JIT compiler to do it. But the MS JIT compiler does not do any agressive optimization, especially inlining and subsequent optimizations. So the generated machine code is just atrocious and performance is much lower than expected. I know that optimizing on a MSIL level will somewhat alleviate the problem since the microsoft C++/CLR compiler does MSIL level optimizations and produces much faster code in some tests I have written. But rewriting the application in question in C++/CLR is not an option. best regards, R?diger Klaehn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/d11cbc80/attachment.html From nicolas.geoffray at lip6.fr Sat May 16 09:00:11 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Sat, 16 May 2009 16:00:11 +0200 Subject: [LLVMdev] VMKit: msil optimization In-Reply-To: <9dcd50a60905160258y4e45677hb59010a67224dd77@mail.gmail.com> References: <9dcd50a60905160258y4e45677hb59010a67224dd77@mail.gmail.com> Message-ID: <4A0EC6EB.4020208@lip6.fr> Dear Rudiger, R?diger Klaehn wrote: > Hello all. > > is it possible to use LLVM to optimize existing .NET assemblies? > It's in theory possible. LLVM+VMKit already does it for Java classes. > Basically doing the following: > > - read in MSIL and convert into LLVM internal representation > - perform global optimizations on LLVM internal representation > - write out optimized MSIL using the existing LLVM backend > > I presume that the capability to convert MSIL into LLVM internal > representation exists somewhere in VMKit. > Although I haven't worked on VMKit's .NET for a long time, and it must surely be broken for larger programs than HelloWorld, adding the capability should not be too hard. It was really straightforward to add it to VMKit's JVM. As for the state of the MSIL backend of LLVM, I don't think it's for production use yet. Assemblies have lots of information in them and maintaining them during the MSIL -> LLVM -> MSIL translations should be the hard part. Cheers, Nicolas > The reason I need this is the following: > > I have a very large C# application that is in desperate need of some > optimization. The problem is that the microsoft C# compiler does > almost no optimization but relies on the MS JIT compiler to do it. But > the MS JIT compiler does not do any agressive optimization, especially > inlining and subsequent optimizations. So the generated machine code > is just atrocious and performance is much lower than expected. > > I know that optimizing on a MSIL level will somewhat alleviate the > problem since the microsoft C++/CLR compiler does MSIL level > optimizations and produces much faster code in some tests I have > written. But rewriting the application in question in C++/CLR is not > an option. > > > best regards, > > R?diger Klaehn > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From anton at korobeynikov.info Sat May 16 10:09:25 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Sat, 16 May 2009 19:09:25 +0400 Subject: [LLVMdev] VMKit: msil optimization In-Reply-To: <4A0EC6EB.4020208@lip6.fr> References: <9dcd50a60905160258y4e45677hb59010a67224dd77@mail.gmail.com> <4A0EC6EB.4020208@lip6.fr> Message-ID: Hello, > As for the state of the MSIL backend of LLVM, I don't think it's for > production use yet. Assemblies have lots of information in them and > maintaining them during the MSIL -> LLVM -> MSIL translations should be > the hard part. This should be pretty hard. MSIL is definitely much more high level than LLVM, that's why significant portion of information will be lost during MSIL => LLVM (=lowered to vmkit-specific stuff), so I doubt that sane back reconstruction will ever be possible (consider e.g. callvirt instruction as an example). -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From rklaehn at googlemail.com Sat May 16 10:59:02 2009 From: rklaehn at googlemail.com (=?ISO-8859-1?Q?R=FCdiger_Klaehn?=) Date: Sat, 16 May 2009 17:59:02 +0200 Subject: [LLVMdev] VMKit: msil optimization In-Reply-To: References: <9dcd50a60905160258y4e45677hb59010a67224dd77@mail.gmail.com> <4A0EC6EB.4020208@lip6.fr> Message-ID: <9dcd50a60905160859m6ce6ca40re9206d269cf68880@mail.gmail.com> On Sat, May 16, 2009 at 5:09 PM, Anton Korobeynikov wrote: > Hello, > > > As for the state of the MSIL backend of LLVM, I don't think it's for > > production use yet. Assemblies have lots of information in them and > > maintaining them during the MSIL -> LLVM -> MSIL translations should be > > the hard part. > This should be pretty hard. MSIL is definitely much more high level > than LLVM, that's why significant portion of information will be lost > during MSIL => LLVM (=lowered to vmkit-specific stuff), so I doubt > that sane back reconstruction will ever be possible (consider e.g. > callvirt instruction as an example). OK. That is quite unfortunate. Does that mean that the existing LLVM MSIL backend does not work for complex LLVM programs? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/7039d5ae/attachment.html From aaronngray.lists at googlemail.com Sat May 16 11:52:37 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Sat, 16 May 2009 17:52:37 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com><01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com><6917E04590514A27BAE0BFC1F0394428@HPLAPTOP> Message-ID: <3452049ED81C41A79269BCBBBBC84953@HPLAPTOP> >> It is declared in > > ... which is included by , which might be a bit more > standard? At least, only is listed here: > > http://www.opengroup.org/onlinepubs/007908775/headix.html Cheers Jay, Cygwin has 'termios.h'. Aaron From anton at korobeynikov.info Sat May 16 11:58:37 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Sat, 16 May 2009 20:58:37 +0400 Subject: [LLVMdev] VMKit: msil optimization In-Reply-To: <9dcd50a60905160859m6ce6ca40re9206d269cf68880@mail.gmail.com> References: <9dcd50a60905160258y4e45677hb59010a67224dd77@mail.gmail.com> <4A0EC6EB.4020208@lip6.fr> <9dcd50a60905160859m6ce6ca40re9206d269cf68880@mail.gmail.com> Message-ID: Hello, > Does that mean that the existing LLVM MSIL backend does not work for complex > LLVM programs? No (modulo bugs). It should work, however it will "map" to some (C-like) subset of MSIL. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From resistor at mac.com Sat May 16 16:11:00 2009 From: resistor at mac.com (Owen Anderson) Date: Sat, 16 May 2009 14:11:00 -0700 Subject: [LLVMdev] RFC: Atomics.h Message-ID: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> Some of you may have noticed that I addedd include/llvm/System/ Atomics.h to the repository briefly, which will be used for adding support for threading in LLVM. I have tried to provided appropriate implementations of the atomic ops (currently memory fence and CAS) for platforms we care about, but my knowledge of these, and my ability to test them, is limited. So, please, if you run on any less common platform, test out the file, and send me patches to improve it if it doesn't work verbatim on your system. Thanks, --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/fe19e9cd/attachment.bin From vargaz at gmail.com Sat May 16 17:00:06 2009 From: vargaz at gmail.com (Zoltan Varga) Date: Sun, 17 May 2009 00:00:06 +0200 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> Message-ID: <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> Hi, You might want to use this: http://www.hpl.hp.com/research/linux/atomic_ops/ Zoltan On Sat, May 16, 2009 at 11:11 PM, Owen Anderson wrote: > Some of you may have noticed that I addedd include/llvm/System/Atomics.h to > the repository briefly, which will be used for adding support for threading > in LLVM. > > I have tried to provided appropriate implementations of the atomic ops > (currently memory fence and CAS) for platforms we care about, but my > knowledge of these, and my ability to test them, is limited. So, please, if > you run on any less common platform, test out the file, and send me patches > to improve it if it doesn't work verbatim on your system. > > Thanks, > > --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090517/6ac99301/attachment.html From resistor at mac.com Sat May 16 21:33:43 2009 From: resistor at mac.com (Owen Anderson) Date: Sat, 16 May 2009 19:33:43 -0700 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> Message-ID: Surprisingly enough, libatomic_ops doesn't define just a hardware memory fence call as far as I can tell. --Owen On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > Hi, > > You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > Zoltan > > On Sat, May 16, 2009 at 11:11 PM, Owen Anderson > wrote: > Some of you may have noticed that I addedd include/llvm/System/ > Atomics.h to the repository briefly, which will be used for adding > support for threading in LLVM. > > I have tried to provided appropriate implementations of the atomic > ops (currently memory fence and CAS) for platforms we care about, > but my knowledge of these, and my ability to test them, is limited. > So, please, if you run on any less common platform, test out the > file, and send me patches to improve it if it doesn't work verbatim > on your system. > > Thanks, > > --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/f560bd15/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/f560bd15/attachment.bin From resistor at mac.com Sat May 16 21:38:31 2009 From: resistor at mac.com (Owen Anderson) Date: Sat, 16 May 2009 19:38:31 -0700 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> Message-ID: <4D39E872-415E-4D3B-830F-EB82BAECF43F@mac.com> Actually, I take that back. The non-obviously named AO_nop_full() what I want. :-) --Owen On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > Hi, > > You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > Zoltan > > On Sat, May 16, 2009 at 11:11 PM, Owen Anderson > wrote: > Some of you may have noticed that I addedd include/llvm/System/ > Atomics.h to the repository briefly, which will be used for adding > support for threading in LLVM. > > I have tried to provided appropriate implementations of the atomic > ops (currently memory fence and CAS) for platforms we care about, > but my knowledge of these, and my ability to test them, is limited. > So, please, if you run on any less common platform, test out the > file, and send me patches to improve it if it doesn't work verbatim > on your system. > > Thanks, > > --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/16479e63/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/16479e63/attachment.bin From luked at cs.rochester.edu Sat May 16 21:47:09 2009 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Sat, 16 May 2009 22:47:09 -0400 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> Message-ID: <4A0F7AAD.5030702@cs.rochester.edu> Owen Anderson wrote: > Some of you may have noticed that I addedd include/llvm/System/Atomics.h > to the repository briefly, which will be used for adding support for > threading in LLVM. Just out of curiosity, is there a design document somewhere for the plan for threading? Also, atomic ops are usually pretty low level things used for nonblocking algorithms or to build higher level locking constructs. Is that the plan here too? It seems like you'd want to avoid anything too fancy since LLVM has to run on so many different architectures with their variety of memory semantics, etc. Luke > > I have tried to provided appropriate implementations of the atomic ops > (currently memory fence and CAS) for platforms we care about, but my > knowledge of these, and my ability to test them, is limited. So, > please, if you run on any less common platform, test out the file, and > send me patches to improve it if it doesn't work verbatim on your system. > > Thanks, > > --Owen > > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From jyasskin at google.com Sat May 16 22:49:46 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Sat, 16 May 2009 20:49:46 -0700 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> Message-ID: What would you do with a just-hardware memory fence? If the compiler's free to move operations over the hardware fence, that seems to defeat the purpose. C++0X provides a compiler-only fence, and a hardware+compiler fence, but no hardware-only fence, I believe for this reason. See , section 29.8. On Sat, May 16, 2009 at 7:33 PM, Owen Anderson wrote: > Surprisingly enough, libatomic_ops doesn't define just a hardware memory > fence call as far as I can tell. > --Owen > On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > > Hi, > > ? You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > ???????????????????????????? Zoltan > > On Sat, May 16, 2009 at 11:11 PM, Owen Anderson wrote: >> >> Some of you may have noticed that I addedd include/llvm/System/Atomics.h >> to the repository briefly, which will be used for adding support for >> threading in LLVM. >> >> I have tried to provided appropriate implementations of the atomic ops >> (currently memory fence and CAS) for platforms we care about, but my >> knowledge of these, and my ability to test them, is limited. ?So, please, if >> you run on any less common platform, test out the file, and send me patches >> to improve it if it doesn't work verbatim on your system. >> >> Thanks, >> >> --Owen >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ????????http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From resistor at mac.com Sat May 16 23:21:15 2009 From: resistor at mac.com (Owen Anderson) Date: Sat, 16 May 2009 21:21:15 -0700 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> Message-ID: <6382ED6F-531D-4E1F-9877-1E1ADA48DF6E@mac.com> I meant as opposed to CAS+fence, though I have since found out I was incorrect. --Owen On May 16, 2009, at 8:49 PM, Jeffrey Yasskin wrote: > What would you do with a just-hardware memory fence? If the compiler's > free to move operations over the hardware fence, that seems to defeat > the purpose. > > C++0X provides a compiler-only fence, and a hardware+compiler fence, > but no hardware-only fence, I believe for this reason. See > , > section 29.8. > > On Sat, May 16, 2009 at 7:33 PM, Owen Anderson > wrote: >> Surprisingly enough, libatomic_ops doesn't define just a hardware >> memory >> fence call as far as I can tell. >> --Owen >> On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: >> >> Hi, >> >> You might want to use this: >> >> http://www.hpl.hp.com/research/linux/atomic_ops/ >> >> Zoltan >> >> On Sat, May 16, 2009 at 11:11 PM, Owen Anderson >> wrote: >>> >>> Some of you may have noticed that I addedd include/llvm/System/ >>> Atomics.h >>> to the repository briefly, which will be used for adding support for >>> threading in LLVM. >>> >>> I have tried to provided appropriate implementations of the atomic >>> ops >>> (currently memory fence and CAS) for platforms we care about, but my >>> knowledge of these, and my ability to test them, is limited. So, >>> please, if >>> you run on any less common platform, test out the file, and send >>> me patches >>> to improve it if it doesn't work verbatim on your system. >>> >>> Thanks, >>> >>> --Owen >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/f316286f/attachment.bin From luked at cs.rochester.edu Sat May 16 23:28:14 2009 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Sun, 17 May 2009 00:28:14 -0400 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> Message-ID: <4A0F925E.3050507@cs.rochester.edu> Jeffrey Yasskin wrote: > What would you do with a just-hardware memory fence? If the compiler's > free to move operations over the hardware fence, that seems to defeat > the purpose. If your compiler memory fence (gcc's __sync_synchronize()) doesn't distinguish different kinds of fencing requirements, and your platform has different hardware fences with different costs (isync, lwsync, eieio, etc), then it can make sense to separate the two using something like asm volatile(::"memory") for the compiler fence. It gets pretty architecture dependent though. Luke > > C++0X provides a compiler-only fence, and a hardware+compiler fence, > but no hardware-only fence, I believe for this reason. See > , > section 29.8. > > On Sat, May 16, 2009 at 7:33 PM, Owen Anderson wrote: >> Surprisingly enough, libatomic_ops doesn't define just a hardware memory >> fence call as far as I can tell. >> --Owen >> On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: >> >> Hi, >> >> You might want to use this: >> >> http://www.hpl.hp.com/research/linux/atomic_ops/ >> >> Zoltan >> >> On Sat, May 16, 2009 at 11:11 PM, Owen Anderson wrote: >>> Some of you may have noticed that I addedd include/llvm/System/Atomics.h >>> to the repository briefly, which will be used for adding support for >>> threading in LLVM. >>> >>> I have tried to provided appropriate implementations of the atomic ops >>> (currently memory fence and CAS) for platforms we care about, but my >>> knowledge of these, and my ability to test them, is limited. So, please, if >>> you run on any less common platform, test out the file, and send me patches >>> to improve it if it doesn't work verbatim on your system. >>> >>> Thanks, >>> >>> --Owen >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From luked at cs.rochester.edu Sat May 16 23:42:58 2009 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Sun, 17 May 2009 00:42:58 -0400 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <4A0F925E.3050507@cs.rochester.edu> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> <4A0F925E.3050507@cs.rochester.edu> Message-ID: <4A0F95D2.4050201@cs.rochester.edu> Luke Dalessandro wrote: > Jeffrey Yasskin wrote: >> What would you do with a just-hardware memory fence? If the compiler's >> free to move operations over the hardware fence, that seems to defeat >> the purpose. > > If your compiler memory fence (gcc's __sync_synchronize()) doesn't > distinguish different kinds of fencing requirements, and your platform > has different hardware fences with different costs (isync, lwsync, > eieio, etc), then it can make sense to separate the two using something > like asm volatile(::"memory") for the compiler fence. It gets pretty > architecture dependent though. To reply to my reply, most sane implementations of these memory barriers would imply the compiler fence by slapping a memory clobber on the underlying asm, so you're point is well taken. I have seen cross platform code where they are separated though for whatever reason though. Luke > > Luke > >> C++0X provides a compiler-only fence, and a hardware+compiler fence, >> but no hardware-only fence, I believe for this reason. See >> , >> section 29.8. >> >> On Sat, May 16, 2009 at 7:33 PM, Owen Anderson wrote: >>> Surprisingly enough, libatomic_ops doesn't define just a hardware memory >>> fence call as far as I can tell. >>> --Owen >>> On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: >>> >>> Hi, >>> >>> You might want to use this: >>> >>> http://www.hpl.hp.com/research/linux/atomic_ops/ >>> >>> Zoltan >>> >>> On Sat, May 16, 2009 at 11:11 PM, Owen Anderson wrote: >>>> Some of you may have noticed that I addedd include/llvm/System/Atomics.h >>>> to the repository briefly, which will be used for adding support for >>>> threading in LLVM. >>>> >>>> I have tried to provided appropriate implementations of the atomic ops >>>> (currently memory fence and CAS) for platforms we care about, but my >>>> knowledge of these, and my ability to test them, is limited. So, please, if >>>> you run on any less common platform, test out the file, and send me patches >>>> to improve it if it doesn't work verbatim on your system. >>>> >>>> Thanks, >>>> >>>> --Owen >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From resistor at mac.com Sun May 17 00:01:07 2009 From: resistor at mac.com (Owen Anderson) Date: Sat, 16 May 2009 22:01:07 -0700 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> Message-ID: OK, I've enhanced Atomic.h by pulling in a bunch of implementations from libatomic_ops, and others that I could figure out on my own. Again, my plea: PLEASE TRY THIS OUT ON YOUR PLATFORM, AND SEND ME PATCHES IF IT DOESN'T WORK! Similarly, if you think the implementation could be improved for your platform, send me a patch. I know that Sparc doesn't work currently (no CAS implementation yet), and I'm a little unsure about the ARM version, so it'd be great if gurus for those platforms could look at them. --Owen On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > Hi, > > You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > Zoltan > > On Sat, May 16, 2009 at 11:11 PM, Owen Anderson > wrote: > Some of you may have noticed that I addedd include/llvm/System/ > Atomics.h to the repository briefly, which will be used for adding > support for threading in LLVM. > > I have tried to provided appropriate implementations of the atomic > ops (currently memory fence and CAS) for platforms we care about, > but my knowledge of these, and my ability to test them, is limited. > So, please, if you run on any less common platform, test out the > file, and send me patches to improve it if it doesn't work verbatim > on your system. > > Thanks, > > --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/6fae4db3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/6fae4db3/attachment.bin From resistor at mac.com Sun May 17 00:03:10 2009 From: resistor at mac.com (Owen Anderson) Date: Sat, 16 May 2009 22:03:10 -0700 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <4A0F7AAD.5030702@cs.rochester.edu> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <4A0F7AAD.5030702@cs.rochester.edu> Message-ID: <4BD39C8A-3E9D-4AFA-A701-4996D70C592A@mac.com> On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: > Owen Anderson wrote: >> Some of you may have noticed that I addedd include/llvm/System/ >> Atomics.h >> to the repository briefly, which will be used for adding support for >> threading in LLVM. > > Just out of curiosity, is there a design document somewhere for the > plan > for threading? Not as yet. Chris may have ideas in this direction, but I don't think they're been written down anywhere. For now, I'm just trying to enhance the thread-safety of some obviously unsafe pieces of code. > Also, atomic ops are usually pretty low level things used for > nonblocking algorithms or to build higher level locking constructs. Is > that the plan here too? It seems like you'd want to avoid anything too > fancy since LLVM has to run on so many different architectures with > their variety of memory semantics, etc. I totally agree. However, at least one case of thread-unsafety (ManagedStatic), has proven very-difficult-to-impossible to implement correctly without using lower-level operations. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090516/37f0253c/attachment.bin From baldrick at free.fr Sun May 17 02:28:11 2009 From: baldrick at free.fr (Duncan Sands) Date: Sun, 17 May 2009 09:28:11 +0200 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <4BD39C8A-3E9D-4AFA-A701-4996D70C592A@mac.com> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <4A0F7AAD.5030702@cs.rochester.edu> <4BD39C8A-3E9D-4AFA-A701-4996D70C592A@mac.com> Message-ID: <4A0FBC8B.40701@free.fr> Hi Owen, perhaps you could post a little testsuite for the atomic ops. I would be happy to run them on various machines. I have access to a bunch of multi-processor machines, unfortunately all x86 or x86-64. I also have access to single-processor alpha, arm, g5, mips and sparc64 machines. Ciao, Duncan. From rjmccall at apple.com Sun May 17 02:33:13 2009 From: rjmccall at apple.com (John McCall) Date: Sun, 17 May 2009 00:33:13 -0700 Subject: [LLVMdev] [patch] Remove getType() overrides from extractvalue and insertvalue Message-ID: <997EA2B3-85FD-455B-AF5F-6BAECB83EF8E@apple.com> Several instruction classes override getType() when the instruction always creates a particular type of value. For example, the result of insertelement is always a vector, so InsertElementInst overrides getType() to return a VectorType*. This makes perfect sense. However, ExtractValueInst and InsertValueInst override getType() to return a PointerType*, which does not make sense and is in fact never correct for the latter instruction; this is probably a relic of an oversight during class creation. So this patch simply removes these overrides, which I suppose is technically an API change. John. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gettype.patch.txt Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090517/efccfd7a/attachment.txt From baldrick at free.fr Sun May 17 07:10:10 2009 From: baldrick at free.fr (Duncan Sands) Date: Sun, 17 May 2009 14:10:10 +0200 Subject: [LLVMdev] SSI in LLVM In-Reply-To: <4A0DA605.3020501@dcc.ufmg.br> References: <4A0DA605.3020501@dcc.ufmg.br> Message-ID: <4A0FFEA2.8020704@free.fr> Hi Andre, LLVM has a target independent intermediate representation (IR) which is what the optimizations run by "opt" work on. This IR can be fed into the interpreter, the JIT, the code generators, static analysers etc. The code generators generate code for particular target processors; this is what llc does. You want to work at the IR level, not the codegen level, so none of the LLVM code under lib/CodeGen/ is relevant to you. In particular LiveIntervalAnalysis is part of codegen, so you should ignore it. Look instead inside lib/Analysis and lib/Transforms. Ciao, Duncan. > I am one of the summer of coders working on LLVM this year. My > project is to implement the ABCD algorithm for array bounds checking, > and also a bitwidth analysis that maps variables to an approximation of > its size in bits. To implement this, I will have to simulate a > intermediate representation called SSI (Static Single Information) form > on top of LLVM SSA representation. The SSI form has the property that > each use of a variable post-dominates its definition. Also, if there are > two uses of the same variable, say, u(v1) and u(v2), then, either u(v1) > dominates u(v2) or vice-versa. > > I would like to discuss my approach with you guys, so that you can > redirect me if I am going through a bad path, so I am listing some > points below: > > 1) I want to implement a very modular design. In this way, I will have > an analysis that receives the intervals produced by > LiveIntervalAnalysis, plus a list of variables, and creates a new set of > intervals, so that each interval designates a new virtual variable, that > is visible only inside my analysis. These variables have the SSI > property. In this way, it is possible to map constraints such as (a > > 10) to an interval. > > 2) Each client gives to my analysis the variables that it wants mapped > to SSI. For instance, the ABCD client passes all the variables that are > used as indexes of arrays, or as array sizes. A pass to eliminate dead > code passes all the variables used inside conditionals, and the pass > that does bitwidth analysis passes all the variables of type int, for > instance. > > 3) This implies that each client will have to traverse the program > representation harvesting the variables of interest. My analysis will > take care of simulating the SSI representation for those variables. > > 4) Queries can be made given an instruction index, as computed by > LiveIntervalAnalysis. For instance, a typical query would be: is a > x > at program point 110. > > 5) Keeping the intervals ordered, we can answer queries in O(ln N), > where N is the maximal program index. > > I would like to have critics on this approach so it can be well thought > before implementation to reduce reimplementation. In particular, to use > this technique, my analysis must work at the MachineFunction level, as > it must run after LiveIntervalAnalysis. Do I miss essential information > at this level, compared to the Function level? I mean, is it possible to > analysis conditionals to discover things like a > 10, or a == 10, etc? > > Please, feel free to ask me any clarification you may think about. I > would really appreciate any comments and thoughts you guys may have. > > Thanks, > From luked at cs.rochester.edu Sun May 17 07:23:09 2009 From: luked at cs.rochester.edu (Luke Dalessandro) Date: Sun, 17 May 2009 08:23:09 -0400 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <4BD39C8A-3E9D-4AFA-A701-4996D70C592A@mac.com> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <4A0F7AAD.5030702@cs.rochester.edu> <4BD39C8A-3E9D-4AFA-A701-4996D70C592A@mac.com> Message-ID: <4A1001AD.7070506@cs.rochester.edu> Owen Anderson wrote: > > On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: > >> Also, atomic ops are usually pretty low level things used for >> nonblocking algorithms or to build higher level locking constructs. Is >> that the plan here too? It seems like you'd want to avoid anything too >> fancy since LLVM has to run on so many different architectures with >> their variety of memory semantics, etc. > > I totally agree. However, at least one case of thread-unsafety > (ManagedStatic), has proven very-difficult-to-impossible to implement > correctly without using lower-level operations. > Yes, double-checked locking is a pain. There's a C++ safe implementation in http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html in the "Making it work with explicit memory barriers" section. As far as I know, it is still considered to work. Luke > --Owen > > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From resistor at mac.com Sun May 17 12:08:45 2009 From: resistor at mac.com (Owen Anderson) Date: Sun, 17 May 2009 10:08:45 -0700 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <4A1001AD.7070506@cs.rochester.edu> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <4A0F7AAD.5030702@cs.rochester.edu> <4BD39C8A-3E9D-4AFA-A701-4996D70C592A@mac.com> <4A1001AD.7070506@cs.rochester.edu> Message-ID: <893613F0-82B2-479E-8B6B-57E88D78A94D@mac.com> On May 17, 2009, at 5:23 AM, Luke Dalessandro wrote: > Owen Anderson wrote: >> >> On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: >> >>> Also, atomic ops are usually pretty low level things used for >>> nonblocking algorithms or to build higher level locking >>> constructs. Is >>> that the plan here too? It seems like you'd want to avoid anything >>> too >>> fancy since LLVM has to run on so many different architectures with >>> their variety of memory semantics, etc. >> >> I totally agree. However, at least one case of thread-unsafety >> (ManagedStatic), has proven very-difficult-to-impossible to implement >> correctly without using lower-level operations. >> > > Yes, double-checked locking is a pain. There's a C++ safe > implementation > in > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html > in the "Making it work with explicit memory barriers" section. As > far as > I know, it is still considered to work. Our problems are actually deeper than that, because we need to interact well with static constructors. This means that we can't use a mutex with a non-constant initializer, or else we can't depend on it being properly initialized before the ManagedStatic is accessed. While this would be possible with pthread mutexes, I know of no good way to do it for Windows CRITICAL_SECTION's. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090517/907801f3/attachment.bin From edwintorok at gmail.com Sun May 17 12:54:23 2009 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sun, 17 May 2009 20:54:23 +0300 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: <893613F0-82B2-479E-8B6B-57E88D78A94D@mac.com> References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <4A0F7AAD.5030702@cs.rochester.edu> <4BD39C8A-3E9D-4AFA-A701-4996D70C592A@mac.com> <4A1001AD.7070506@cs.rochester.edu> <893613F0-82B2-479E-8B6B-57E88D78A94D@mac.com> Message-ID: <4A104F4F.6060008@gmail.com> On 2009-05-17 20:08, Owen Anderson wrote: > > On May 17, 2009, at 5:23 AM, Luke Dalessandro wrote: > >> Owen Anderson wrote: >>> >>> On May 16, 2009, at 7:47 PM, Luke Dalessandro wrote: >>> >>>> Also, atomic ops are usually pretty low level things used for >>>> nonblocking algorithms or to build higher level locking constructs. Is >>>> that the plan here too? It seems like you'd want to avoid anything too >>>> fancy since LLVM has to run on so many different architectures with >>>> their variety of memory semantics, etc. >>> >>> I totally agree. However, at least one case of thread-unsafety >>> (ManagedStatic), has proven very-difficult-to-impossible to implement >>> correctly without using lower-level operations. >>> >> >> Yes, double-checked locking is a pain. There's a C++ safe implementation >> in >> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html >> in the "Making it work with explicit memory barriers" section. As far as >> I know, it is still considered to work. > > Our problems are actually deeper than that, because we need to > interact well with static constructors. This means that we can't use > a mutex with a non-constant initializer, or else we can't depend on it > being properly initialized before the ManagedStatic is accessed. > While this would be possible with pthread mutexes, I know of no good > way to do it for Windows CRITICAL_SECTION's. There is a static mutex implementation in Boost, that uses PTHREAD_MUTEX_INITIALIZER when pthread is available, and uses InterlockedCompareAndExchange on win32 (no mutexes, or criticalsections): https://svn.boost.org/trac/boost/browser/trunk/libs/regex/src/static_mutex.cpp This may be useful too: https://svn.boost.org/trac/boost/browser/trunk/boost/thread/win32/once.hpp https://svn.boost.org/trac/boost/browser/trunk/boost/thread/pthread/once.hpp It doesn't use any inline assembly. Best regards, --Edwin From clattner at apple.com Sun May 17 14:32:11 2009 From: clattner at apple.com (Chris Lattner) Date: Sun, 17 May 2009 12:32:11 -0700 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> Message-ID: On May 16, 2009, at 10:01 PM, Owen Anderson wrote: > OK, I've enhanced Atomic.h by pulling in a bunch of implementations > from libatomic_ops, and others that I could figure out on my own. > > Again, my plea: PLEASE TRY THIS OUT ON YOUR PLATFORM, AND SEND ME > PATCHES IF IT DOESN'T WORK! Similarly, if you think the > implementation could be improved for your platform, send me a patch. > > I know that Sparc doesn't work currently (no CAS implementation > yet), and I'm a little unsure about the ARM version, so it'd be > great if gurus for those platforms could look at them. Owen, I would really rather that you didn't take this path. Threading support in LLVM should always be optional: it should be possible to use LLVM on systems where we don't have support for threading operations. Indeed, some systems don't support threads! Given that, I think it makes sense to start out the atomics operations very simple: just make them work for compilers that support GCC 4.2's atomics. Since things will be changing quickly initially, this makes it easy to prototype and build things out, and this also avoids pulling in an external library with a (compatible but) different license. In practice, I think a huge chunk of the community will be served when LLVM supports GCC 4.2 atomics + a windows implementation. I don't see a reason to make things any more complex than that. Since llvm-gcc supports atomics, someone doing development on a supported architecture can just build llvm-gcc single threaded, which provides them with a compiler that supports atomics on their platform. > Our problems are actually deeper than that, because we need to > interact well with static constructors. This means that we can't > use a mutex with a non-constant initializer, or else we can't depend > on it being properly initialized before the ManagedStatic is > accessed. While this would be possible with pthread mutexes, I know > of no good way to do it for Windows CRITICAL_SECTION's. Actually, global static constructors are evil and should be eliminated. No static constructors should do anything non-trivial, and it is essential that ManagedStatic *not have a constructor*. That is its entire design point. However, ManagedStatic should theoretically pretty simple with double checked locking. The observation is that llvm_shutdown() can only be called on one thread, but that lazily initialization of data structures can happen from multiple threads. This means that the "get" operation should look something like this (an suitably fenced version of): if (Ptr == 0) { lock(); if (Ptr == 0) init(); unlock(); } Also, I see no reason why the lock needs to be per-object. Just use a heavy weight global "pthreads" lock in the .cpp file. When you get back to hacking on ManagedStatic, please define this in one method, not duplicated in ->, *, etc. -Chris From resistor at mac.com Sun May 17 15:20:02 2009 From: resistor at mac.com (Owen Anderson) Date: Sun, 17 May 2009 13:20:02 -0700 Subject: [LLVMdev] RFC: Atomics.h In-Reply-To: References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> <295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> Message-ID: <6BF939BD-723F-40B9-8E53-BBE414631991@mac.com> On May 17, 2009, at 12:32 PM, Chris Lattner wrote: > Owen, I would really rather that you didn't take this path. Threading > support in LLVM should always be optional: it should be possible to > use LLVM on systems where we don't have support for threading > operations. Indeed, some systems don't support threads! I'm not trying to make it required. I had provided threads-disabled versions of all the operations. > Given that, I think it makes sense to start out the atomics > operations very simple: just make them work for compilers that support > GCC 4.2's atomics. Since things will be changing quickly initially, > this makes it easy to prototype and build things out, and this also > avoids pulling in an external library with a (compatible but) > different license. > > In practice, I think a huge chunk of the community will be served when > LLVM supports GCC 4.2 atomics + a windows implementation. I don't see > a reason to make things any more complex than that. Since llvm-gcc > supports atomics, someone doing development on a supported > architecture can just build llvm-gcc single threaded, which provides > them with a compiler that supports atomics on their platform. After thinking about this some more, I think you're right. Trying to support every platform anyone cares about is rapidly becoming a nightmare. Setting GCC4.2 as a baseline requirement (and presumably providing a Windows implementation as well) is probably a good way to get this back to a sane amount of stuff to support. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090517/94b7c3c0/attachment.bin From andrewl at lenharth.org Sun May 17 22:56:17 2009 From: andrewl at lenharth.org (Andrew Lenharth) Date: Sun, 17 May 2009 22:56:17 -0500 Subject: [LLVMdev] DataStructure Analysis ds-aa can not stop when passing mysqld In-Reply-To: <20090513143632.pq8gvq8ksok8oo48@cubmail.cc.columbia.edu> References: <041DD5ACCD9F824BB2273B9421CA13D2FCF485@RZ-EX-06.rz.uni-karlsruhe.de> <0B94D2F6-D5C2-4F39-BA2F-BA9A81DCB982@apple.com> <20090513143632.pq8gvq8ksok8oo48@cubmail.cc.columbia.edu> Message-ID: <85dfcd7f0905172056n21e2a746w4beffe50d796115c@mail.gmail.com> On Wed, May 13, 2009 at 1:36 PM, wrote: > Quoting Chris Lattner : > > Dear staff, > ? ? I am using the ds-aa to pass mysqld. I compile mysqld 4.0.12 > statically (compile all libraries statically to the executable) and > got the bc file, named it as mysqld.bc3. > ? ? I use the command to pass: > > opt -load /lib/libLLVMDataStructure.so -ds-aa > mysqld.bc3 -print-alias-sets -disable-output > > ? ? However, I got a lot of "cast in ... " on output screen like this: > > cast in strxnmov > ? ? ? ? %13 = inttoptr i32 %10 to i8* ? ? ? ? ? ; [#uses=1] > > ? ? In addition, and pass can not stop for a long time, and the last > output is the "cast in ... " as above. inttoptr casts are very bad for alias analysis. DSA has some code in it these days to try to track common inttoptr idioms, but this code likely doesn't scale well. Andrew > Thanks, > Heming > > >> >> On May 13, 2009, at 7:22 AM, Stripf, Timo wrote: >> >>> Hi all, >>> >>> i?m working atm on a backend for a processor architecture that is >>> capable of storing the carry flag of ADDC in an 1-bit register >>> class. So I tried to lower the ADDC instruction to generate two >>> register values as result. On the tablegen description of the >>> instruction i came across the tablegen restriction that only one >>> output result of one instruction is possible: >>> >>> ?assert(NumResults <= 1 && >>> ? ? ? ? "We only work with nodes with zero or one result so far!"); >>> >>> So my question is now how much work it would be to remove this >>> restriction in tablegen. What do I have to take into consideration? >>> >> >> I don't know offhand, but this would be a very welcome improvement! >> >> -Chris > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From hc2428 at columbia.edu Sun May 17 23:32:34 2009 From: hc2428 at columbia.edu (hc2428 at columbia.edu) Date: Mon, 18 May 2009 00:32:34 -0400 Subject: [LLVMdev] DataStructure Analysis ds-aa can not stop when passing mysqld In-Reply-To: <85dfcd7f0905172056n21e2a746w4beffe50d796115c@mail.gmail.com> References: <041DD5ACCD9F824BB2273B9421CA13D2FCF485@RZ-EX-06.rz.uni-karlsruhe.de> <0B94D2F6-D5C2-4F39-BA2F-BA9A81DCB982@apple.com> <20090513143632.pq8gvq8ksok8oo48@cubmail.cc.columbia.edu> <85dfcd7f0905172056n21e2a746w4beffe50d796115c@mail.gmail.com> Message-ID: <20090518003234.7um59yb5n4cgsgc8@cubmail.cc.columbia.edu> Quoting Andrew Lenharth : Hi Andrew, Thanks for your reply. How can I eliminate the inttoptr instruction from my software? Can any compile option achieve this goal? Or shall I modify the source code in software manually? Thanks, Heming > On Wed, May 13, 2009 at 1:36 PM, wrote: >> Quoting Chris Lattner : >> >> Dear staff, >> ? ? I am using the ds-aa to pass mysqld. I compile mysqld 4.0.12 >> statically (compile all libraries statically to the executable) and >> got the bc file, named it as mysqld.bc3. >> ? ? I use the command to pass: >> >> opt -load /lib/libLLVMDataStructure.so -ds-aa >> mysqld.bc3 -print-alias-sets -disable-output >> >> ? ? However, I got a lot of "cast in ... " on output screen like this: >> >> cast in strxnmov >> ? ? ? ? %13 = inttoptr i32 %10 to i8* ? ? ? ? ? ; [#uses=1] >> >> ? ? In addition, and pass can not stop for a long time, and the last >> output is the "cast in ... " as above. > > inttoptr casts are very bad for alias analysis. DSA has some code in > it these days to try to track common inttoptr idioms, but this code > likely doesn't scale well. > > Andrew > >> Thanks, >> Heming >> >> >>> >>> On May 13, 2009, at 7:22 AM, Stripf, Timo wrote: >>> >>>> Hi all, >>>> >>>> i?m working atm on a backend for a processor architecture that is >>>> capable of storing the carry flag of ADDC in an 1-bit register >>>> class. So I tried to lower the ADDC instruction to generate two >>>> register values as result. On the tablegen description of the >>>> instruction i came across the tablegen restriction that only one >>>> output result of one instruction is possible: >>>> >>>> ?assert(NumResults <= 1 && >>>> ? ? ? ? "We only work with nodes with zero or one result so far!"); >>>> >>>> So my question is now how much work it would be to remove this >>>> restriction in tablegen. What do I have to take into consideration? >>>> >>> >>> I don't know offhand, but this would be a very welcome improvement! >>> >>> -Chris >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From viridia at gmail.com Mon May 18 01:54:09 2009 From: viridia at gmail.com (Talin) Date: Sun, 17 May 2009 23:54:09 -0700 Subject: [LLVMdev] Getting exceptions to work? Message-ID: <4A110611.6000303@gmail.com> I've been struggling for several days, trying to get native exceptions to work in my code. I managed to boil down the IR to the simplest possible example that I can think of. If anyone on this list can tell me what changes I need to make to the following code to get it to work (i.e. return 0 instead of a bus error), it would make my life immensely better. ; ModuleID = 'ExceptionTest' %Object = type {} %UnwindInfo = type { i64, void (i32, %UnwindInfo *)*, i16, i16 } %Throwable = type { %Object, %UnwindInfo } define i32 @main(i32, i8**) nounwind { entry: invoke fastcc void @throwSomething() to label %nounwind unwind label %catch catch: ret i32 0 nounwind: ret i32 -1 } define internal fastcc void @throwSomething() noreturn { entry: %throwable = malloc %Throwable call fastcc void @Throwable.construct(%Throwable* %throwable) %unwindInfo = getelementptr %Throwable* %throwable, i32 0, i32 1 %throw = call i32 @_Unwind_RaiseException(%UnwindInfo* %unwindInfo) unreachable } define internal fastcc void @Throwable.construct(%Throwable* %self) nounwind { entry: %exceptionClass = getelementptr %Throwable* %self, i32 0, i32 1, i32 0 store i64 0, i64* %exceptionClass %exceptionCleanup = getelementptr %Throwable* %self, i32 0, i32 1, i32 1 store void (i32, %UnwindInfo *)* @exceptionCleanupFn, void (i32, %UnwindInfo *)** %exceptionCleanup %private1 = getelementptr %Throwable* %self, i32 0, i32 1, i32 2 store i16 0, i16* %private1 %private2 = getelementptr %Throwable* %self, i32 0, i32 1, i32 3 store i16 0, i16* %private2 ret void } define internal void @exceptionCleanupFn(i32 %reason, %UnwindInfo * %exc) { ret void } declare i32 @_Unwind_RaiseException(%UnwindInfo*) noreturn -- Talin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ExTest.ll Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090517/6b2e2a8c/attachment.pl From eli.friedman at gmail.com Mon May 18 02:17:57 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 18 May 2009 00:17:57 -0700 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A110611.6000303@gmail.com> References: <4A110611.6000303@gmail.com> Message-ID: On Sun, May 17, 2009 at 11:54 PM, Talin wrote: > I've been struggling for several days, trying to get native exceptions to > work in my code. I managed to boil down the IR to the simplest possible > example that I can think of. > > If anyone on this list can tell me what changes I need to make to the > following code to get it to work (i.e. return 0 instead of a bus error), it > would make my life immensely better. It looks like you're missing some required code in main() to catch the exception. Try comparing with the output of "llvm-gcc -x c++ - -o - -S -O2 -emit-llvm" for a simple program like the following: __attribute__((noinline)) int a() { throw 1; } int main() { try { a(); } catch (...) { return 0; } return 1; } -Eli From nicolas.geoffray at lip6.fr Mon May 18 02:31:30 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 18 May 2009 09:31:30 +0200 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A110611.6000303@gmail.com> References: <4A110611.6000303@gmail.com> Message-ID: <4A110ED2.6060809@lip6.fr> Hi Talin, You're not using the llvm intrinsics for exception handling, so your code won't work. Using _Unwind_RaiseException should be OK, but your main function must at least use llvm.eh.exception, llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. Nicolas Talin wrote: > I've been struggling for several days, trying to get native exceptions > to work in my code. I managed to boil down the IR to the simplest > possible example that I can think of. > > If anyone on this list can tell me what changes I need to make to the > following code to get it to work (i.e. return 0 instead of a bus > error), it would make my life immensely better. > > ; ModuleID = 'ExceptionTest' > %Object = type {} > %UnwindInfo = type { i64, void (i32, %UnwindInfo *)*, i16, i16 } > %Throwable = type { %Object, %UnwindInfo } > > define i32 @main(i32, i8**) nounwind { > entry: > invoke fastcc void @throwSomething() to label %nounwind unwind > label %catch > > catch: > ret i32 0 > > nounwind: > ret i32 -1 > } > > define internal fastcc void @throwSomething() noreturn { > entry: > %throwable = malloc %Throwable > call fastcc void @Throwable.construct(%Throwable* %throwable) > %unwindInfo = getelementptr %Throwable* %throwable, i32 0, i32 1 > %throw = call i32 @_Unwind_RaiseException(%UnwindInfo* > %unwindInfo) > unreachable > } > > define internal fastcc void @Throwable.construct(%Throwable* %self) > nounwind { > entry: > %exceptionClass = getelementptr %Throwable* %self, i32 0, i32 1, > i32 0 > store i64 0, i64* %exceptionClass > %exceptionCleanup = getelementptr %Throwable* %self, i32 0, i32 > 1, i32 1 > store void (i32, %UnwindInfo *)* @exceptionCleanupFn, void (i32, > %UnwindInfo *)** %exceptionCleanup > %private1 = getelementptr %Throwable* %self, i32 0, i32 1, i32 2 > store i16 0, i16* %private1 > %private2 = getelementptr %Throwable* %self, i32 0, i32 1, i32 3 > store i16 0, i16* %private2 > ret void > } > > define internal void @exceptionCleanupFn(i32 %reason, %UnwindInfo * > %exc) { > ret void > } > > declare i32 @_Unwind_RaiseException(%UnwindInfo*) noreturn > > -- Talin > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From baldrick at free.fr Mon May 18 03:03:52 2009 From: baldrick at free.fr (Duncan Sands) Date: Mon, 18 May 2009 10:03:52 +0200 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A110611.6000303@gmail.com> References: <4A110611.6000303@gmail.com> Message-ID: <4A111668.8050303@free.fr> Hi Talin, > I've been struggling for several days, trying to get native exceptions > to work in my code. I managed to boil down the IR to the simplest > possible example that I can think of. currently exception handling requires you to specify a personality function (do this using an selector intrinsic). Ciao, Duncan. From jay.foad at gmail.com Mon May 18 05:00:59 2009 From: jay.foad at gmail.com (Jay Foad) Date: Mon, 18 May 2009 11:00:59 +0100 Subject: [LLVMdev] "Processed value not in any map!" failures In-Reply-To: <4A0DA14C.9060008@free.fr> References: <4A0DA14C.9060008@free.fr> Message-ID: > building with ENABLE_EXPENSIVE_CHECKS=1 turns on a bunch > of extra sanity checking in LegalizeTypes. ?"make check" used to > pass all tests with this on. ?I notice that the failing node is a target > constant. ?These are a special case, and the code dealing with them > was tweaked a little while ago - probably that caused this. ?I will > take a look. Thanks for fixing this, Duncan! Jay. From benny.kra at googlemail.com Mon May 18 07:56:21 2009 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Mon, 18 May 2009 14:56:21 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version Message-ID: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> At the moment llvm-config outputs "2.6svn" if llvm is build from trunk $ llvm-config --version 2.6svn Some external projects (built out-of-tree) need to know which revision of llvm is installed. LDC currently asks llvm-config --src-root for the source directory and then parses svn info's output to get the revision number. This requires the user to keep the llvm source tree around even if it is not needed to build ldc. The attached patch modifies the llvm build system (both autotools and cmake) to write the revision into PACKAGE_VERSION: $ llvm-config --version 2.6-71981 or, if it couldn't find svn during the build: $ llvm-config --version 2.6-svn -------------- next part -------------- A non-text attachment was scrubbed... Name: revversion.patch Type: application/octet-stream Size: 1846 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090518/ebd8d507/attachment.obj -------------- next part -------------- From fvbommel at wxs.nl Mon May 18 09:05:01 2009 From: fvbommel at wxs.nl (Frits van Bommel) Date: Mon, 18 May 2009 16:05:01 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> Message-ID: <4A116B0D.5050104@wxs.nl> Benjamin Kramer wrote: > At the moment llvm-config outputs "2.6svn" if llvm is build from trunk > > $ llvm-config --version > 2.6svn > > Some external projects (built out-of-tree) need to know which revision > of llvm is installed. LDC currently asks llvm-config --src-root for the > source directory and then parses svn info's output to get the revision > number. This requires the user to keep the llvm source tree around even > if it is not needed to build ldc. Not technically true; it's not *required*. However, if this isn't done you need to set it manually in the cmake configuration... > The attached patch modifies the llvm build system (both autotools and > cmake) to write the revision into PACKAGE_VERSION: > > $ llvm-config --version > 2.6-71981 I don't think that's enough for LDC; we want to be able to compare the version with #if, so we need it to produce something like '#define LLVM_REV 71981' (i.e. a raw integer, not a string). From anton at korobeynikov.info Mon May 18 09:51:31 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 18 May 2009 18:51:31 +0400 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4A116B0D.5050104@wxs.nl> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> Message-ID: > I don't think that's enough for LDC; we want to be able to compare the version > with #if, so we need it to produce something like '#define LLVM_REV 71981' (i.e. > a raw integer, not a string). Why don't introduce some another option for it? E.g. llvm-config --revision ? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From benny.kra at googlemail.com Mon May 18 09:56:55 2009 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Mon, 18 May 2009 16:56:55 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4A116B0D.5050104@wxs.nl> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> Message-ID: Frits van Bommel wrote: > I don't think that's enough for LDC; we want to be able to compare > the version > with #if, so we need it to produce something like '#define LLVM_REV > 71981' (i.e. > a raw integer, not a string). Here is another patch which adds a new option to llvm-config: $ llvm-config --revision or, if the build script couldn't find svn: $ llvm-config --revision 0 I think this is also a safer approach, it won't break anything that relies on the current llvm-config behavior. -------------- next part -------------- A non-text attachment was scrubbed... Name: revv2.patch Type: application/octet-stream Size: 2959 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090518/dd604bf2/attachment.obj -------------- next part -------------- From xerxes at zafena.se Mon May 18 10:03:20 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 18 May 2009 17:03:20 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4A116B0D.5050104@wxs.nl> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> Message-ID: <4A1178B8.8040802@zafena.se> Frits van Bommel skrev: > Benjamin Kramer wrote: > >> At the moment llvm-config outputs "2.6svn" if llvm is build from trunk >> >> $ llvm-config --version >> 2.6svn >> >> Some external projects (built out-of-tree) need to know which revision >> of llvm is installed. LDC currently asks llvm-config --src-root for the >> source directory and then parses svn info's output to get the revision >> number. This requires the user to keep the llvm source tree around even >> if it is not needed to build ldc. >> > > Not technically true; it's not *required*. However, if this isn't done you need > to set it manually in the cmake configuration... > > >> The attached patch modifies the llvm build system (both autotools and >> cmake) to write the revision into PACKAGE_VERSION: >> >> $ llvm-config --version >> 2.6-71981 >> > > I don't think that's enough for LDC; we want to be able to compare the version > with #if, so we need it to produce something like '#define LLVM_REV 71981' (i.e. > a raw integer, not a string). > When we build Icedtea shark JIT we use the llvm-config version to make the icedtea code compatible with api changes in llvm. I belive you are trying to do something similarwith LDC. This can be done without changing the llvm codebase. I suggest the following: add to the LDC configure. LLVM_CFLAGS="$LLVM_CFLAGS -DLLVM_VERSION=`$LLVM_CONFIG --version | sed 's/\.//;s/svn.*//'`" this will take the llvm-config --version output and truncates the versionnumber from 2.6svn to 26 now the LLVM_VERSION can be used in your source code like this: #if LLVM_VERSION >= 26 /*llvm 2.6 and above compatible code*/ #endif #if LLVM_VERSION >= 25 // etc... #endif cheers Xerxes From andrelct at dcc.ufmg.br Mon May 18 10:09:42 2009 From: andrelct at dcc.ufmg.br (Andre Tavares) Date: Mon, 18 May 2009 12:09:42 -0300 Subject: [LLVMdev] llvm-java Message-ID: <4A117A36.8030504@dcc.ufmg.br> Hello, I'm working on a project to remove unnecessary array bound checks in Java. For this purpose I will need to use llvm-java. What is the state of llvm-java? Can someone explain how to build and use it? I saw some old emails on the list, and some about a SoC 2008 on Java, but I didn't find anything regarding its current state and documentation. Regards, -- Andre Tavares Master Student in Computer Science - UFMG - Brasil http://dcc.ufmg.br/~andrelct From samuraileumas at yahoo.com Mon May 18 10:25:03 2009 From: samuraileumas at yahoo.com (Samuel Crow) Date: Mon, 18 May 2009 08:25:03 -0700 (PDT) Subject: [LLVMdev] llvm-java In-Reply-To: <4A117A36.8030504@dcc.ufmg.br> References: <4A117A36.8030504@dcc.ufmg.br> Message-ID: <903165.44062.qm@web62003.mail.re1.yahoo.com> Hello, LLVM-Java has been rendered obsolete by http://vmkit.llvm.org/ so look into using VMKit instead. --Sam ----- Original Message ---- > From: Andre Tavares > To: LLVMdev at cs.uiuc.edu > Sent: Monday, May 18, 2009 10:09:42 AM > Subject: [LLVMdev] llvm-java > > Hello, > > I'm working on a project to remove unnecessary array bound checks in > Java. For this purpose I will need to use llvm-java. > > What is the state of llvm-java? Can someone explain how to build and use it? > > I saw some old emails on the list, and some about a SoC 2008 on Java, > but I didn't find anything regarding its current state and documentation. > > Regards, > > -- > Andre Tavares > Master Student in Computer Science - UFMG - Brasil > http://dcc.ufmg.br/~andrelct > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From andrelct at dcc.ufmg.br Mon May 18 10:31:33 2009 From: andrelct at dcc.ufmg.br (Andre Tavares) Date: Mon, 18 May 2009 12:31:33 -0300 Subject: [LLVMdev] llvm-java In-Reply-To: <903165.44062.qm@web62003.mail.re1.yahoo.com> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> Message-ID: <4A117F55.3070807@dcc.ufmg.br> Samuel Crow wrote: > Hello, > > LLVM-Java has been rendered obsolete by http://vmkit.llvm.org/ so look into using VMKit instead. > > --Sam > > > > ----- Original Message ---- > >> From: Andre Tavares >> To: LLVMdev at cs.uiuc.edu >> Sent: Monday, May 18, 2009 10:09:42 AM >> Subject: [LLVMdev] llvm-java >> >> Hello, >> >> I'm working on a project to remove unnecessary array bound checks in >> Java. For this purpose I will need to use llvm-java. >> >> What is the state of llvm-java? Can someone explain how to build and use it? >> >> I saw some old emails on the list, and some about a SoC 2008 on Java, >> but I didn't find anything regarding its current state and documentation. >> >> Regards, >> >> -- >> Andre Tavares >> Master Student in Computer Science - UFMG - Brasil >> http://dcc.ufmg.br/~andrelct >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > Thanks Samuel I will look it. -- Andre Tavares Master Student in Computer Science - UFMG - Brasil http://dcc.ufmg.br/~andrelct From aph at redhat.com Mon May 18 10:44:32 2009 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 May 2009 16:44:32 +0100 Subject: [LLVMdev] llvm-java In-Reply-To: <903165.44062.qm@web62003.mail.re1.yahoo.com> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> Message-ID: <4A118260.9010305@redhat.com> Samuel Crow wrote: >> From: Andre Tavares >> I'm working on a project to remove unnecessary array bound checks in >> Java. For this purpose I will need to use llvm-java. >> >> What is the state of llvm-java? Can someone explain how to build and use it? >> >> I saw some old emails on the list, and some about a SoC 2008 on Java, >> but I didn't find anything regarding its current state and documentation. > LLVM-Java has been rendered obsolete by http://vmkit.llvm.org/ so look into using VMKit instead. Also, if you can make the capability generic enough to use in Shark (more at http://gbenson.net/) that would be very useful. The key, I suspect, is to allow the Java front end mark an array.length field in such a way that LLVM knows that field doesn't alias anything else and is constant, so it can be hoisted out of loops. Andrew. From anton at korobeynikov.info Mon May 18 10:54:01 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 18 May 2009 19:54:01 +0400 Subject: [LLVMdev] llvm-java In-Reply-To: <4A117A36.8030504@dcc.ufmg.br> References: <4A117A36.8030504@dcc.ufmg.br> Message-ID: <1242662041.18321.192.camel@aslstation> Hello, Andre > I'm working on a project to remove unnecessary array bound checks in > Java. For this purpose I will need to use llvm-java. Why? Why don't use vmkit for this? > What is the state of llvm-java? Can someone explain how to build and use it? It's dead and unmaintained for years. Most probably nobody will be able to run it without major rewrite. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From baldrick at free.fr Mon May 18 10:54:10 2009 From: baldrick at free.fr (Duncan Sands) Date: Mon, 18 May 2009 17:54:10 +0200 Subject: [LLVMdev] llvm-java In-Reply-To: <4A117A36.8030504@dcc.ufmg.br> References: <4A117A36.8030504@dcc.ufmg.br> Message-ID: <4A1184A2.3090900@free.fr> Hi Andre, > I'm working on a project to remove unnecessary array bound checks in > Java. For this purpose I will need to use llvm-java. > > What is the state of llvm-java? Can someone explain how to build and use it? > > I saw some old emails on the list, and some about a SoC 2008 on Java, > but I didn't find anything regarding its current state and documentation. I have a much better idea: work on removing unnecessary array bound checks in Ada. Who cares about this java thing anyway?! Seriously though, while of course it is important to work on java, may I humbly request that you also look at the llvm-gcc Ada front-end. Ada, like Pascal (which it derives from) does bound checking on all array accesses and does many other runtime checks too. As such it should be a good test for any such pass. It's not particularly hard to build llvm-gcc with Ada support if you are using x86-32 linux, see http://llvm.org/docs/GCCFEBuildInstrs.html Even better, llvm-gcc comes with the complete Ada ACATS testsuite, so after building all you have to do is change into the gcc subdirectory and do: make -k check-acats Ciao, Duncan. From nicolas.geoffray at lip6.fr Mon May 18 10:57:42 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 18 May 2009 17:57:42 +0200 Subject: [LLVMdev] llvm-java In-Reply-To: <4A117A36.8030504@dcc.ufmg.br> References: <4A117A36.8030504@dcc.ufmg.br> Message-ID: <4A118576.3080301@lip6.fr> Hi Andre, Andre Tavares wrote: > Hello, > > I'm working on a project to remove unnecessary array bound checks in > Java. For this purpose I will need to use llvm-java. > > What is the state of llvm-java? Can someone explain how to build and use it? > > llvm-java won't compile with current versions of LLVM. Instead, you could use VMKit (http://vmkit.llvm.org). Cheers, Nicolas From nicolas.geoffray at lip6.fr Mon May 18 11:17:58 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 18 May 2009 18:17:58 +0200 Subject: [LLVMdev] llvm-java In-Reply-To: <4A118260.9010305@redhat.com> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> Message-ID: <4A118A36.9040109@lip6.fr> Hi Andrew, Andrew Haley wrote: > Also, if you can make the capability generic enough to use in Shark > (more at http://gbenson.net/) that would be very useful. > > Agree. > The key, I suspect, is to allow the Java front end mark an array.length > field in such a way that LLVM knows that field doesn't alias anything else > and is constant, so it can be hoisted out of loops. > For that matter, VMKit already has this optimization. Instead of emitting an LLVM load of the size field, VMKit emits a GetArrayLength call, flagged readnone. The GVN pass will merge all GetArrayLength of a same array and the LICM pass will hoist the call. Once theses passes are complete, VMKit lowers the call to the actual load. :) Cheers, Nicolas > Andrew. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From jay.foad at gmail.com Mon May 18 11:26:14 2009 From: jay.foad at gmail.com (Jay Foad) Date: Mon, 18 May 2009 17:26:14 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN In-Reply-To: <01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com> References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com> <01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com> Message-ID: 2009/5/15 Douglas Gregor : > > On May 15, 2009, at 11:03 AM, Aaron Gray wrote: > > I am getting a bug building Cygwin on latest SVN :- > > llvm[1]: Compiling Process.cpp for Debug build > In file included from /home/ang/git/workbench/lib/System/Process.cpp:29: > /home/ang/git/workbench/lib/System/Unix/Process.inc: In function 'unsigned > int g > etColumns(int)': > /home/ang/git/workbench/lib/System/Unix/Process.inc:209: error: aggregate > 'winsi > ze ws' has incomplete type and cannot be defined > /home/ang/git/workbench/lib/System/Unix/Process.inc:210: error: 'TIOCGWINSZ' > was > ?not declared in this scope > make[1]: *** [/home/ang/build/workbench/lib/System/Debug/Process.o] Error 1 > make[1]: Leaving directory `/home/ang/build/workbench/lib/System' > make: *** [all] Error 1 > > Having IOCTL.H does not seem to be a strict enough test for struct > winsize'es presence. > #ifdef HAVE_SYS_IOCTL_H > ? // Try to determine the width of the terminal. > ? struct winsize ws; > ? if (ioctl(FileID, TIOCGWINSZ, &ws) == 0) > ??? Columns = ws.ws_col; > #endif > > I could not see any changes in Process.cpp's SVN that could have caused > this. > Anyone got a clue ? > > It's my change, here: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090511/077380.html > Is struct winsize declared anywhere in the Cygwin headers? Hi Doug, LLVM is still not building on cygwin. Can you fix it, please? Thanks, Jay. From aph at redhat.com Mon May 18 11:35:51 2009 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 May 2009 17:35:51 +0100 Subject: [LLVMdev] llvm-java In-Reply-To: <4A118A36.9040109@lip6.fr> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> <4A118A36.9040109@lip6.fr> Message-ID: <4A118E67.7050508@redhat.com> Nicolas Geoffray wrote: > Hi Andrew, > > Andrew Haley wrote: >> Also, if you can make the capability generic enough to use in Shark >> (more at http://gbenson.net/) that would be very useful. > > Agree. > >> The key, I suspect, is to allow the Java front end mark an array.length >> field in such a way that LLVM knows that field doesn't alias anything else >> and is constant, so it can be hoisted out of loops. > > For that matter, VMKit already has this optimization. Instead of > emitting an LLVM load of the size field, VMKit emits a GetArrayLength > call, flagged readnone. The GVN pass will merge all GetArrayLength of a > same array and the LICM pass will hoist the call. Once theses passes are > complete, VMKit lowers the call to > the actual load. Right, so that part should be trivial. So, does the array bounds check elimination already work? If it does, that will considerably reduce the work that Andre needs to do. To say the least... Andrew. From fvbommel at wxs.nl Mon May 18 12:06:46 2009 From: fvbommel at wxs.nl (Frits van Bommel) Date: Mon, 18 May 2009 19:06:46 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4A1178B8.8040802@zafena.se> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> <4A1178B8.8040802@zafena.se> Message-ID: <4A1195A6.5040906@wxs.nl> Xerxes R?nby wrote: > Frits van Bommel skrev: >> Benjamin Kramer wrote: >>> The attached patch modifies the llvm build system (both autotools and >>> cmake) to write the revision into PACKAGE_VERSION: >>> >>> $ llvm-config --version >>> 2.6-71981 >>> >> I don't think that's enough for LDC; we want to be able to compare the version >> with #if, so we need it to produce something like '#define LLVM_REV 71981' (i.e. >> a raw integer, not a string). >> > When we build Icedtea shark JIT we use the llvm-config version to make > the icedtea code compatible with api changes in llvm. > I belive you are trying to do something similarwith LDC. This can be > done without changing the llvm codebase. > > I suggest the following: > add to the LDC configure. > > LLVM_CFLAGS="$LLVM_CFLAGS -DLLVM_VERSION=`$LLVM_CONFIG --version | sed 's/\.//;s/svn.*//'`" > > this will take the llvm-config --version output and truncates the versionnumber from > > 2.6svn to 26 > > now the LLVM_VERSION can be used in your source code like this: > > #if LLVM_VERSION >= 26 > /*llvm 2.6 and above compatible code*/ > #endif > > #if LLVM_VERSION >= 25 > // etc... > #endif That's not precise enough. API changes are introduced in svn all the time, and bugs are fixed (obsoleting workarounds). We currently test for 5 different trunk revisions after 2.5. Though I suppose a similar technique could be used with the original version of the patch, sed'ing out the revision nr. It'd certainly be less error-prone than the current approach. From edwintorok at gmail.com Mon May 18 12:13:27 2009 From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=) Date: Mon, 18 May 2009 20:13:27 +0300 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4A1195A6.5040906@wxs.nl> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> <4A1178B8.8040802@zafena.se> <4A1195A6.5040906@wxs.nl> Message-ID: <4A119737.9060601@gmail.com> On 2009-05-18 20:06, Frits van Bommel wrote: > Xerxes R?nby wrote: > >> Frits van Bommel skrev: >> >>> Benjamin Kramer wrote: >>> >>>> The attached patch modifies the llvm build system (both autotools and >>>> cmake) to write the revision into PACKAGE_VERSION: >>>> >>>> $ llvm-config --version >>>> 2.6-71981 >>>> >>>> >>> I don't think that's enough for LDC; we want to be able to compare the version >>> with #if, so we need it to produce something like '#define LLVM_REV 71981' (i.e. >>> a raw integer, not a string). >>> >>> >> When we build Icedtea shark JIT we use the llvm-config version to make >> the icedtea code compatible with api changes in llvm. >> I belive you are trying to do something similarwith LDC. This can be >> done without changing the llvm codebase. >> >> I suggest the following: >> add to the LDC configure. >> >> LLVM_CFLAGS="$LLVM_CFLAGS -DLLVM_VERSION=`$LLVM_CONFIG --version | sed 's/\.//;s/svn.*//'`" >> >> this will take the llvm-config --version output and truncates the versionnumber from >> >> 2.6svn to 26 >> >> now the LLVM_VERSION can be used in your source code like this: >> >> #if LLVM_VERSION >= 26 >> /*llvm 2.6 and above compatible code*/ >> #endif >> >> #if LLVM_VERSION >= 25 >> // etc... >> #endif >> > > That's not precise enough. API changes are introduced in svn all the time, and > bugs are fixed (obsoleting workarounds). We currently test for 5 different trunk > revisions after 2.5. > > Though I suppose a similar technique could be used with the original version of > the patch, sed'ing out the revision nr. It'd certainly be less error-prone than > the current approach. I think you don't need to support all trunk revisions. People using trunk could be told to either update to a certain revision, or stick to a released version. This should suffice: #if LLVM_VERSION >= 25 .... #endif #if LLVM_VERSION == 26 #if LLVM_REVISION < MINIMUM_THAT_CONTAINS_ALLYOUNEED #error "Please update to SVN rXYZ" #else //code for SVN API #endif Best regards, --Edwin From nicolas.geoffray at lip6.fr Mon May 18 12:15:09 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Mon, 18 May 2009 19:15:09 +0200 Subject: [LLVMdev] llvm-java In-Reply-To: <4A118E67.7050508@redhat.com> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> Message-ID: <4A11979D.5030607@lip6.fr> Andrew Haley wrote: > > Right, so that part should be trivial. So, does the array bounds check > elimination already work? If it does, that will considerably reduce > the work that Andre needs to do. To say the least... > > Trivial bounds check elimination already work, such as tab[2] = 1; tab[1] = 2 (the second affectation won't have a bounds checks). Although I don't know the details, I believe Andre also targets less trivial eliminations. Nicolas > Andrew. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From dgregor at apple.com Mon May 18 12:22:08 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 18 May 2009 10:22:08 -0700 Subject: [LLVMdev] [Cygwin] bug on SVN In-Reply-To: <6917E04590514A27BAE0BFC1F0394428@HPLAPTOP> References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com> <01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com> <6917E04590514A27BAE0BFC1F0394428@HPLAPTOP> Message-ID: <3B15CFBE-898B-44A7-8F4E-D2C74930355E@apple.com> On May 15, 2009, at 12:13 PM, Aaron Gray wrote: > > ----- Original Message ----- > From: Douglas Gregor > To: LLVM Developers Mailing List > Sent: Friday, May 15, 2009 7:24 PM > Subject: Re: [LLVMdev] [Cygwin] bug on SVN > > > On May 15, 2009, at 11:03 AM, Aaron Gray wrote: > >> I am getting a bug building Cygwin on latest SVN :- >> >> llvm[1]: Compiling Process.cpp for Debug build >> In file included from /home/ang/git/workbench/lib/System/ >> Process.cpp:29: >> /home/ang/git/workbench/lib/System/Unix/Process.inc: In function >> 'unsigned int g >> etColumns(int)': >> /home/ang/git/workbench/lib/System/Unix/Process.inc:209: error: >> aggregate 'winsi >> ze ws' has incomplete type and cannot be defined >> /home/ang/git/workbench/lib/System/Unix/Process.inc:210: error: >> 'TIOCGWINSZ' was >> not declared in this scope >> make[1]: *** [/home/ang/build/workbench/lib/System/Debug/Process.o] >> Error 1 >> make[1]: Leaving directory `/home/ang/build/workbench/lib/System' >> make: *** [all] Error 1 >> >> Having IOCTL.H does not seem to be a strict enough test for struct >> winsize'es presence. >> >> #ifdef HAVE_SYS_IOCTL_H >> // Try to determine the width of the terminal. >> struct winsize ws; >> if (ioctl(FileID, TIOCGWINSZ, &ws) == 0) >> Columns = ws.ws_col; >> #endif >> >> I could not see any changes in Process.cpp's SVN that could have >> caused this. >> Anyone got a clue ? >> > > >It's my change, here: > > >http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- > Mon-20090511/077380.html > > >Is struct winsize declared anywhere in the Cygwin headers? > > Doug, > > It is declared in > Okay, we're now checking for in addition to . Hopefully, things are working again on Cygwin with r72018 (but I can't test it here). - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090518/172d6b3a/attachment.html From dnmh68 at hotmail.com Mon May 18 12:32:08 2009 From: dnmh68 at hotmail.com (dan mihai) Date: Mon, 18 May 2009 17:32:08 +0000 Subject: [LLVMdev] dumping IR Message-ID: Hello, I am new to LLVM. I would like to see the effect of each pass on IR, and in particular to see which pass performed certain changes. So, I was wondering if there is a command line option that dumps the IR after each pass. Thank you, Dan _________________________________________________________________ Hotmail? has a new way to see what's up with your friends. http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090518/a0168163/attachment.html From criswell at cs.uiuc.edu Mon May 18 12:57:15 2009 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 18 May 2009 12:57:15 -0500 Subject: [LLVMdev] llvm-gcc on OpenSolaris for SPARC Message-ID: <4A11A17B.7000004@cs.uiuc.edu> Dear All, Is anyone using llvm-gcc and LLVM on OpenSolaris compiling for the SPARC architecture? I see that it's listed under supported platforms, but I don't see a pre-built llvm-gcc front-end for it. I know someone here at Illinois that needs it, but I'd like to know if compiling llvm-gcc is likely to work before I try it. Thanks in advance. -- John T. From fvbommel at wxs.nl Mon May 18 13:35:58 2009 From: fvbommel at wxs.nl (Frits van Bommel) Date: Mon, 18 May 2009 20:35:58 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4A119737.9060601@gmail.com> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> <4A1178B8.8040802@zafena.se> <4A1195A6.5040906@wxs.nl> <4A119737.9060601@gmail.com> Message-ID: <4A11AA8E.9020103@wxs.nl> T?r?k Edwin wrote: > I think you don't need to support all trunk revisions. > People using trunk could be told to either update to a certain revision, > or stick to a released version. We don't support /all/ trunk revisions, but we don't like to force upgrades unless it's really needed so we try to at least support most recent revisions. One of the reasons is that not all of our developers use the same trunk revision, and recompiling LLVM trunk is not something everyone likes to do once a day. (It's nice if you can put it off for a couple of days without things breaking) From echristo at apple.com Mon May 18 13:47:19 2009 From: echristo at apple.com (Eric Christopher) Date: Mon, 18 May 2009 11:47:19 -0700 Subject: [LLVMdev] [patch] Remove getType() overrides from extractvalue and insertvalue In-Reply-To: <997EA2B3-85FD-455B-AF5F-6BAECB83EF8E@apple.com> References: <997EA2B3-85FD-455B-AF5F-6BAECB83EF8E@apple.com> Message-ID: <46D9930E-FBD3-4D46-891C-80F8FB3EDADC@apple.com> On May 17, 2009, at 12:33 AM, John McCall wrote: > Several instruction classes override getType() when the instruction > always creates a particular type of value. For example, the result > of insertelement is always a vector, so InsertElementInst overrides > getType() to return a VectorType*. This makes perfect sense. > However, ExtractValueInst and InsertValueInst override getType() to > return a PointerType*, which does not make sense and is in fact > never correct for the latter instruction; this is probably a relic > of an oversight during class creation. So this patch simply removes > these overrides, which I suppose is technically an API change. I've gone ahead and committed this - thanks John! -eric From dag at cray.com Mon May 18 14:27:34 2009 From: dag at cray.com (David Greene) Date: Mon, 18 May 2009 14:27:34 -0500 Subject: [LLVMdev] dumping IR In-Reply-To: References: Message-ID: <200905181427.34294.dag@cray.com> On Monday 18 May 2009 12:32, dan mihai wrote: > Hello, > > I am new to LLVM. > I would like to see the effect of each pass on IR, and in particular to see > which pass performed certain changes. So, I was wondering if there is a > command line option that dumps the IR after each pass. Not yet, but I have a patch that provides this. I've been meaning to send it upstream. I'll get on it and hopefully have it in in a couple of days. -Dave From aaronngray.lists at googlemail.com Mon May 18 14:30:00 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Mon, 18 May 2009 20:30:00 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com><01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com><6917E04590514A27BAE0BFC1F0394428@HPLAPTOP> <3B15CFBE-898B-44A7-8F4E-D2C74930355E@apple.com> Message-ID: <053F39ED69DD49629FC2B2599165F2E2@HPLAPTOP> Doug, Thanks, I will be in a position to check it again tomorrow. Aaron ----- Original Message ----- From: Douglas Gregor To: LLVM Developers Mailing List Sent: Monday, May 18, 2009 6:22 PM Subject: Re: [LLVMdev] [Cygwin] bug on SVN On May 15, 2009, at 12:13 PM, Aaron Gray wrote: ----- Original Message ----- From: Douglas Gregor To: LLVM Developers Mailing List Sent: Friday, May 15, 2009 7:24 PM Subject: Re: [LLVMdev] [Cygwin] bug on SVN On May 15, 2009, at 11:03 AM, Aaron Gray wrote: I am getting a bug building Cygwin on latest SVN :- llvm[1]: Compiling Process.cpp for Debug build In file included from /home/ang/git/workbench/lib/System/Process.cpp:29: /home/ang/git/workbench/lib/System/Unix/Process.inc: In function 'unsigned int g etColumns(int)': /home/ang/git/workbench/lib/System/Unix/Process.inc:209: error: aggregate 'winsi ze ws' has incomplete type and cannot be defined /home/ang/git/workbench/lib/System/Unix/Process.inc:210: error: 'TIOCGWINSZ' was not declared in this scope make[1]: *** [/home/ang/build/workbench/lib/System/Debug/Process.o] Error 1 make[1]: Leaving directory `/home/ang/build/workbench/lib/System' make: *** [all] Error 1 Having IOCTL.H does not seem to be a strict enough test for struct winsize'es presence. #ifdef HAVE_SYS_IOCTL_H // Try to determine the width of the terminal. struct winsize ws; if (ioctl(FileID, TIOCGWINSZ, &ws) == 0) Columns = ws.ws_col; #endif I could not see any changes in Process.cpp's SVN that could have caused this. Anyone got a clue ? >It's my change, here: >http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090511/077380.html >Is struct winsize declared anywhere in the Cygwin headers? Doug, It is declared in Okay, we're now checking for in addition to . Hopefully, things are working again on Cygwin with r72018 (but I can't test it here). - Doug ------------------------------------------------------------------------------ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090518/8fc99c17/attachment.html From clattner at apple.com Mon May 18 14:34:28 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 18 May 2009 12:34:28 -0700 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4A11AA8E.9020103@wxs.nl> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> <4A1178B8.8040802@zafena.se> <4A1195A6.5040906@wxs.nl> <4A119737.9060601@gmail.com> <4A11AA8E.9020103@wxs.nl> Message-ID: On May 18, 2009, at 11:35 AM, Frits van Bommel wrote: > T?r?k Edwin wrote: >> I think you don't need to support all trunk revisions. >> People using trunk could be told to either update to a certain >> revision, >> or stick to a released version. > > We don't support /all/ trunk revisions, but we don't like to force > upgrades > unless it's really needed so we try to at least support most recent > revisions. I agree that this is a really useful thing to support. On side of being willing to break APIs is that we should work hard to make people with out-of-tree code be able to cope with this, even though we shouldn't be afraid of breaking APIs. The idea of the patch to add the new option to llvm-config sounds great to me. One concern: does an svn up now cause a complete relink of all llvm tools? Ideally, I'd like to see something like this: $ svn up u docs/LangRef.html $ make ... only llvm-config is "rebuilt" ... -Chris From benny.kra at googlemail.com Mon May 18 14:45:55 2009 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Mon, 18 May 2009 21:45:55 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> <4A1178B8.8040802@zafena.se> <4A1195A6.5040906@wxs.nl> <4A119737.9060601@gmail.com> <4A11AA8E.9020103@wxs.nl> Message-ID: <9118AE83-DACE-4240-BABA-788271278BCA@gmail.com> Chris Lattner wrote: > The idea of the patch to add the new option to llvm-config sounds > great to me. One concern: does an svn up now cause a complete relink > of all llvm tools? Ideally, I'd like to see something like this: In the current version of my patch the revision is only updated on a re-configure/CMake. On a second thought that is quite stupid. But I'm not sure what's the best way to fix this. I guess we need to add a target which is always run to llvm-config's Makefile ... From clattner at apple.com Mon May 18 15:02:57 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 18 May 2009 13:02:57 -0700 Subject: [LLVMdev] memory lifetime and invariance Message-ID: FYI, I wrote up some thoughts on this here: http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt The intention is to allow front-ends to express things like "I know this memory is a constant in this region" and to allow the optimizer/ codegen to perform more aggressive stack slot merging. -Chris From ofv at wanadoo.es Mon May 18 15:22:43 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Mon, 18 May 2009 22:22:43 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> <4A1178B8.8040802@zafena.se> <4A1195A6.5040906@wxs.nl> <4A119737.9060601@gmail.com> <4A11AA8E.9020103@wxs.nl> <9118AE83-DACE-4240-BABA-788271278BCA@gmail.com> Message-ID: <87iqjytb3g.fsf@telefonica.net> Benjamin Kramer writes: > In the current version of my patch the revision is only updated on a > re-configure/CMake. On a second thought that is quite stupid. But I'm > not sure what's the best way to fix this. I guess we need to add a > target which is always run to llvm-config's Makefile ... This is easy: see the logic for regenerating llvm-config when the file that contains the library dependencies changes. Why do you use `svn info' and not `svnversion'? And this brings another question: how do you deal with modified working copies? -- ?scar Fuentes Desarrollo de Software From jay.foad at gmail.com Mon May 18 15:25:18 2009 From: jay.foad at gmail.com (Jay Foad) Date: Mon, 18 May 2009 21:25:18 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN In-Reply-To: <3B15CFBE-898B-44A7-8F4E-D2C74930355E@apple.com> References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com> <01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com> <6917E04590514A27BAE0BFC1F0394428@HPLAPTOP> <3B15CFBE-898B-44A7-8F4E-D2C74930355E@apple.com> Message-ID: > Okay, we're now checking for in addition to . > Hopefully, things are working again on Cygwin with r72018 (but I can't test > it here). It's still building here, but it definitely gets further than it used to. Thanks Doug! Jay. From varonrotem at gmail.com Mon May 18 15:26:44 2009 From: varonrotem at gmail.com (Rotem Varon) Date: Mon, 18 May 2009 23:26:44 +0300 Subject: [LLVMdev] IDE for llvm Message-ID: <4f5edbea0905181326q611feb9cn760294c14adae9fa@mail.gmail.com> Hi, I am new in the "Linux business" and i need to add an optimization to the LLVM compiler. I would like to know what is the bast way to debug (IDE) the LLVM compiler ? To be more precise, what is the equivalent to Microsoft visual studio on Linux platform? is it eclipse? I want features like: syntax highlight, go to def, etc. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090518/dfb5462a/attachment.html From samuraileumas at yahoo.com Mon May 18 15:43:30 2009 From: samuraileumas at yahoo.com (Samuel Crow) Date: Mon, 18 May 2009 13:43:30 -0700 (PDT) Subject: [LLVMdev] IDE for llvm In-Reply-To: <4f5edbea0905181326q611feb9cn760294c14adae9fa@mail.gmail.com> References: <4f5edbea0905181326q611feb9cn760294c14adae9fa@mail.gmail.com> Message-ID: <298748.58073.qm@web62006.mail.re1.yahoo.com> Hello, Eclipse is pretty good. If you want something with a smaller memory footprint there's always Code::Blocks for C++. It isn't as advanced as Eclipse though. I don't know if anybody has done the configuration files for LLVM-GCC on those IDEs yet but it should definitely be possible to modify from the standard GCC profiles. If you find something better, let us know. --Sam ________________________________ From: Rotem Varon To: LLVM Developers Mailing List Sent: Monday, May 18, 2009 3:26:44 PM Subject: [LLVMdev] IDE for llvm Hi, I am new in the "Linux business" and i need to add an optimization to the LLVM compiler. I would like to know what is the bast way to debug (IDE) the LLVM compiler ? To be more precise, what is the equivalent to Microsoft visual studio on Linux platform? is it eclipse? I want features like: syntax highlight, go to def, etc. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090518/95b781dc/attachment.html From aaronngray.lists at googlemail.com Mon May 18 15:49:28 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Mon, 18 May 2009 21:49:28 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com><01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com><6917E04590514A27BAE0BFC1F0394428@HPLAPTOP><3B15CFBE-898B-44A7-8F4E-D2C74930355E@apple.com> Message-ID: <949959A0F8C447379618527FF772CCC3@HPLAPTOP> >> Okay, we're now checking for in addition to . >> Hopefully, things are working again on Cygwin with r72018 (but I can't >> test >> it here). > > It's still building here, but it definitely gets further than it used > to. Thanks Doug! Jay, Do you mean it does not build or does build ? I had freeked it and added a #include to Cygwins include/sys/ioctrl.h and it built fine. Aaron From benny.kra at googlemail.com Mon May 18 15:51:27 2009 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Mon, 18 May 2009 22:51:27 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <87iqjytb3g.fsf@telefonica.net> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> <4A1178B8.8040802@zafena.se> <4A1195A6.5040906@wxs.nl> <4A119737.9060601@gmail.com> <4A11AA8E.9020103@wxs.nl> <9118AE83-DACE-4240-BABA-788271278BCA@gmail.com> <87iqjytb3g.fsf@telefonica.net> Message-ID: <4734A662-3F73-401E-884B-3EADC39E33D5@gmail.com> ?scar Fuentes wrote: > Why do you use `svn info' and not `svnversion'? bad habit. I'm not very familiar with svnversion and its output. > And this brings another question: how do you deal with modified > working > copies? We could add a M or "dirty" to the revision number. But I don't know how this would affect things like "if (revision >= 12345)". > This is easy: see the logic for regenerating llvm-config when the file > that contains the library dependencies changes. hmm, sounds reasonable since it's in the same Makefile. But I probably won't have time to look into this until thursday. Damn exams. If anyone likes to volunteer: just do it ;) From cedric.venet at laposte.net Mon May 18 16:03:41 2009 From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=) Date: Mon, 18 May 2009 23:03:41 +0200 Subject: [LLVMdev] IDE for llvm In-Reply-To: <298748.58073.qm@web62006.mail.re1.yahoo.com> References: <4f5edbea0905181326q611feb9cn760294c14adae9fa@mail.gmail.com> <298748.58073.qm@web62006.mail.re1.yahoo.com> Message-ID: <4A11CD2D.4070709@laposte.net> > > I don't know if anybody has done the configuration files for LLVM-GCC > on those IDEs yet but it should definitely be possible to modify from > the standard GCC profiles. The CMake build system should work on linux (since it do work on windows) and can generate projects for eclipse CDT, KDevelop and Code::Blocks. From bique.alexandre at gmail.com Mon May 18 16:09:27 2009 From: bique.alexandre at gmail.com (Alexandre Bique) Date: Mon, 18 May 2009 21:09:27 +0000 Subject: [LLVMdev] IDE for llvm In-Reply-To: <4A11CD2D.4070709@laposte.net> References: <4f5edbea0905181326q611feb9cn760294c14adae9fa@mail.gmail.com> <298748.58073.qm@web62006.mail.re1.yahoo.com> <4A11CD2D.4070709@laposte.net> Message-ID: <5d3bb3090905181409i2589ee32q76a3253461af30e5@mail.gmail.com> You can try QtCreator: http://qt.gitorious.org/qt-creator -- Alexandre Bique From dag at cray.com Mon May 18 16:17:10 2009 From: dag at cray.com (David Greene) Date: Mon, 18 May 2009 16:17:10 -0500 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4A11AA8E.9020103@wxs.nl> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A119737.9060601@gmail.com> <4A11AA8E.9020103@wxs.nl> Message-ID: <200905181617.11215.dag@cray.com> On Monday 18 May 2009 13:35, Frits van Bommel wrote: > T?r?k Edwin wrote: > > I think you don't need to support all trunk revisions. > > People using trunk could be told to either update to a certain revision, > > or stick to a released version. > > We don't support /all/ trunk revisions, but we don't like to force upgrades > unless it's really needed so we try to at least support most recent > revisions. > > One of the reasons is that not all of our developers use the same trunk > revision, and recompiling LLVM trunk is not something everyone likes to do > once a day. (It's nice if you can put it off for a couple of days without > things breaking) There's an easy way to fix these kinds of problems. Deprecate interfaces for one release. I brought this up before but the idea was quickly shot down. It's insane to litter your code with #ifdefs based on SVN revisions. This is exactly the kind of situation that the LLVM community needs to address. Changing APIs is fine. Ripping out old versions without first deprecating them for a release causes nightmares all around. -Dave From fvbommel at wxs.nl Mon May 18 16:26:28 2009 From: fvbommel at wxs.nl (Frits van Bommel) Date: Mon, 18 May 2009 23:26:28 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <87iqjytb3g.fsf@telefonica.net> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> <4A1178B8.8040802@zafena.se> <4A1195A6.5040906@wxs.nl> <4A119737.9060601@gmail.com> <4A11AA8E.9020103@wxs.nl> <9118AE83-DACE-4240-BABA-788271278BCA@gmail.com> <87iqjytb3g.fsf@telefonica.net> Message-ID: <4A11D284.3070702@wxs.nl> ?scar Fuentes wrote: > Why do you use `svn info' and not `svnversion'? He probably copied this from LDC. We used to use `svnversion` for LDC, but I changed it to `svn info` because it was noticeably faster[1]. This may be less of an issue for LLVM where builds take more time anyway, decreasing the relative impact. > And this brings another question: how do you deal with modified working > copies? If you use svnversion it will append an 'M' to the revision number; see `svnversion --help`. [1]: IIRC svnversion took several times longer than the rest of an incremental build if little had changed. From max_stonebraker at yahoo.com Mon May 18 16:32:03 2009 From: max_stonebraker at yahoo.com (Max Stonebraker) Date: Mon, 18 May 2009 14:32:03 -0700 (PDT) Subject: [LLVMdev] Invoking LLVM Andersens Programmatically Message-ID: <777921.46188.qm@web59910.mail.ac4.yahoo.com> Hello, How do apply the LLVM Andersens alias analysis direclty to a Module object. I'm trying to avoid using the PassManager. Max -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090518/aec81e30/attachment.html From max_stonebraker at yahoo.com Mon May 18 17:02:20 2009 From: max_stonebraker at yahoo.com (Max Stonebraker) Date: Mon, 18 May 2009 15:02:20 -0700 (PDT) Subject: [LLVMdev] Invoking LLVM Andersens Programmatically Message-ID: <638795.46627.qm@web59905.mail.ac4.yahoo.com> Hello, How do apply the LLVM Andersens alias analysis direclty to a Module object. I'm trying to avoid using the PassManager. Max -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090518/1a9d9a89/attachment-0001.html From fvbommel at wxs.nl Mon May 18 17:04:06 2009 From: fvbommel at wxs.nl (Frits van Bommel) Date: Tue, 19 May 2009 00:04:06 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4734A662-3F73-401E-884B-3EADC39E33D5@gmail.com> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A116B0D.5050104@wxs.nl> <4A1178B8.8040802@zafena.se> <4A1195A6.5040906@wxs.nl> <4A119737.9060601@gmail.com> <4A11AA8E.9020103@wxs.nl> <9118AE83-DACE-4240-BABA-788271278BCA@gmail.com> <87iqjytb3g.fsf@telefonica.net> <4734A662-3F73-401E-884B-3EADC39E33D5@gmail.com> Message-ID: <4A11DB56.4030805@wxs.nl> Benjamin Kramer wrote: > ?scar Fuentes wrote: >> And this brings another question: how do you deal with modified >> working >> copies? > > We could add a M or "dirty" to the revision number. But I don't know > how this would affect things like "if (revision >= 12345)". It should be easy enough to sed out. From fvbommel at wxs.nl Mon May 18 17:08:21 2009 From: fvbommel at wxs.nl (Frits van Bommel) Date: Tue, 19 May 2009 00:08:21 +0200 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <200905181617.11215.dag@cray.com> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <4A119737.9060601@gmail.com> <4A11AA8E.9020103@wxs.nl> <200905181617.11215.dag@cray.com> Message-ID: <4A11DC55.4070006@wxs.nl> David Greene wrote: > There's an easy way to fix these kinds of problems. Deprecate interfaces for > one release. I brought this up before but the idea was quickly shot down. > It's insane to litter your code with #ifdefs based on SVN revisions. > > This is exactly the kind of situation that the LLVM community needs to > address. Changing APIs is fine. Ripping out old versions without first > deprecating them for a release causes nightmares all around. On the other hand, I've found code breakage to be a very good motivator to fix it right away :). (In some cases, even before anyone (including me) ever saw the error...) From dag at cray.com Mon May 18 17:40:59 2009 From: dag at cray.com (David Greene) Date: Mon, 18 May 2009 17:40:59 -0500 Subject: [LLVMdev] [PATCH] llvm-config: add svn revision to --version In-Reply-To: <4A11DC55.4070006@wxs.nl> References: <4F9A10C4-4E8E-4D6A-BD62-D71EF04CF8DB@gmail.com> <200905181617.11215.dag@cray.com> <4A11DC55.4070006@wxs.nl> Message-ID: <200905181740.59795.dag@cray.com> On Monday 18 May 2009 17:08, Frits van Bommel wrote: > David Greene wrote: > > There's an easy way to fix these kinds of problems. Deprecate interfaces > > for one release. I brought this up before but the idea was quickly shot > > down. It's insane to litter your code with #ifdefs based on SVN > > revisions. > > > > This is exactly the kind of situation that the LLVM community needs to > > address. Changing APIs is fine. Ripping out old versions without first > > deprecating them for a release causes nightmares all around. > > On the other hand, I've found code breakage to be a very good motivator to > fix it right away :). > (In some cases, even before anyone (including me) ever saw the error...) But what kind of breakage? The risk of upgrading is that not only do APIs change, so do the algorithms, etc. So you have to track down bugs as well as fix APIs. Then you have the problem sorting out whether you caused the bug by not converting APIs correctly or the bug exists upstream. Really, it's much better to isolate points of failure. We're talking about basic software engineering and maintenance practice. The current situation is fine for single-user projects or small research graoups. It absolutely does not work well for even mid-sized teams in a time-to-market commercial setting where stability is king. I'm curious to hear from the other commercial vendors out there. How do you deal with the current process? -Dave From keveman at gmail.com Mon May 18 20:29:20 2009 From: keveman at gmail.com (Manjunath Kudlur) Date: Mon, 18 May 2009 18:29:20 -0700 Subject: [LLVMdev] TableGen pattern Message-ID: <68c4c3e20905181829k6435e8ecm39be7538aac9aa1e@mail.gmail.com> Hello, I am trying to convert the subtree (vector_shuffle v2f32, v2f32 (build_vector imm1, imm2)) to a machine instruction that takes 2 v2f32's and 2 immediates. I tried the following table gen pattern : (set v2f32Reg:$dst, (vector_shuffle v2f32Reg:$src1, v2f32Reg:$src2, (build_vector imm:$c1, imm:$c2))) Table gen barfs about type inference contradiction for build_vector. What am I doing wrong and how can I achieve converting to the aforesaid machine instruction? Thanks, Manjunath From hc2428 at columbia.edu Mon May 18 21:21:40 2009 From: hc2428 at columbia.edu (hc2428 at columbia.edu) Date: Mon, 18 May 2009 22:21:40 -0400 Subject: [LLVMdev] How to get line number and source file name for IR? Message-ID: <20090518222140.vzid1uqiy2og8gwk@cubmail.cc.columbia.edu> Dear Staff, I am asking this question: given a line of IR code in *.ll file, how can I know the corresponding line number and C/C++ source file name for this IR code? I am investigating some code patterns with LLVM IR, I need to know where this IR code come from (the line number in a source file name). An existing way is using -g option to compile my software, then I can get something as below: call void @llvm.dbg.stoppoint(i32 9, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit17 to { }*)) I know that the first argument is line number, and the third argument, the compile unit llvm.dbg.compile_unit17, is mapped to a source file. I can get the first line number very easily by "CallSite::arg_iterator" (and represent the first argument with class ConstantInt). However, I do not know how to represent the "{ }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit17 to { }*)" in LLVM source code. Moreover, do we have a better way to achieve the line number and source file name without the "-g" option? Thanks, Heming From xi.wang at gmail.com Mon May 18 21:34:37 2009 From: xi.wang at gmail.com (Xi Wang) Date: Mon, 18 May 2009 22:34:37 -0400 Subject: [LLVMdev] How to get line number and source file name for IR? In-Reply-To: <20090518222140.vzid1uqiy2og8gwk@cubmail.cc.columbia.edu> References: <20090518222140.vzid1uqiy2og8gwk@cubmail.cc.columbia.edu> Message-ID: check llvm/Analysis/DebugInfo.h (for -g). On Mon, May 18, 2009 at 10:21 PM, wrote: > Dear Staff, > ? ? I am asking this question: given a line of IR code in *.ll file, > how can I know the corresponding line number and C/C++ source file > name for this IR code? > ? ? I am investigating some code patterns with LLVM IR, I need to > know where this IR code come from (the line number in a source file > name). > ? ? An existing way is using -g option to compile my software, then I > can get something as below: > call void @llvm.dbg.stoppoint(i32 9, i32 0, { }* bitcast > (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit17 to { }*)) > > ? ? I know that the first argument is line number, and the third > argument, the compile unit llvm.dbg.compile_unit17, is mapped to a > source file. I can get the first line number very easily by > "CallSite::arg_iterator" (and represent the first argument with class > ConstantInt). However, I do not know how to represent the "{ }* > bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit17 to { > }*)" in LLVM source code. > ? ? Moreover, do we have a better way to achieve the line number and > source file name without the "-g" option? > > Thanks, > Heming > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From dnmh68 at hotmail.com Mon May 18 22:33:02 2009 From: dnmh68 at hotmail.com (dan mihai) Date: Tue, 19 May 2009 03:33:02 +0000 Subject: [LLVMdev] how to get a deterministic execution Message-ID: Hello, For debugging purposes, I've added a unique id member to the Value class: global_next_vuid = 0; Value::Value(..){ vuid = ++global_next_vuid; } My hope is that by looking at the vuid of a Value, I can see its vuid, set a conditional breakpoint and re-run the compiler to see who (what pass) constructed that value. Maybe I am not doing it the right way, but the above 'vuid' field doesn't seem to be updated deterministically. I am using a DEBUG built. Is LLVM multithreaded by default? Is it possible to get a deterministic behavior? Thank you, Dan _________________________________________________________________ Hotmail? goes with you. http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090519/4ef51a34/attachment.html From me22.ca at gmail.com Mon May 18 23:49:08 2009 From: me22.ca at gmail.com (me22) Date: Mon, 18 May 2009 21:49:08 -0700 Subject: [LLVMdev] IDE for llvm In-Reply-To: <4f5edbea0905181326q611feb9cn760294c14adae9fa@mail.gmail.com> References: <4f5edbea0905181326q611feb9cn760294c14adae9fa@mail.gmail.com> Message-ID: 2009/5/18 Rotem Varon : > I am new in the "Linux?business" and i need to add an?optimization?to the > LLVM compiler. > I would like to know what is the bast way to debug (IDE) the LLVM compiler ? > To be more?precise, ?what is the?equivalent?to?Microsoft?visual studio on > Linux platform? is it?eclipse? > I want features like: syntax?highlight, go to def, etc. > I don't know how the features compare, but I tried monodevelop a bit ago and found it worth considering. From viridia at gmail.com Mon May 18 23:56:49 2009 From: viridia at gmail.com (Talin) Date: Mon, 18 May 2009 21:56:49 -0700 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A110ED2.6060809@lip6.fr> References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> Message-ID: <4A123C11.80709@gmail.com> Nicolas Geoffray wrote: > Hi Talin, > > You're not using the llvm intrinsics for exception handling, so your > code won't work. Using _Unwind_RaiseException should be OK, but your > main function must at least use llvm.eh.exception, > llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. > Let me ask a follow-up question then - if the llvm.eh.* intrinsics are required to define the landing pad, then what is the role of the "unwind" target in the invoke instruction? According to the docs, the unwind target defines where execution will jump to when the called function returns with an exception, but clearly that isn't true - the flow of control passes directly to the personality function, bypassing the unwind target completely (as far as I can tell). By using the llvm.eh* intrinsics, I have managed to get the code to call my custom personality function without crashing. However, what I don't yet understand is how to get the result from the personality function back to the landing pad. For example, I could use the function _Unwind_SetIP to tell it where to jump to, except that I can't take the address of a label in LLVM. I could call _Unwind_SetGR to set an index and then have a switch in the landing pad that uses that index - except that I would have no way to determine which register is safe to set in a platform-independent way. I could even just have the personality function do nothing at all, and have the landing pad do all the work - except that if my personality function doesn't do anything, then the landing pad is skipped entirely, and control resumes at the non-unwind target of the original invoke instruction, as if no exception had been thrown at all. > Nicolas > > > Talin wrote: > >> I've been struggling for several days, trying to get native exceptions >> to work in my code. I managed to boil down the IR to the simplest >> possible example that I can think of. >> >> If anyone on this list can tell me what changes I need to make to the >> following code to get it to work (i.e. return 0 instead of a bus >> error), it would make my life immensely better. >> >> ; ModuleID = 'ExceptionTest' >> %Object = type {} >> %UnwindInfo = type { i64, void (i32, %UnwindInfo *)*, i16, i16 } >> %Throwable = type { %Object, %UnwindInfo } >> >> define i32 @main(i32, i8**) nounwind { >> entry: >> invoke fastcc void @throwSomething() to label %nounwind unwind >> label %catch >> >> catch: >> ret i32 0 >> >> nounwind: >> ret i32 -1 >> } >> >> define internal fastcc void @throwSomething() noreturn { >> entry: >> %throwable = malloc %Throwable >> call fastcc void @Throwable.construct(%Throwable* %throwable) >> %unwindInfo = getelementptr %Throwable* %throwable, i32 0, i32 1 >> %throw = call i32 @_Unwind_RaiseException(%UnwindInfo* >> %unwindInfo) >> unreachable >> } >> >> define internal fastcc void @Throwable.construct(%Throwable* %self) >> nounwind { >> entry: >> %exceptionClass = getelementptr %Throwable* %self, i32 0, i32 1, >> i32 0 >> store i64 0, i64* %exceptionClass >> %exceptionCleanup = getelementptr %Throwable* %self, i32 0, i32 >> 1, i32 1 >> store void (i32, %UnwindInfo *)* @exceptionCleanupFn, void (i32, >> %UnwindInfo *)** %exceptionCleanup >> %private1 = getelementptr %Throwable* %self, i32 0, i32 1, i32 2 >> store i16 0, i16* %private1 >> %private2 = getelementptr %Throwable* %self, i32 0, i32 1, i32 3 >> store i16 0, i16* %private2 >> ret void >> } >> >> define internal void @exceptionCleanupFn(i32 %reason, %UnwindInfo * >> %exc) { >> ret void >> } >> >> declare i32 @_Unwind_RaiseException(%UnwindInfo*) noreturn >> >> -- Talin >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From anton at korobeynikov.info Tue May 19 00:38:10 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 19 May 2009 09:38:10 +0400 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A123C11.80709@gmail.com> References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> Message-ID: Hello, Talin > By using the llvm.eh* intrinsics, I have managed to get the code to call > my custom personality function without crashing. However, what I don't > yet understand is how to get the result from the personality function > back to the landing pad. You might find this useful: http://www.codesourcery.com/public/cxx-abi/abi-eh.html#cxx-catch -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From nicholas at mxc.ca Tue May 19 01:03:42 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Mon, 18 May 2009 23:03:42 -0700 Subject: [LLVMdev] SSI in LLVM In-Reply-To: <4A0DA605.3020501@dcc.ufmg.br> References: <4A0DA605.3020501@dcc.ufmg.br> Message-ID: <4A124BBE.4090805@mxc.ca> Andre Tavares wrote: > Dear LLVM Community, > > I am one of the summer of coders working on LLVM this year. My > project is to implement the ABCD algorithm for array bounds checking, > and also a bitwidth analysis that maps variables to an approximation of > its size in bits. To implement this, I will have to simulate a > intermediate representation called SSI (Static Single Information) form > on top of LLVM SSA representation. The SSI form has the property that > each use of a variable post-dominates its definition. Also, if there are > two uses of the same variable, say, u(v1) and u(v2), then, either u(v1) > dominates u(v2) or vice-versa. > > I would like to discuss my approach with you guys, so that you can > redirect me if I am going through a bad path, so I am listing some > points below: > > 1) I want to implement a very modular design. In this way, I will have > an analysis that receives the intervals produced by > LiveIntervalAnalysis, plus a list of variables, and creates a new set of > intervals, so that each interval designates a new virtual variable, that > is visible only inside my analysis. These variables have the SSI > property. In this way, it is possible to map constraints such as (a > > 10) to an interval. > > 2) Each client gives to my analysis the variables that it wants mapped > to SSI. For instance, the ABCD client passes all the variables that are > used as indexes of arrays, or as array sizes. A pass to eliminate dead > code passes all the variables used inside conditionals, and the pass > that does bitwidth analysis passes all the variables of type int, for > instance. > > 3) This implies that each client will have to traverse the program > representation harvesting the variables of interest. My analysis will > take care of simulating the SSI representation for those variables. LLVM's pass system does a good job of forcing you into having a modular design. The two relevant choices are these: * make it an analysis pass. The pass works by studying the IR and building up an in-memory model of the information it wants to represent. Passes that want to access this information have to declare that they need it to the PassManager and then ask for the FooAnalysisPass* when running and query it through its public interface. If another pass wants use this info and also change the IR, it needs to either invalidate the analysis or update it through the public interface. For an example of this, see LoopInfo. * make it a transformation pass. The pass works by modifying the IR such that it maintains a certain property (for example, "there is exactly one exit block"). Passes which require the property declare it to the PassManager then they either declare that they will also preserve the property or it is assumed that they don't. A good example of this is LCSSA. In either case a series of passes will be constructed such that the required analysis/properties are available when needed and not needlessly recomputed in between. I happen to agree with Eli that it would be better to do the "SSI as unary PHI nodes" trick (which LCSSA already does, by the way) than to make the users of this data request it for each interesting variable, but I don't have any solid experience here so I can be persuaded either way. > 4) Queries can be made given an instruction index, as computed by > LiveIntervalAnalysis. For instance, a typical query would be: is a > x > at program point 110. That's a query you'd ask of ABCD not an SSI analysis. > 5) Keeping the intervals ordered, we can answer queries in O(ln N), > where N is the maximal program index. How are they numbered anyway? > I would like to have critics on this approach so it can be well thought > before implementation to reduce reimplementation. In particular, to use > this technique, my analysis must work at the MachineFunction level, as > it must run after LiveIntervalAnalysis. Do I miss essential information > at this level, compared to the Function level? I mean, is it possible to > analysis conditionals to discover things like a > 10, or a == 10, etc? I don't know if there's anything stopping you from porting LiveIntervalAnalysis from working on both Function and MachineFunction like loop strength reduction does. It'd probably be hard. Nick > Please, feel free to ask me any clarification you may think about. I > would really appreciate any comments and thoughts you guys may have. From viridia at gmail.com Tue May 19 01:20:24 2009 From: viridia at gmail.com (Talin) Date: Mon, 18 May 2009 23:20:24 -0700 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> Message-ID: <4A124FA8.10405@gmail.com> Anton Korobeynikov wrote: > Hello, Talin > > >> By using the llvm.eh* intrinsics, I have managed to get the code to call >> my custom personality function without crashing. However, what I don't >> yet understand is how to get the result from the personality function >> back to the landing pad. >> > You might find this useful: > http://www.codesourcery.com/public/cxx-abi/abi-eh.html#cxx-catch > I've been reading that. But what's not clear is how to translate that into LLVM-speak. For example, what value would you pass to _Unwind_SetIP? -- Talin From evan.cheng at apple.com Tue May 19 01:54:08 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 18 May 2009 23:54:08 -0700 Subject: [LLVMdev] TableGen pattern In-Reply-To: <68c4c3e20905181829k6435e8ecm39be7538aac9aa1e@mail.gmail.com> References: <68c4c3e20905181829k6435e8ecm39be7538aac9aa1e@mail.gmail.com> Message-ID: <4DE0A8D3-3399-4DB4-B9FC-BF8BB7CBA5D5@apple.com> What version of llvm are you using? ISD::VECTOR_SHUFFLE node has changed so the shuffle mask is no longer explicit operands. Rather it's now part of the ShuffleVectorSDNode class. Evan On May 18, 2009, at 6:29 PM, Manjunath Kudlur wrote: > Hello, > > I am trying to convert the subtree (vector_shuffle v2f32, v2f32 > (build_vector imm1, imm2)) to a machine instruction that takes 2 > v2f32's and 2 immediates. I tried the following table gen pattern : > > (set v2f32Reg:$dst, (vector_shuffle v2f32Reg:$src1, v2f32Reg:$src2, > (build_vector > imm:$c1, imm:$c2))) > > Table gen barfs about type inference contradiction for build_vector. > What am I doing wrong and how can I achieve converting to the > aforesaid machine instruction? > > Thanks, > Manjunath > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From marc at bruenink.de Tue May 19 02:04:52 2009 From: marc at bruenink.de (=?ISO-8859-15?Q?Marc_Br=FCnink?=) Date: Tue, 19 May 2009 09:04:52 +0200 Subject: [LLVMdev] Transforming Loops Message-ID: <4A125A14.5070504@bruenink.de> Hi all, I need to transform loops like this one for (int i = b; i References: <4A125A14.5070504@bruenink.de> Message-ID: On Tue, May 19, 2009 at 12:04 AM, Marc Br?nink wrote: > Hi all, > > I need to transform loops like this one > for (int i = b; i > into loops like this one: > for(p=buffer+b; p > Does any pass already perform this? If there's none, I guess loop-reduce > is a good starting point for me, isn't it? I don't think any pass does this at the moment, but loop-reduce could easily be extended to do something like that. Make sure you're using trunk so you get SCEVs for pointers. -Eli From nicholas at mxc.ca Tue May 19 02:32:38 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Tue, 19 May 2009 00:32:38 -0700 Subject: [LLVMdev] memory lifetime and invariance In-Reply-To: References: Message-ID: <4A126096.9060803@mxc.ca> Chris Lattner wrote: > FYI, I wrote up some thoughts on this here: > http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt > > The intention is to allow front-ends to express things like "I know > this memory is a constant in this region" and to allow the optimizer/ > codegen to perform more aggressive stack slot merging. Very nice! Why does @llvm.invariant.end restate the size when it already takes the call to @llvm.invariant.start as its first argument? Did you really mean to allow for the case where part of an object is still invariant and part isn't? If so, isn't it missing an offset as well? Nick From jay.foad at gmail.com Tue May 19 02:44:26 2009 From: jay.foad at gmail.com (Jay Foad) Date: Tue, 19 May 2009 08:44:26 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN In-Reply-To: <949959A0F8C447379618527FF772CCC3@HPLAPTOP> References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com> <01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com> <6917E04590514A27BAE0BFC1F0394428@HPLAPTOP> <3B15CFBE-898B-44A7-8F4E-D2C74930355E@apple.com> <949959A0F8C447379618527FF772CCC3@HPLAPTOP> Message-ID: > Do you mean it does not build or does build ? It does build. Sorry if I was unclear. Thanks, Jay. From baldrick at free.fr Tue May 19 03:36:49 2009 From: baldrick at free.fr (Duncan Sands) Date: Tue, 19 May 2009 10:36:49 +0200 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A123C11.80709@gmail.com> References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> Message-ID: <4A126FA1.3010108@free.fr> Talin wrote: > Nicolas Geoffray wrote: >> Hi Talin, >> >> You're not using the llvm intrinsics for exception handling, so your >> code won't work. Using _Unwind_RaiseException should be OK, but your >> main function must at least use llvm.eh.exception, >> llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. >> > Let me ask a follow-up question then - if the llvm.eh.* intrinsics are > required to define the landing pad, then what is the role of the > "unwind" target in the invoke instruction? They are not required to define a landing pad. They are currently required by the code generators. The interpreter works fine without them for example. The current design is pretty horrible: the dwarf eh intrinsics were tacked on to the pre-existing invoke-unwind scheme, and it shows. Anyway, I plan to teach the code generators that if no personality function was specified then it should use the C personality function (yes, there is one). This is probably good enough for simple cases such as running cleanups. According to the docs, the > unwind target defines where execution will jump to when the called > function returns with an exception, but clearly that isn't true - the > flow of control passes directly to the personality function, bypassing > the unwind target completely (as far as I can tell). The language description describes how it is supposed to work. It simply hasn't been implemented yet in the code generator. Obviously some code is necessarily executed by the run-time when an exception is thrown, to unwind the stack etc. You should think of the personality function as part of the runtime. > By using the llvm.eh* intrinsics, I have managed to get the code to call > my custom personality function without crashing. However, what I don't > yet understand is how to get the result from the personality function > back to the landing pad. For example, I could use the function > _Unwind_SetIP to tell it where to jump to, except that I can't take the > address of a label in LLVM. I could call _Unwind_SetGR to set an index > and then have a switch in the landing pad that uses that index - except > that I would have no way to determine which register is safe to set in a > platform-independent way. I could even just have the personality > function do nothing at all, and have the landing pad do all the work - > except that if my personality function doesn't do anything, then the > landing pad is skipped entirely, and control resumes at the non-unwind > target of the original invoke instruction, as if no exception had been > thrown at all. I would just use the C personality function, __gcc_personality_v0, if I were you. It should know where to jump to because the code generators record the invoke unwind target in the dwarf exception handling info in the object file. Ciao, Duncan. >> Nicolas >> >> >> Talin wrote: >> >>> I've been struggling for several days, trying to get native exceptions >>> to work in my code. I managed to boil down the IR to the simplest >>> possible example that I can think of. >>> >>> If anyone on this list can tell me what changes I need to make to the >>> following code to get it to work (i.e. return 0 instead of a bus >>> error), it would make my life immensely better. >>> >>> ; ModuleID = 'ExceptionTest' >>> %Object = type {} >>> %UnwindInfo = type { i64, void (i32, %UnwindInfo *)*, i16, i16 } >>> %Throwable = type { %Object, %UnwindInfo } >>> >>> define i32 @main(i32, i8**) nounwind { >>> entry: >>> invoke fastcc void @throwSomething() to label %nounwind unwind >>> label %catch >>> >>> catch: >>> ret i32 0 >>> >>> nounwind: >>> ret i32 -1 >>> } >>> >>> define internal fastcc void @throwSomething() noreturn { >>> entry: >>> %throwable = malloc %Throwable >>> call fastcc void @Throwable.construct(%Throwable* %throwable) >>> %unwindInfo = getelementptr %Throwable* %throwable, i32 0, i32 1 >>> %throw = call i32 @_Unwind_RaiseException(%UnwindInfo* >>> %unwindInfo) >>> unreachable >>> } >>> >>> define internal fastcc void @Throwable.construct(%Throwable* %self) >>> nounwind { >>> entry: >>> %exceptionClass = getelementptr %Throwable* %self, i32 0, i32 1, >>> i32 0 >>> store i64 0, i64* %exceptionClass >>> %exceptionCleanup = getelementptr %Throwable* %self, i32 0, i32 >>> 1, i32 1 >>> store void (i32, %UnwindInfo *)* @exceptionCleanupFn, void (i32, >>> %UnwindInfo *)** %exceptionCleanup >>> %private1 = getelementptr %Throwable* %self, i32 0, i32 1, i32 2 >>> store i16 0, i16* %private1 >>> %private2 = getelementptr %Throwable* %self, i32 0, i32 1, i32 3 >>> store i16 0, i16* %private2 >>> ret void >>> } >>> >>> define internal void @exceptionCleanupFn(i32 %reason, %UnwindInfo * >>> %exc) { >>> ret void >>> } >>> >>> declare i32 @_Unwind_RaiseException(%UnwindInfo*) noreturn >>> >>> -- Talin >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From aph at redhat.com Tue May 19 04:43:22 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 May 2009 10:43:22 +0100 Subject: [LLVMdev] llvm-java In-Reply-To: <4A11979D.5030607@lip6.fr> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> Message-ID: <4A127F3A.2070906@redhat.com> Nicolas Geoffray wrote: > Andrew Haley wrote: >> Right, so that part should be trivial. So, does the array bounds check >> elimination already work? If it does, that will considerably reduce >> the work that Andre needs to do. To say the least... >> >> > > Trivial bounds check elimination already work, such as tab[2] = 1; > tab[1] = 2 (the second affectation won't have a bounds checks). Although > I don't know the details, I believe Andre also targets less trivial > eliminations. I should have asked a better question. By "does it work" I meant something like for (int i = 0; i < a.length; i++) System.out.println(a[i]); in which the autogenerated check should trivially be removed, but only if LLVM knows that a.length is invariant. Andrew. From Aleksey.Loginov at gmail.com Tue May 19 02:07:02 2009 From: Aleksey.Loginov at gmail.com (night beast) Date: Tue, 19 May 2009 00:07:02 -0700 (PDT) Subject: [LLVMdev] multi-threading Message-ID: <05006c6d-6c02-41b6-92da-611e68da7b3f@o14g2000vbo.googlegroups.com> Are there any plans for support multi-threading in the core IR? From clattner at apple.com Tue May 19 05:00:52 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 19 May 2009 03:00:52 -0700 Subject: [LLVMdev] memory lifetime and invariance In-Reply-To: <4A126096.9060803@mxc.ca> References: <4A126096.9060803@mxc.ca> Message-ID: On May 19, 2009, at 12:32 AM, Nick Lewycky wrote: > Chris Lattner wrote: >> FYI, I wrote up some thoughts on this here: >> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >> >> The intention is to allow front-ends to express things like "I know >> this memory is a constant in this region" and to allow the optimizer/ >> codegen to perform more aggressive stack slot merging. > > Very nice! > > Why does @llvm.invariant.end restate the size when it already takes > the > call to @llvm.invariant.start as its first argument? Did you really > mean > to allow for the case where part of an object is still invariant and > part isn't? If so, isn't it missing an offset as well? It is basically because the invariant.start may not be the immediate operand of the invariant.end. You may end up having phi nodes connecting the two when various phi translation cases occur. -Chris From aph at redhat.com Tue May 19 05:01:32 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 May 2009 11:01:32 +0100 Subject: [LLVMdev] llvm-java In-Reply-To: <4A127F3A.2070906@redhat.com> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> Message-ID: <4A12837C.3060107@redhat.com> Andrew Haley wrote: > Nicolas Geoffray wrote: >> Andrew Haley wrote: >>> Right, so that part should be trivial. So, does the array bounds check >>> elimination already work? If it does, that will considerably reduce >>> the work that Andre needs to do. To say the least... >>> >>> >> Trivial bounds check elimination already work, such as tab[2] = 1; >> tab[1] = 2 (the second affectation won't have a bounds checks). Although >> I don't know the details, I believe Andre also targets less trivial >> eliminations. > > I should have asked a better question. By "does it work" I meant something > like > > for (int i = 0; i < a.length; i++) > System.out.println(a[i]); > > in which the autogenerated check should trivially be removed, but only if > LLVM knows that a.length is invariant. Oh, I forgot to mention that a.length should be hoisted into a register as it's loop invariant. Andrew. From nicolas.geoffray at lip6.fr Tue May 19 05:27:10 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 19 May 2009 12:27:10 +0200 Subject: [LLVMdev] llvm-java In-Reply-To: <4A127F3A.2070906@redhat.com> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> Message-ID: <4A12897E.2080507@lip6.fr> Andrew Haley wrote: > > I should have asked a better question. By "does it work" I meant something > like > > for (int i = 0; i < a.length; i++) > System.out.println(a[i]); > OK, so no :) VMKit does not know that a[i] is related to a.length. I believe Andre's optimizations will take care of that. Nicolas From Dr.Graef at t-online.de Tue May 19 07:00:58 2009 From: Dr.Graef at t-online.de (Albert Graef) Date: Tue, 19 May 2009 14:00:58 +0200 Subject: [LLVMdev] -fPIC troubles on Linux x86 (32 bit) Message-ID: <4A129F7A.5020502@t-online.de> Hi all, I noticed that now that --enable-pic is the default in svn, there's also some logic in Makefiles.rules to eliminate -fPIC for the case of mingw and cygwin: ifeq ($(ENABLE_PIC),1) ifeq ($(OS), $(filter $(OS), Cygwin MingW)) # Nothing. Win32 defaults to PIC and warns when given -fPIC else ... I would suggest that it should be done this way (i.e., eliminating -fPIC) not only for win32, but for all 32 bit x86 systems. Or has anyone seen any kind of x86 system where the -fPIC is indeed required? The problem with using -fPIC on x86 is not only the speed of the generated code, I also get JIT-related segfaults in the Pure interpreter (on Linux). See, e.g.: http://code.google.com/p/pure-lang/issues/detail?id=9 (That specific bug report relates to the Ubuntu Jaunty LLVM 2.5 package, which is (mis)configured with --enable-pic on all architectures including x86. But the issue is exactly the same with current svn, as has been reported for various different x86 Linux systems by other Pure users. The segfaults go away if LLVM is compiled with --disable-pic on x86. I don't have a minimal test example, but I'm pretty sure that the bug is in LLVM, not in the Pure interpreter, as the interpreter passes its test suite just fine if LLVM is compiled with --disable-pic.) Note that -fPIC is *not* required to build shared libraries on 32 bit x86, in fact AFAICT it's recommended to *not* use -fPIC there. The workaround is obvious: we just tell users to build LLVM with --disable-pic on x86 systems (and to avoid broken binary x86 packages like the one in Jaunty). But of course it would make things easier for packagers and end users if this worked out of the box. Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From torvald at se.inf.tu-dresden.de Tue May 19 07:02:09 2009 From: torvald at se.inf.tu-dresden.de (Torvald Riegel) Date: Tue, 19 May 2009 14:02:09 +0200 Subject: [LLVMdev] llvm-gcc on OpenSolaris for SPARC In-Reply-To: <4A11A17B.7000004@cs.uiuc.edu> References: <4A11A17B.7000004@cs.uiuc.edu> Message-ID: <200905191402.10207.torvald@se.inf.tu-dresden.de> On Monday 18 May 2009, John Criswell wrote: > Dear All, > > Is anyone using llvm-gcc and LLVM on OpenSolaris compiling for the SPARC > architecture? I see that it's listed under supported platforms, but I > don't see a pre-built llvm-gcc front-end for it. > > I know someone here at Illinois that needs it, but I'd like to know if > compiling llvm-gcc is likely to work before I try it. If it works, could you post instructions or make the binary available (if there is anything special to be done)? Thanks! Torvald From aph at redhat.com Tue May 19 07:29:45 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 May 2009 13:29:45 +0100 Subject: [LLVMdev] -fPIC troubles on Linux x86 (32 bit) In-Reply-To: <4A129F7A.5020502@t-online.de> References: <4A129F7A.5020502@t-online.de> Message-ID: <4A12A639.3070007@redhat.com> Albert Graef wrote: > I noticed that now that --enable-pic is the default in svn, there's also > some logic in Makefiles.rules to eliminate -fPIC for the case of mingw > and cygwin: > > ifeq ($(ENABLE_PIC),1) > ifeq ($(OS), $(filter $(OS), Cygwin MingW)) > # Nothing. Win32 defaults to PIC and warns when given -fPIC > else > ... > > I would suggest that it should be done this way (i.e., eliminating > -fPIC) not only for win32, but for all 32 bit x86 systems. Or has anyone > seen any kind of x86 system where the -fPIC is indeed required? It's not strictly required, as the runtime system will fix them up, but of course the fixed-up parts of the "shared libraries" are no longer shared, which rather defeats the point. > The problem with using -fPIC on x86 is not only the speed of the > generated code, I also get JIT-related segfaults in the Pure interpreter > (on Linux). See, e.g.: > > http://code.google.com/p/pure-lang/issues/detail?id=9 > > (That specific bug report relates to the Ubuntu Jaunty LLVM 2.5 package, > which is (mis)configured with --enable-pic on all architectures > including x86. But the issue is exactly the same with current svn, as > has been reported for various different x86 Linux systems by other Pure > users. The segfaults go away if LLVM is compiled with --disable-pic on > x86. I don't have a minimal test example, but I'm pretty sure that the > bug is in LLVM, not in the Pure interpreter, as the interpreter passes > its test suite just fine if LLVM is compiled with --disable-pic.) > > Note that -fPIC is *not* required to build shared libraries on 32 bit > x86, in fact AFAICT it's recommended to *not* use -fPIC there. That's not true for Fedora, where non-PIC shared libraries will fail rpmlint and SELinux may (depending on how it's configured) refuse to load them. The real solution is to fix the bug. Andrew. From gbenson at redhat.com Tue May 19 07:40:19 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 19 May 2009 13:40:19 +0100 Subject: [LLVMdev] -fPIC troubles on Linux x86 (32 bit) In-Reply-To: <4A129F7A.5020502@t-online.de> References: <4A129F7A.5020502@t-online.de> Message-ID: <20090519124019.GE3155@redhat.com> Albert Graef wrote: > Hi all, > > I noticed that now that --enable-pic is the default in svn, there's > also some logic in Makefiles.rules to eliminate -fPIC for the case > of mingw and cygwin: > > ifeq ($(ENABLE_PIC),1) > ifeq ($(OS), $(filter $(OS), Cygwin MingW)) > # Nothing. Win32 defaults to PIC and warns when given -fPIC > else > ... > > I would suggest that it should be done this way (i.e., eliminating > -fPIC) not only for win32, but for all 32 bit x86 systems. Or has > anyone seen any kind of x86 system where the -fPIC is indeed > required? > > The problem with using -fPIC on x86 is not only the speed of the > generated code, I also get JIT-related segfaults in the Pure > interpreter (on Linux). See, e.g.: > > http://code.google.com/p/pure-lang/issues/detail?id=9 > > (That specific bug report relates to the Ubuntu Jaunty LLVM 2.5 > package, which is (mis)configured with --enable-pic on all > architectures including x86. But the issue is exactly the same with > current svn, as has been reported for various different x86 Linux > systems by other Pure users. The segfaults go away if LLVM is > compiled with --disable-pic on x86. I don't have a minimal test > example, but I'm pretty sure that the bug is in LLVM, not in the > Pure interpreter, as the interpreter passes its test suite just fine > if LLVM is compiled with --disable-pic.) > > Note that -fPIC is *not* required to build shared libraries on 32 > bit x86, in fact AFAICT it's recommended to *not* use -fPIC > there. The workaround is obvious: we just tell users to build LLVM > with --disable-pic on x86 systems (and to avoid broken binary x86 > packages like the one in Jaunty). But of course it would make things > easier for packagers and end users if this worked out of the box. I'm not sure if it's specifically required on 32-bit x86 (and I don't have a machine lying around to test it on) but certainly on PowerPC you cannot link other shared libraries with LLVM unless you build LLVM with --enable-pic because parts of LLVM end up statically linked into the library that's linked with LLVM (there are ordinary object files listed in `llvm_config --libs`). If something is crashing in Pure/LLVM when LLVM is built with --enable-pic then surely the correct solution is to find and fix the crash, not to silently remove compiler options on certain platforms. If someone builds LLVM with --enable-pic then presumably they wanted it... Cheers, Gary -- http://gbenson.net/ From anton at korobeynikov.info Tue May 19 08:03:46 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 19 May 2009 17:03:46 +0400 Subject: [LLVMdev] -fPIC troubles on Linux x86 (32 bit) In-Reply-To: <4A129F7A.5020502@t-online.de> References: <4A129F7A.5020502@t-online.de> Message-ID: Hello, Everyone > Note that -fPIC is *not* required to build shared libraries on 32 bit > x86, in fact AFAICT it's recommended to *not* use -fPIC there. The > workaround is obvious: we just tell users to build LLVM with > --disable-pic on x86 systems (and to avoid broken binary x86 packages > like the one in Jaunty). The problem is pretty easy: nobody cared about loading GOT pointer to ebx before doing a call via PLT. The initial patch for this was x86-64 only (and I explicitly mentioned that it won't work on x86-32 due to this issue). Unfortunately, it was commited as-is and later when PIC was enabled by default this subtle bug appeared... The proper solution will be to conditionalize for x86-32 linux and assemble a proper call sequence via PLT. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From anton at korobeynikov.info Tue May 19 08:04:54 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 19 May 2009 17:04:54 +0400 Subject: [LLVMdev] -fPIC troubles on Linux x86 (32 bit) In-Reply-To: <4A129F7A.5020502@t-online.de> References: <4A129F7A.5020502@t-online.de> Message-ID: Albert, > The problem with using -fPIC on x86 is not only the speed of the > generated code, I also get JIT-related segfaults in the Pure interpreter > (on Linux). See, e.g.: Please fill a PR in the LLVM bugzilla, so this issue won't get lost. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From andrelct at dcc.ufmg.br Tue May 19 10:19:40 2009 From: andrelct at dcc.ufmg.br (Andre Tavares) Date: Tue, 19 May 2009 12:19:40 -0300 Subject: [LLVMdev] llvm-java In-Reply-To: <4A12897E.2080507@lip6.fr> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> Message-ID: <4A12CE0C.6050907@dcc.ufmg.br> Nicolas Geoffray wrote: > Andrew Haley wrote: > >> I should have asked a better question. By "does it work" I meant something >> like >> >> for (int i = 0; i < a.length; i++) >> System.out.println(a[i]); >> >> > > OK, so no :) VMKit does not know that a[i] is related to a.length. I > believe Andre's optimizations will take care of that. > > Nicolas > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > Thanks for all answers. I will consider them all before I start coding. I have another discussion that I would like to hear from you. I can implement SSI in two different ways. Analysis or Transformation Pass. As an Analysis Pass, I would create a SSI LiveInterval, mapping each interval with a constraint. Pros: No change to the IR. Cons: It is a simulation. As an Transformation Pass, SSI would be implemented in the IR with copy instructions (pi functions) and phi functions on the end. Pros: Real SSI. Each interval has a constraint. Cons: IR is bigger, what can impact other optimizations. What do you think? -- Andre Tavares Master Student in Computer Science - UFMG - Brasil http://dcc.ufmg.br/~andrelct From nicolas.geoffray at lip6.fr Tue May 19 10:59:36 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 19 May 2009 17:59:36 +0200 Subject: [LLVMdev] llvm-java In-Reply-To: <4A12CE0C.6050907@dcc.ufmg.br> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> Message-ID: <4A12D768.3010006@lip6.fr> Hi Andre? Andre Tavares wrote: > Thanks for all answers. I will consider them all before I start coding. > > I have another discussion that I would like to hear from you. > > I can implement SSI in two different ways. Analysis or Transformation Pass. > > As an Analysis Pass, I would create a SSI LiveInterval, mapping each > interval with a constraint. > Pros: No change to the IR. > Cons: It is a simulation. > It is a simulation == bad performance? > As an Transformation Pass, SSI would be implemented in the IR with copy > instructions (pi functions) and phi functions on the end. > Pros: Real SSI. Each interval has a constraint. > Cons: IR is bigger, what can impact other optimizations. > > How would you model this pi function? New instruction? New intrinsic? Nicolas From viridia at gmail.com Tue May 19 11:20:02 2009 From: viridia at gmail.com (Talin) Date: Tue, 19 May 2009 09:20:02 -0700 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A126FA1.3010108@free.fr> References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> <4A126FA1.3010108@free.fr> Message-ID: <4A12DC32.80206@gmail.com> Duncan Sands wrote: > I would just use the C personality function, __gcc_personality_v0, if > I were you. It should know where to jump to because the code generators > record the invoke unwind target in the dwarf exception handling info in > the object file. > > I see. OK, I will try that. I was hoping to be able to test the exception type in the personality function - the language I am working on has its own type system, unrelated to C or C++, so I want to minimize reliance on C++ exception handling libraries. In this case, I guess I can do the exception type checking in the landing pad instead of the personality function. -- Talin From andrelct at dcc.ufmg.br Tue May 19 11:38:32 2009 From: andrelct at dcc.ufmg.br (Andre Tavares) Date: Tue, 19 May 2009 13:38:32 -0300 Subject: [LLVMdev] llvm-java In-Reply-To: <4A12D768.3010006@lip6.fr> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> Message-ID: <4A12E088.30100@dcc.ufmg.br> Nicolas Geoffray wrote: > Hi Andre? > > Andre Tavares wrote: > >> Thanks for all answers. I will consider them all before I start coding. >> >> I have another discussion that I would like to hear from you. >> >> I can implement SSI in two different ways. Analysis or Transformation Pass. >> >> As an Analysis Pass, I would create a SSI LiveInterval, mapping each >> interval with a constraint. >> Pros: No change to the IR. >> Cons: It is a simulation. >> >> > > It is a simulation == bad performance? > > >> As an Transformation Pass, SSI would be implemented in the IR with copy >> instructions (pi functions) and phi functions on the end. >> Pros: Real SSI. Each interval has a constraint. >> Cons: IR is bigger, what can impact other optimizations. >> >> >> > > How would you model this pi function? New instruction? New intrinsic? > > Nicolas > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > Nicolas, I think the performance of my Pass will be the same independent of which type I use. But if I make transformations I will reduce the performance of other optimizations. The pi functions can be implemented with copy instructions. This way it won't change other optimizations. Example: a1, a2 = pi(a) into a1 = a a2 = a -- Andre Tavares Master Student in Computer Science - UFMG - Brasil http://dcc.ufmg.br/~andrelct From nicolas.geoffray at lip6.fr Tue May 19 11:45:17 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 19 May 2009 18:45:17 +0200 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A12DC32.80206@gmail.com> References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> <4A126FA1.3010108@free.fr> <4A12DC32.80206@gmail.com> Message-ID: <4A12E21D.6020406@lip6.fr> Talin wrote: > I see. OK, I will try that. > > I was hoping to be able to test the exception type in the personality > function - the language I am working on has its own type system, > unrelated to C or C++, so I want to minimize reliance on C++ exception > handling libraries. In this case, I guess I can do the exception type > checking in the landing pad instead of the personality function. > Yes, that's what VMKit used to do, until it realized dwarf exceptions should never be used for something like Java :) Nicolas > -- Talin > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From Dr.Graef at t-online.de Tue May 19 12:08:58 2009 From: Dr.Graef at t-online.de (Albert Graef) Date: Tue, 19 May 2009 19:08:58 +0200 Subject: [LLVMdev] -fPIC troubles on Linux x86 (32 bit) In-Reply-To: References: <4A129F7A.5020502@t-online.de> Message-ID: <4A12E7AA.2000002@t-online.de> Anton Korobeynikov wrote: >> The problem with using -fPIC on x86 is not only the speed of the >> generated code, I also get JIT-related segfaults in the Pure interpreter >> (on Linux). See, e.g.: > Please fill a PR in the LLVM bugzilla, so this issue won't get lost. Will do. Thanks for the explanation! -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From aaronngray.lists at googlemail.com Tue May 19 12:30:51 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Tue, 19 May 2009 18:30:51 +0100 Subject: [LLVMdev] [Cygwin] bug on SVN References: <9719867c0905151103o325d9ac5g758df1f5cd400255@mail.gmail.com><01A96761-E854-46D3-8E2B-1C32B2188D3B@apple.com><6917E04590514A27BAE0BFC1F0394428@HPLAPTOP><3B15CFBE-898B-44A7-8F4E-D2C74930355E@apple.com><949959A0F8C447379618527FF772CCC3@HPLAPTOP> Message-ID: <239209A49F454F6DA52982B3C143F589@HPLAPTOP> >> Do you mean it does not build or does build ? > > It does build. Sorry if I was unclear. Builds here fine too. Thanks Doug, Aaron From isanbard at gmail.com Tue May 19 12:59:35 2009 From: isanbard at gmail.com (Bill Wendling) Date: Tue, 19 May 2009 10:59:35 -0700 Subject: [LLVMdev] how to get a deterministic execution In-Reply-To: References: Message-ID: <16e5fdf90905191059o61b08dc5g7d9eda64804e4430@mail.gmail.com> On Mon, May 18, 2009 at 8:33 PM, dan mihai wrote: > Hello, > Yo! > For debugging purposes, I've added a unique id member to the Value class: > > global_next_vuid = 0; > Value::Value(..){ > ? vuid = ++global_next_vuid; > } > > My hope is that by looking at the vuid of a Value, I can see its vuid, > set a conditional breakpoint and re-run the compiler to > see who (what pass) constructed that value. > > Maybe I am not doing it the right way, but the above 'vuid' field doesn't > seem > to be updated deterministically. > We'd need a testcase to see what you mean...I'm not entirely sure that what you're doing will work, though. > I am using a DEBUG built. Is LLVM multithreaded by default? > No. LLVM isn't multithreaded safe just yet. > Is it possible to get a deterministic behavior? > The code that's generated should be completely deterministic. -bw From dnmh68 at hotmail.com Tue May 19 13:47:42 2009 From: dnmh68 at hotmail.com (dan mihai) Date: Tue, 19 May 2009 18:47:42 +0000 Subject: [LLVMdev] how to get a deterministic execution In-Reply-To: <16e5fdf90905191059o61b08dc5g7d9eda64804e4430@mail.gmail.com> References: <16e5fdf90905191059o61b08dc5g7d9eda64804e4430@mail.gmail.com> Message-ID: The generated code is deterministic, but the global order the instructions were generated seems it is not (although the result is guaranteed to be the same). Now I think the order functions are processed might not be guaranteed. I've attached a test case, and here is what I get: ............................... (303)$ ~/bin/llvm/bin/gcc -O3 -emit-llvm try_calls_basic.2.c -c -o try_calls_basic2.bc (304)$ $LLVM/opt -O3 -IR-DUMP :ALL -load ~/download/llvm-objects/Debug/lib/LLVMHello.so -hello -debug-pass Structure < try_calls_basic2.bc > try_calls_basic2.2.bc 2> x1 (305)$ $LLVM/opt -O3 -IR-DUMP :ALL -load ~/download/llvm-objects/Debug/lib/LLVMHello.so -hello -debug-pass Structure < try_calls_basic2.bc > try_calls_basic2.2.bc 2> x2 (306)$ diff x1 x2|more 237c237 < %0 = tail call i32 (...)* %pf() nounwind ; [#uses=0] {vuid=69} --- > %0 = tail call i32 (...)* %pf() nounwind ; [#uses=0] {vuid=56} .................................... (The -IR-DUMP :ALL is a debugging option I use, that dumps the IR after each function pass in FPPassManager::runOnFunction) The vuid are different (69!=56). In fact a closer examination shows that the 56-th Value in the first case is an instruction in main, while in the 2nd case is an instruction in a different function. My particular issue is that I want to see when the following instruction is created: %pf1.0 = select i1 %0, i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i32 (...)* bitcast (i32 ()* @pointed_to_function2 to i32 (...)*) ; [#uses=2] {vuid=67} So, I assume it is the 67-th Value, set a conditional breakpoint and restart the program. But this fails, because the second time it is the 55-th value created: %pf1.0 = select i1 %0, i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i32 (...)* bitcast (i32 ()* @pointed_to_function2 to i32 (...)*) ; [#uses=2] {vuid=55} The issues seems to go away, if I remove all other functions from the file and only keep the function I am interested in. Thank you, Daniel > Date: Tue, 19 May 2009 10:59:35 -0700 > From: isanbard at gmail.com > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] how to get a deterministic execution > > On Mon, May 18, 2009 at 8:33 PM, dan mihai wrote: > > Hello, > > > Yo! > > > For debugging purposes, I've added a unique id member to the Value class: > > > > global_next_vuid = 0; > > Value::Value(..){ > > vuid = ++global_next_vuid; > > } > > > > My hope is that by looking at the vuid of a Value, I can see its vuid, > > set a conditional breakpoint and re-run the compiler to > > see who (what pass) constructed that value. > > > > Maybe I am not doing it the right way, but the above 'vuid' field doesn't > > seem > > to be updated deterministically. > > > We'd need a testcase to see what you mean...I'm not entirely sure that > what you're doing will work, though. > > > I am using a DEBUG built. Is LLVM multithreaded by default? > > > No. LLVM isn't multithreaded safe just yet. > > > Is it possible to get a deterministic behavior? > > > The code that's generated should be completely deterministic. > > -bw > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev _________________________________________________________________ Insert movie times and more without leaving Hotmail?. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090519/380e56f5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: try_calls_basic.2.c Type: text/x-csrc Size: 593 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090519/380e56f5/attachment.bin From resistor at mac.com Tue May 19 14:30:56 2009 From: resistor at mac.com (Owen Anderson) Date: Tue, 19 May 2009 14:30:56 -0500 Subject: [LLVMdev] how to get a deterministic execution In-Reply-To: References: <16e5fdf90905191059o61b08dc5g7d9eda64804e4430@mail.gmail.com> Message-ID: <30669736832466944299935139025131241978-Webmail@me.com> There are a number of places in the optimizers where instructions are held in sets or maps by pointer value, which is non-deterministic. While the final output has to be the same in all cases, there are several places where iterations are accelerated by using non-deterministic iteration orders. As long as the same final end result is produced, this is allowed. --Owen On Tuesday, May 19, 2009, at 01:47PM, "dan mihai" wrote: > >The generated code is deterministic, but the global order the instructions were generated >seems it is not (although the result is guaranteed to be the same). >Now I think the order functions are processed might not be guaranteed. >I've attached a test case, and here is what I get: >............................... > (303)$ ~/bin/llvm/bin/gcc -O3 -emit-llvm try_calls_basic.2.c -c -o try_calls_basic2.bc > (304)$ $LLVM/opt -O3 -IR-DUMP :ALL -load ~/download/llvm-objects/Debug/lib/LLVMHello.so -hello -debug-pass Structure < try_calls_basic2.bc > try_calls_basic2.2.bc 2> x1 > (305)$ $LLVM/opt -O3 -IR-DUMP :ALL -load ~/download/llvm-objects/Debug/lib/LLVMHello.so -hello -debug-pass Structure < try_calls_basic2.bc > try_calls_basic2.2.bc 2> x2 > (306)$ diff x1 x2|more >237c237 >< %0 = tail call i32 (...)* %pf() nounwind ; [#uses=0] {vuid=69} >--- >> %0 = tail call i32 (...)* %pf() nounwind ; [#uses=0] {vuid=56} >.................................... >(The -IR-DUMP :ALL is a debugging option I use, that dumps the IR after each function pass in FPPassManager::runOnFunction) > >The vuid are different (69!=56). >In fact a closer examination shows that the 56-th Value in the first case is >an instruction in main, while in the 2nd case is an instruction in a different function. > >My particular issue is that I want to see when the following instruction is created: > %pf1.0 = select i1 %0, i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i32 (...)* bitcast (i32 ()* @pointed_to_function2 to i32 (...)*) ; [#uses=2] {vuid=67} > >So, I assume it is the 67-th Value, set a conditional breakpoint and restart the program. >But this fails, because the second time it is the 55-th value created: > %pf1.0 = select i1 %0, i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i32 (...)* bitcast (i32 ()* @pointed_to_function2 to i32 (...)*) ; [#uses=2] {vuid=55} > > >The issues seems to go away, if I remove all other functions from the file and only keep the function I am interested in. > >Thank you, >Daniel > > >> Date: Tue, 19 May 2009 10:59:35 -0700 >> From: isanbard at gmail.com >> To: llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] how to get a deterministic execution >> >> On Mon, May 18, 2009 at 8:33 PM, dan mihai wrote: >> > Hello, >> > >> Yo! >> >> > For debugging purposes, I've added a unique id member to the Value class: >> > >> > global_next_vuid = 0; >> > Value::Value(..){ >> > vuid = ++global_next_vuid; >> > } >> > >> > My hope is that by looking at the vuid of a Value, I can see its vuid, >> > set a conditional breakpoint and re-run the compiler to >> > see who (what pass) constructed that value. >> > >> > Maybe I am not doing it the right way, but the above 'vuid' field doesn't >> > seem >> > to be updated deterministically. >> > >> We'd need a testcase to see what you mean...I'm not entirely sure that >> what you're doing will work, though. >> >> > I am using a DEBUG built. Is LLVM multithreaded by default? >> > >> No. LLVM isn't multithreaded safe just yet. >> >> > Is it possible to get a deterministic behavior? >> > >> The code that's generated should be completely deterministic. >> >> -bw >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >_________________________________________________________________ >Insert movie times and more without leaving Hotmail?. >http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009 From nicolas.geoffray at lip6.fr Tue May 19 14:30:58 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Tue, 19 May 2009 21:30:58 +0200 Subject: [LLVMdev] llvm-java In-Reply-To: <4A12E088.30100@dcc.ufmg.br> References: <4A117A36.8030504@dcc.ufmg.br> <903165.44062.qm@web62003.mail.re1.yahoo.com> <4A118260.9010305@redhat.com> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> Message-ID: <4A1308F2.7070905@lip6.fr> Hi Andre, Andre Tavares wrote: > Nicolas, > > I think the performance of my Pass will be the same independent of which > type I use. But if I make transformations I will reduce the performance > of other optimizations. > > I don't get it. What is the cons then of a simulation? > The pi functions can be implemented with copy instructions. Store instructions? > This way it > won't change other optimizations. > > Why would the analysis change other optimizations? > Example: > a1, a2 = pi(a) into > a1 = a > a2 = a > > OK, so your pass/analysis creates the stores? Why do you need to introduce the pi name? (Btw, I have no knowledge on SSI/SSA construction theories, so maybe I need a higher-level explanation of the problem) Thanks, Nicolas From eli.friedman at gmail.com Tue May 19 15:40:13 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 19 May 2009 13:40:13 -0700 Subject: [LLVMdev] llvm-java In-Reply-To: <4A1308F2.7070905@lip6.fr> References: <4A117A36.8030504@dcc.ufmg.br> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> <4A1308F2.7070905@lip6.fr> Message-ID: On Tue, May 19, 2009 at 12:30 PM, Nicolas Geoffray wrote: >> The pi functions can be implemented with copy instructions. > > Store instructions? I would assume something more like "select i1 true, %val, undef". -Eli From viridia at gmail.com Tue May 19 16:48:29 2009 From: viridia at gmail.com (Talin) Date: Tue, 19 May 2009 14:48:29 -0700 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A12E21D.6020406@lip6.fr> References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> <4A126FA1.3010108@free.fr> <4A12DC32.80206@gmail.com> <4A12E21D.6020406@lip6.fr> Message-ID: On Tue, May 19, 2009 at 9:45 AM, Nicolas Geoffray wrote: > Talin wrote: >> I see. OK, I will try that. >> >> I was hoping to be able to test the exception type in the personality >> function - the language I am working on has its own type system, >> unrelated to C or C++, so I want to minimize reliance on C++ exception >> handling libraries. In this case, I guess I can do the exception type >> checking in the landing pad instead of the personality function. >> > > Yes, that's what VMKit used to do, until it realized dwarf exceptions > should never be used for something like Java :) Can you elaborate on that last point a bit? What problems did you run into? -- Talin From resistor at mac.com Tue May 19 20:06:52 2009 From: resistor at mac.com (Owen Anderson) Date: Tue, 19 May 2009 18:06:52 -0700 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> <4A126FA1.3010108@free.fr> <4A12DC32.80206@gmail.com> <4A12E21D.6020406@lip6.fr> Message-ID: On May 19, 2009, at 2:48 PM, Talin wrote: > On Tue, May 19, 2009 at 9:45 AM, Nicolas Geoffray > wrote: >> Talin wrote: >> >> Yes, that's what VMKit used to do, until it realized dwarf exceptions >> should never be used for something like Java :) > > Can you elaborate on that last point a bit? What problems did you > run into? DWARF exceptions (aka zero-cost exceptions) are optimized to be efficient when no exceptions are thrown. They're not efficient at all when exceptions are thrown, so they tend to be a poor match for languages like Java where exceptions are relatively common. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090519/7a8451d6/attachment.bin From nicholas at mxc.ca Tue May 19 21:58:47 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Tue, 19 May 2009 19:58:47 -0700 Subject: [LLVMdev] memory lifetime and invariance In-Reply-To: References: <4A126096.9060803@mxc.ca> Message-ID: <4A1371E7.8070602@mxc.ca> Chris Lattner wrote: > On May 19, 2009, at 12:32 AM, Nick Lewycky wrote: > >> Chris Lattner wrote: >>> FYI, I wrote up some thoughts on this here: >>> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >>> >>> The intention is to allow front-ends to express things like "I know >>> this memory is a constant in this region" and to allow the optimizer/ >>> codegen to perform more aggressive stack slot merging. >> Very nice! >> >> Why does @llvm.invariant.end restate the size when it already takes >> the >> call to @llvm.invariant.start as its first argument? Did you really >> mean >> to allow for the case where part of an object is still invariant and >> part isn't? If so, isn't it missing an offset as well? > > It is basically because the invariant.start may not be the immediate > operand of the invariant.end. You may end up having phi nodes > connecting the two when various phi translation cases occur. The verifier rejects phi nodes of {} type. Do you actually have a case where you want this to happen? Nick From nicholas at mxc.ca Tue May 19 22:15:31 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Tue, 19 May 2009 20:15:31 -0700 Subject: [LLVMdev] llvm-java In-Reply-To: References: <4A117A36.8030504@dcc.ufmg.br> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> <4A1308F2.7070905@lip6.fr> Message-ID: <4A1375D3.9000101@mxc.ca> Eli Friedman wrote: > On Tue, May 19, 2009 at 12:30 PM, Nicolas Geoffray > wrote: >>> The pi functions can be implemented with copy instructions. >> Store instructions? > > I would assume something more like "select i1 true, %val, undef". %x = phi [%val, %predbb]. Nick From viridia at gmail.com Tue May 19 23:00:59 2009 From: viridia at gmail.com (Talin) Date: Tue, 19 May 2009 21:00:59 -0700 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A126FA1.3010108@free.fr> References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> <4A126FA1.3010108@free.fr> Message-ID: <4A13807B.4090809@gmail.com> Duncan Sands wrote: > I would just use the C personality function, __gcc_personality_v0, if > I were you. It should know where to jump to because the code generators > record the invoke unwind target in the dwarf exception handling info in > the object file. > > So I tried what you suggested, and it just gives me a bus error: define i32 @main(i32, i8**) nounwind { entry: call void @print(i8* bitcast ([6 x i8]* @str_begin to i8 *)) invoke fastcc void @throwSomething() to label %nounwind unwind label %catch; catch: %eh_ptr = call i8* @llvm.eh.exception(); %eh_select34 = call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32 ( i8* %eh_ptr, i8* bitcast (i32 (i32, i32, i64, i8*, %UnwindContext*)* @__gcc_personality_v0 to i8*), i32 1) call void @print(i8* bitcast ([6 x i8]* @str_catch to i8 *)) ret i32 0 nounwind: call void @print(i8* bitcast ([8 x i8]* @str_nocatch to i8 *)) ret i32 -1 } However, when I use my own personality function instead of __gcc_personality_v0, it doesn't crash, but it doesn't work right either (for reasons we've already discussed - it doesn't know how to redirect the execution to the landing pad): @str_persn = internal constant [10 x i8] c"persn %d\0a\00" define i32 @personality_func(i32 %version, i32 %action, i64 %eh_class, i8* %eh_ptr, %UnwindContext* %eh_context) nounwind { call void (i8*, ...)* @printf(i8* bitcast ([10 x i8]* @str_persn to i8*), i32 %action) %phase = icmp eq i32 %action, 1 br i1 %phase, label %search, label %handler search: ret i32 6 handler: call void @_Unwind_SetIP(%UnwindContext* %eh_context, i8* %cc0) ret i32 7 } -- Talin From resistor at mac.com Tue May 19 23:00:49 2009 From: resistor at mac.com (Owen Anderson) Date: Tue, 19 May 2009 21:00:49 -0700 Subject: [LLVMdev] llvm-java In-Reply-To: <4A1375D3.9000101@mxc.ca> References: <4A117A36.8030504@dcc.ufmg.br> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> <4A1308F2.7070905@lip6.fr> <4A1375D3.9000101@mxc.ca> Message-ID: <6B1B0792-0355-4E52-A031-1EE8FAA43EEF@mac.com> On May 19, 2009, at 8:15 PM, Nick Lewycky wrote: > Eli Friedman wrote: >> On Tue, May 19, 2009 at 12:30 PM, Nicolas Geoffray >> wrote: >>>> The pi functions can be implemented with copy instructions. >>> Store instructions? >> >> I would assume something more like "select i1 true, %val, >> undef". > > %x = phi [%val, %predbb]. FWIW, I strongly recommend going this direction. It'll buy you a lot of free functionality, like replaceAllUsesWith(). --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090519/be073130/attachment.bin From nicolas.geoffray at lip6.fr Wed May 20 01:56:38 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Wed, 20 May 2009 08:56:38 +0200 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> <4A126FA1.3010108@free.fr> <4A12DC32.80206@gmail.com> <4A12E21D.6020406@lip6.fr> Message-ID: <4A13A9A6.4070208@lip6.fr> Owen Anderson wrote: > DWARF exceptions (aka zero-cost exceptions) are optimized to be > efficient when no exceptions are thrown. They're not efficient at all > when exceptions are thrown, so they tend to be a poor match for > languages like Java where exceptions are relatively common. Exactly. For instance, VMKit completes the exception-intensive jack benchmark (http://www.spec.org/jvm98/) in 60 seconds with Dwarf exceptions, and in 10 seconds with exception checks after each call. On applications with no exceptions, the exception check code does not cost that much (maybe 1 or 2%). Nicolas From baldrick at free.fr Wed May 20 02:15:02 2009 From: baldrick at free.fr (Duncan Sands) Date: Wed, 20 May 2009 09:15:02 +0200 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A13807B.4090809@gmail.com> References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> <4A126FA1.3010108@free.fr> <4A13807B.4090809@gmail.com> Message-ID: <4A13ADF6.3070606@free.fr> Hi Talin, > So I tried what you suggested, and it just gives me a bus error: > %eh_select34 = call i32 (i8*, i8*, ...)* > @llvm.eh.selector.i32 ( > i8* %eh_ptr, > i8* bitcast (i32 (i32, i32, i64, i8*, %UnwindContext*)* > @__gcc_personality_v0 to i8*), > i32 1) try changing i32 1 to i32 0. Also, feel free to send me something I can compile, and I will try it here. Ciao, Duncan. From viridia at gmail.com Wed May 20 03:17:46 2009 From: viridia at gmail.com (Talin) Date: Wed, 20 May 2009 01:17:46 -0700 Subject: [LLVMdev] Getting exceptions to work? In-Reply-To: <4A13ADF6.3070606@free.fr> References: <4A110611.6000303@gmail.com> <4A110ED2.6060809@lip6.fr> <4A123C11.80709@gmail.com> <4A126FA1.3010108@free.fr> <4A13807B.4090809@gmail.com> <4A13ADF6.3070606@free.fr> Message-ID: <4A13BCAA.7040901@gmail.com> Duncan Sands wrote: > Hi Talin, > >> So I tried what you suggested, and it just gives me a bus error: >> >> %eh_select34 = call i32 (i8*, i8*, ...)* >> @llvm.eh.selector.i32 ( >> i8* %eh_ptr, >> i8* bitcast (i32 (i32, i32, i64, i8*, %UnwindContext*)* >> @__gcc_personality_v0 to i8*), >> i32 1) >> > > try changing i32 1 to i32 0. Also, feel free to send me something > I can compile, and I will try it here. > File attached. I compile and run with: llvm-as -f ExTest.ll && llc -f ExTest.bc && gcc -g -o ExTest ExTest.s && ./ExTest -- Talin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ExTest.ll Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090520/f569013e/attachment.pl From Christian.Sayer at dibcom.fr Wed May 20 04:05:37 2009 From: Christian.Sayer at dibcom.fr (Christian Sayer) Date: Wed, 20 May 2009 11:05:37 +0200 Subject: [LLVMdev] memory access optimizations Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4AFA7EFF5E18@FRPAR1CL009.coe.adi.dibcom.com> Hello all, I had an issue with instcombine. from TargetLowering.cpp (SimplifySetCC()): > // If the LHS is '(and load, const)', the RHS is 0, > // the test is for equality or unsigned, and all 1 bits of the const are > // in the same partial word, see if we can shorten the load. to make it short, a little pseudo-code example: %res = (load i16* addr) and (0x100) becomes %res = (load i8* addr+1) and (0x1) Since my target is not byte-addressable (yes, I have been warned : ), this does not work for me. So this is just to ask anybody who might know offhand about other places where this byte-addressability assumption may be an issue to drop me a line, so I can have a look at it in the first place. So far I have covered obvoius things like the backend and TargetData for StructLayout, therefore I would be particularly interested in anything which typically does not directly concern backend development. Thank you, Christian -- CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you. From scubed at nostratic.lingcog.iit.edu Wed May 20 01:50:39 2009 From: scubed at nostratic.lingcog.iit.edu (S3) Date: Tue, 19 May 2009 23:50:39 -0700 Subject: [LLVMdev] Appending globals In-Reply-To: <480FEFAF.2080608@gmail.com> References: <47F30D5F.5070806@gmail.com> <47F31E7F.6050003@uiuc.edu> <480FEFAF.2080608@gmail.com> Message-ID: <4A13A83F.1090304@lingcog.iit.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I tried to write a simple program to use appending globals to get a feel for how they work. (See attached.) I intend it to print out: x! y! z! in any order. However, when I compile it, I get ... %lt = icmp ult i32 %counter, udiv (i32 sub (i32 ptrtoint ([1 x %0]* getelementptr ([1 x %0]* bitcast ([3 x %0]* @abc to [1 x %0]*), i32 1) to i32), i32 ptrtoint ([3 x %0]* @abc to i32)), i32 sub (i32 ptrtoint (%0* getelementptr ([3 x %0]* @abc, i32 0, i32 1) to i32), i32 ptrtoint ([3 x %0]* @abc to i32))) ; [#uses=1] ... The part to note is that all of them become [3 x %0]*, except the first is bitcast to [1 x %0]*. I was trying to determine the length by doing sizeof(x)/sizeof(x[0]), as recommended in the documentation. But, that extra bitcast breaks it, causing it to only print: x! Is this bitcast intentional? If so, is there a way to determine the length? It seems that doing %abcnext = getelementptr [1 x {i32, void()*}]* @abc, i32 1 %abcnexti = ptrtoint [1 x {i32, void()*}]* %abcnext to i32 should get the pointer to after @abc, not the pointer to what was the end of it in just that file. It seems like a bug. - -- ++++++++++++[->+++++++>+++++++++<<]>-.>[->+>+>+>+>+ <<<<<]>++++++++.>-------.<--.>>.---.>++.>-----.>+++ +++++[->++++<]>.<<<<<<<<.>>++.>.>.>.>>++++++++++. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoTqD4ACgkQxzVgPqtIcftr6ACfeMrzJltwET6s+MPN48XhERaA 30cAnjRsBTK/g48+NW50AiKrLCjoTMWm =0srC -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a.ll Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090519/b6b6f55f/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: b.ll Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090519/b6b6f55f/attachment-0001.pl From wim at fixnum.org Wed May 20 04:20:04 2009 From: wim at fixnum.org (Wim Vander Schelden) Date: Wed, 20 May 2009 02:20:04 -0700 (PDT) Subject: [LLVMdev] LLVM-GCC and Symbian Message-ID: <95039cfe-0a3b-4587-83cc-99d45b893c6e@r34g2000vba.googlegroups.com> Hi, I noticed that there is some kind of reference to Symbian support in LLVM-GCC, and I'm trying to find out more about it. I configured llvm- gcc-4.2-2.5 using: > ../configure --prefix=/opt/stow/llvm-gcc-2.5/ --enable-llvm=/home/wim/Documents/Sources/llvm-2.5/OBJ_ROOT/ --disable-bootstrap --disable-multilib --enable-checking --target arm-none-symbianelf --enable-languages=objc,c,c++ --disable-libada At this point, everything seems to work, with the following warning coming up: > *** This configuration is not supported in the following subdirectories: > gnattools target-libmudflap target-libgomp target-libffi target-zlib target-libjava target-libiberty target-libada target-libgfortran zlib target-boehm-gc > (Any other directories should still work fine.) But when I try to build, I get the following error message: > gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -I/home/wim/Documents/Sources/llvm-2.5/OBJ_ROOT//include -I/home/wim/Documents/Sources/llvm-2.5/include -DENABLE_LLVM -I/home/wim/Documents/Sources/llvm-2.5/OBJ_ROOT/../include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -o build/gencondmd.o build/gencondmd.c > ../../gcc/config/arm/arm.md:4788: error: ?MACHO_DYNAMIC_NO_PIC_P? undeclared here (not in a function) > ../../gcc/config/arm/arm.md:4789: warning: missing initializer > ../../gcc/config/arm/arm.md:4789: warning: (near initialization for ?insn_conditions[15].value?) > ../../gcc/config/arm/arm.md:4703: warning: missing initializer > ../../gcc/config/arm/arm.md:4703: warning: (near initialization for ?insn_conditions[56].value?) > ../../gcc/config/arm/arm.md:4789: warning: missing initializer > ../../gcc/config/arm/arm.md:4789: warning: (near initialization for ?insn_conditions[86].value?) > gmake[2]: *** [build/gencondmd.o] Error 1 > gmake[2]: Leaving directory `/home/wim/Documents/Sources/llvm-gcc4.2-2.5/OBJ_ROOT/gcc' > gmake[1]: *** [all-gcc] Error 2 > gmake[1]: Leaving directory `/home/wim/Documents/Sources/llvm-gcc4.2-2.5/OBJ_ROOT' > gmake: *** [all] Error 2 I was wondering if this is because of the Symbian target or just a universal ARM issue. Also, since I find so little about Symbian and LLVM support, is there any chance for LLVM to actually build working Symbian binaries? Kind regards, Wim From anton at korobeynikov.info Wed May 20 06:13:23 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 20 May 2009 15:13:23 +0400 Subject: [LLVMdev] LLVM-GCC and Symbian In-Reply-To: <95039cfe-0a3b-4587-83cc-99d45b893c6e@r34g2000vba.googlegroups.com> References: <95039cfe-0a3b-4587-83cc-99d45b893c6e@r34g2000vba.googlegroups.com> Message-ID: Hello, >> ../../gcc/config/arm/arm.md:4788: error: ?MACHO_DYNAMIC_NO_PIC_P? undeclared here (not in a function) This is well-known apple-local thing. Please consider building from top of the tree. > I was wondering if this is because of the Symbian target or just a > universal ARM issue. This is common ARM issue for non-darwin targets. > Also, since I find so little about Symbian and LLVM support, is there > any chance for LLVM to actually build working Symbian binaries? I think the answer is pretty obvious :) I haven't heard about somebody even tried symbian stuff. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From fernando at CS.UCLA.EDU Wed May 20 07:48:56 2009 From: fernando at CS.UCLA.EDU (Fernando Magno Quintao Pereira) Date: Wed, 20 May 2009 05:48:56 -0700 (PDT) Subject: [LLVMdev] llvm-java In-Reply-To: <6B1B0792-0355-4E52-A031-1EE8FAA43EEF@mac.com> References: <4A117A36.8030504@dcc.ufmg.br> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> <4A1308F2.7070905@lip6.fr> <4A1375D3.9000101@mxc.ca> <6B1B0792-0355-4E52-A031-1EE8FAA43EEF@mac.com> Message-ID: Hi, Nicolas, I have been talking to Andre about this project. Let me add my two cents: > I don't get it. What is the cons then of a simulation? The tradeoff, IMHO, is as follows: simulation: it does not add instructions to LLVM IR. Instead, it builds an interval representation for each variable. Each interval represents a variable in SSI form, and will be associated to one or more constraints, like v > 10, or v > a.length. A query will have to find the variable, O(1), and then its interval, O(ln #intervals). transformation: it replaces a variable with new variables that have the SSI property. In this case, it must add copies and new phi-functions into LLVM IR. Queries are now O(1): just find the variable and recover the constraints. The downside is that it increases the program size. > Why would the analysis change other optimizations? The transformation may slow down other analysis/optimizations because they will have to deal with more instructions. For instance, there will be more copies that the coalescer will have to take into consideration. > OK, so your pass/analysis creates the stores? Why do you need to introduce the pi name? Well, you do not really introduce the pi name. That is an abstraction. In the case of simulation, you have a black box that creates intervals for each variable that must be converted to SSI. In the case of the transformation, you emulate pi-functions with copies (or other instructions of similar semantics). > (Btw, I have no knowledge on SSI/SSA construction theories, so maybe I need a higher-level explanation of the problem) Basically, in (strict) SSA form, you have the property that each definition dominates each use of a variable. In SSI, on the other hand, you have the property that each use post-dominates its definition. That is, any path from the end of the program to the definition of a variable v goes across all the uses of v. This requires pi (also called sigma) functions, which are the duals of phi-functions. If a phi-function is like a multiplexer, a pi-function is like a demux: (a1:B1, a2:B2) := pi(a) copies 'a' into a1 if the execution flows to block B1, and copies a into a2 otherwise. Compare with a := phi (a1:B1, a2:B2). LLVM has no pi function, so it must be simulated with copies. At the beginning of B1, a1 := a, and at the beginning of B2, a2 := a. Fernando From nicolas.geoffray at lip6.fr Wed May 20 08:51:54 2009 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Wed, 20 May 2009 15:51:54 +0200 Subject: [LLVMdev] llvm-java In-Reply-To: References: <4A117A36.8030504@dcc.ufmg.br> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> <4A1308F2.7070905@lip6.fr> <4A1375D3.9000101@mxc.ca> <6B1B0792-0355-4E52-A031-1EE8FAA43EEF@mac.com> Message-ID: <4A140AFA.20405@lip6.fr> Hi Fernando, Thanks for the very clear explanation. Fernando Magno Quintao Pereira wrote: > simulation: it does not add instructions to LLVM IR. Instead, it builds an > interval representation for each variable. Each interval represents a > variable in SSI form, and will be associated to one or more constraints, > like v > 10, or v > a.length. A query will have to find the variable, > O(1), and then its interval, O(ln #intervals). > > transformation: it replaces a variable with new variables that have the > SSI property. In this case, it must add copies and new phi-functions into > LLVM IR. Queries are now O(1): just find the variable and recover the > constraints. The downside is that it increases the program size. > OK. Is it possible to do SSI Transformation --> Array Bounds Optimization --> SSI undo Transformation? Or would that render useless the speed gained with O(1) queries? I think the LLVM philosophy is to favor O(1) queries, and the SSI is probably not increasing the program size that much. Besides, if we can undo, that's the approach I'd recommend. Thanks, Nicolas From criswell at uiuc.edu Wed May 20 10:05:39 2009 From: criswell at uiuc.edu (John Criswell) Date: Wed, 20 May 2009 09:05:39 -0600 Subject: [LLVMdev] llvm-java In-Reply-To: <4A140AFA.20405@lip6.fr> References: <4A117A36.8030504@dcc.ufmg.br> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> <4A1308F2.7070905@lip6.fr> <4A1375D3.9000101@mxc.ca> <6B1B0792-0355-4E52-A031-1EE8FAA43EEF@mac.com> <4A140AFA.20405@lip6.fr> Message-ID: <4A141C43.3070103@uiuc.edu> Dear All, Perhaps a related issue is whether SSI form is valuable for other transformations or analysis passes. If it is, then it might be worth building general SSA->SSI and SSI->SSA transforms so that any LLVM pass wishing to have the code in SSI form can do so. -- John T. Nicolas Geoffray wrote: > [snip] > > OK. Is it possible to do SSI Transformation --> Array Bounds > Optimization --> SSI undo Transformation? Or would that render useless > the speed gained with O(1) queries? > > I think the LLVM philosophy is to favor O(1) queries, and the SSI is > probably not increasing the program size that much. Besides, if we can > undo, that's the approach I'd recommend. > > Thanks, > Nicolas > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From andrewl at lenharth.org Wed May 20 11:25:11 2009 From: andrewl at lenharth.org (Andrew Lenharth) Date: Wed, 20 May 2009 11:25:11 -0500 Subject: [LLVMdev] memory lifetime and invariance In-Reply-To: References: Message-ID: <85dfcd7f0905200925k3cf8650bp4bfe851905b45f58@mail.gmail.com> On Mon, May 18, 2009 at 3:02 PM, Chris Lattner wrote: > FYI, I wrote up some thoughts on this here: > http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt > > The intention is to allow front-ends to express things like "I know > this memory is a constant in this region" and to allow the optimizer/ > codegen to perform more aggressive stack slot merging. It seems no more prone to abuse to reserve an address space for const memory. Within a const region, all pointers to the const data are in the const address space. So rather than starting with a intrinsic, you start with a ptrcast. This would also make checking trivial stores to const regions easy in the verifier. Andrew From fernando at CS.UCLA.EDU Wed May 20 12:04:38 2009 From: fernando at CS.UCLA.EDU (Fernando Magno Quintao Pereira) Date: Wed, 20 May 2009 10:04:38 -0700 (PDT) Subject: [LLVMdev] llvm-java In-Reply-To: <4A141C43.3070103@uiuc.edu> References: <4A117A36.8030504@dcc.ufmg.br> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> <4A1308F2.7070905@lip6.fr> <4A1375D3.9000101@mxc.ca> <6B1B0792-0355-4E52-A031-1EE8FAA43EEF@mac.com> <4A140AFA.20405@lip6.fr> <4A141C43.3070103@uiuc.edu> Message-ID: It is certainly useful in other optimizations: 1) Type check elimination in dynamically typed languages: if you know that i is int, then you don't have to check its type before performing integer operations on it. 2) Constant propagation: if (!i) then x = i else x = 13 => if (i) then x = 0 else x = 13 3) Bitwidth analysis: if (x < 128) then ... => if (x < 128) then "x has at most 7 bits" 4) Dead code elimination: if (x > 10) then if (x < 9) then... else S => if (x <= 10) then S etc That is why we need a modular design: a client pass gives some variables to the SSI module, which will convert those variables to SSI. Fernando > Dear All, > > Perhaps a related issue is whether SSI form is valuable for other > transformations or analysis passes. If it is, then it might be worth > building general SSA->SSI and SSI->SSA transforms so that any LLVM pass > wishing to have the code in SSI form can do so. > > -- John T. > > Nicolas Geoffray wrote: >> [snip] >> >> OK. Is it possible to do SSI Transformation --> Array Bounds >> Optimization --> SSI undo Transformation? Or would that render useless >> the speed gained with O(1) queries? >> >> I think the LLVM philosophy is to favor O(1) queries, and the SSI is >> probably not increasing the program size that much. Besides, if we can >> undo, that's the approach I'd recommend. >> >> Thanks, >> Nicolas >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From rjmccall at apple.com Wed May 20 12:25:55 2009 From: rjmccall at apple.com (John McCall) Date: Wed, 20 May 2009 10:25:55 -0700 Subject: [LLVMdev] memory lifetime and invariance In-Reply-To: <85dfcd7f0905200925k3cf8650bp4bfe851905b45f58@mail.gmail.com> References: <85dfcd7f0905200925k3cf8650bp4bfe851905b45f58@mail.gmail.com> Message-ID: <08282981-5366-4D97-9813-4202F1DB839E@apple.com> On May 20, 2009, at 9:25 AM, Andrew Lenharth wrote: > On Mon, May 18, 2009 at 3:02 PM, Chris Lattner > wrote: >> FYI, I wrote up some thoughts on this here: >> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >> >> The intention is to allow front-ends to express things like "I know >> this memory is a constant in this region" and to allow the optimizer/ >> codegen to perform more aggressive stack slot merging. > > It seems no more prone to abuse to reserve an address space for const > memory. Within a const region, all pointers to the const data are in > the const address space. So rather than starting with a intrinsic, > you start with a ptrcast. This would also make checking trivial > stores to const regions easy in the verifier. This would also make it very easy for a front-end to handle write-once data. Is there a design document about address spaces? John. From resistor at mac.com Wed May 20 12:57:49 2009 From: resistor at mac.com (Owen Anderson) Date: Wed, 20 May 2009 10:57:49 -0700 Subject: [LLVMdev] llvm-java In-Reply-To: <4A140AFA.20405@lip6.fr> References: <4A117A36.8030504@dcc.ufmg.br> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> <4A1308F2.7070905@lip6.fr> <4A1375D3.9000101@mxc.ca> <6B1B0792-0355-4E52-A031-1EE8FAA43EEF@mac.com> <4A140AFA.20405@lip6.fr> Message-ID: On May 20, 2009, at 6:51 AM, Nicolas Geoffray wrote: > Hi Fernando, > > Thanks for the very clear explanation. > > Fernando Magno Quintao Pereira wrote: >> simulation: it does not add instructions to LLVM IR. Instead, it >> builds an >> interval representation for each variable. Each interval represents a >> variable in SSI form, and will be associated to one or more >> constraints, >> like v > 10, or v > a.length. A query will have to find the variable, >> O(1), and then its interval, O(ln #intervals). >> >> transformation: it replaces a variable with new variables that have >> the >> SSI property. In this case, it must add copies and new phi- >> functions into >> LLVM IR. Queries are now O(1): just find the variable and recover the >> constraints. The downside is that it increases the program size. >> > > OK. Is it possible to do SSI Transformation --> Array Bounds > Optimization --> SSI undo Transformation? Or would that render useless > the speed gained with O(1) queries? Undoing SSI translation is just constant propagation, if you've represented the pi nodes with single-input phis/copies. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090520/092bea36/attachment.bin From resistor at mac.com Wed May 20 13:02:23 2009 From: resistor at mac.com (Owen Anderson) Date: Wed, 20 May 2009 11:02:23 -0700 Subject: [LLVMdev] llvm-java In-Reply-To: References: <4A117A36.8030504@dcc.ufmg.br> <4A118A36.9040109@lip6.fr> <4A118E67.7050508@redhat.com> <4A11979D.5030607@lip6.fr> <4A127F3A.2070906@redhat.com> <4A12897E.2080507@lip6.fr> <4A12CE0C.6050907@dcc.ufmg.br> <4A12D768.3010006@lip6.fr> <4A12E088.30100@dcc.ufmg.br> <4A1308F2.7070905@lip6.fr> <4A1375D3.9000101@mxc.ca> <6B1B0792-0355-4E52-A031-1EE8FAA43EEF@mac.com> Message-ID: On May 20, 2009, at 5:48 AM, Fernando Magno Quintao Pereira wrote: > transformation: it replaces a variable with new variables that have > the > SSI property. In this case, it must add copies and new phi-functions > into > LLVM IR. Queries are now O(1): just find the variable and recover the > constraints. The downside is that it increases the program size. It also has the benefit of being much easier to maintain across other transformations. An analysis needs to maintain global information mapping program points to whatever internal indexing it uses, so it needs to be informed about all insertions/deletions/CFG changes made in order to remain up to date. In contrast, only those registers directly impacted need to be update to preserve it in the transformation version. Also, I think the transformation version is much easier for client transformations to use. They take an SSI register, prove something true about it, and can just use replaceAllUsesWith to simplify it. A post-pass of constant propagation cleans the whole things up. This should make things like an SSI-based predicate simplifier extremely simple. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090520/ca61accc/attachment.bin From chuckr at telenix.org Wed May 20 14:19:28 2009 From: chuckr at telenix.org (Chuck Robey) Date: Wed, 20 May 2009 15:19:28 -0400 Subject: [LLVMdev] Arm port Message-ID: <4A1457C0.6000601@telenix.org> If this is the wrong list, please correct me, thanks. I'm trying to get a bit more information about the Arm backend for llvm. The precise processor I'm interested in is the TI OMAP3530 (the Cortex-A8 is the main CPU, along with other processors onboard the chip). I did see that the backend for Arm has support for the V6, but I'm thinking (I could be wrong) that the Cortex-A8 is more V7 compatible. So, I was wondering if the LLVM would be available to me for my project, and if it's not, is support for the Cortex planned. Thanks From deeppatel1987 at gmail.com Wed May 20 14:51:35 2009 From: deeppatel1987 at gmail.com (Sandeep Patel) Date: Wed, 20 May 2009 12:51:35 -0700 Subject: [LLVMdev] Arm port In-Reply-To: <4A1457C0.6000601@telenix.org> References: <4A1457C0.6000601@telenix.org> Message-ID: <305d6f60905201251r1389a9b8g2730d6b924cc597c@mail.gmail.com> I am currently working on support for the Cortex-A9, but as all compiler testing is more easily done on an Cortex-A8 today, A8 support is implicit. What specific ISA changes are you most interested in? Are you able to develop patches if we coordinate which areas to work on? deep On Wed, May 20, 2009 at 12:19 PM, Chuck Robey wrote: > If this is the wrong list, please correct me, thanks. > > I'm trying to get a bit more information about the Arm backend for llvm. ?The > precise processor I'm interested in is the TI OMAP3530 (the Cortex-A8 is the > main CPU, along with other processors onboard the chip). ?I did see that the > backend for Arm has support for the V6, but I'm thinking (I could be wrong) that > the Cortex-A8 is more V7 compatible. ?So, I was wondering if the LLVM would be > available to me for my project, and if it's not, is support for the Cortex planned. > > Thanks > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From eli.friedman at gmail.com Wed May 20 15:19:16 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 20 May 2009 13:19:16 -0700 Subject: [LLVMdev] [PATCH] Add new phase to legalization to handle vector operations Message-ID: Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) +++ lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) @@ -0,0 +1,243 @@ +//===-- LegalizeVectorOps.cpp - Implement SelectionDAG::LegalizeVectors ---===// +// +// The LLVM Compiler Infrastructure +// +// This file is distributed under the University of Illinois Open Source +// License. See LICENSE.TXT for details. +// +//===----------------------------------------------------------------------===// +// +// This file implements the SelectionDAG::LegalizeVectors method. +// +//===----------------------------------------------------------------------===// + +#include "llvm/CodeGen/SelectionDAG.h" +#include "llvm/Target/TargetLowering.h" +using namespace llvm; + +namespace { +class VectorLegalizer { + SelectionDAG& DAG; + TargetLowering& TLI; + SDValue UnrollVectorOp(SDValue Op); + SDValue PromoteVectorOp(SDValue Op); + + public: + bool Run(); + VectorLegalizer(SelectionDAG& dag) : + DAG(dag), TLI(dag.getTargetLoweringInfo()) {} +}; + +bool VectorLegalizer::Run() { + bool Changed = false; + + // The vector legalizer is a relatively simple process because it doesn't + // need to legalize everything: it just needs to catch vector operations + // which might expand to libcalls. + DAG.AssignTopologicalOrder(); + for (SelectionDAG::allnodes_iterator I = DAG.allnodes_begin(), + E = prior(DAG.allnodes_end()); I != next(E); ++I) { + bool HasVectorValue = false; + for (SDNode::value_iterator J = I->value_begin(); J != I->value_end(); ++J) + HasVectorValue |= J->isVector(); + if (!HasVectorValue) continue; + SDNode* Result = I; + switch (I->getOpcode()) { + default: + assert(I->getOpcode() > ISD::BUILTIN_OP_END && "Unexpected node!"); + break; + case ISD::UNDEF: + case ISD::FORMAL_ARGUMENTS: + case ISD::CALL: + case ISD::MERGE_VALUES: + case ISD::RET: + case ISD::VAARG: + case ISD::Register: + case ISD::INTRINSIC_WO_CHAIN: + case ISD::INTRINSIC_W_CHAIN: + case ISD::INTRINSIC_VOID: + case ISD::CopyToReg: + case ISD::CopyFromReg: + case ISD::AssertSext: + case ISD::AssertZext: + // Node cannot be illegal if types are legal + break; + case ISD::BUILD_VECTOR: + case ISD::INSERT_VECTOR_ELT: + case ISD::EXTRACT_VECTOR_ELT: + case ISD::CONCAT_VECTORS: + case ISD::EXTRACT_SUBVECTOR: + case ISD::VECTOR_SHUFFLE: + case ISD::SCALAR_TO_VECTOR: + case ISD::BIT_CONVERT: + case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could potentially generate libcalls, + // not to completely legalize vectors. Also, leaving these around + // exposes them to both custom legalization and later DAGCombines. + case ISD::ZERO_EXTEND: + case ISD::ANY_EXTEND: + case ISD::TRUNCATE: + // These don't need handling: they can't generate libcalls. + // FIXME: But it might be nice for optimization to handle them. + break; + case ISD::SIGN_EXTEND: + case ISD::VSETCC: + // FIXME: Needs handling; could concievably generate a libcall, although + // it would be unusual + break; + case ISD::ADD: + case ISD::SUB: + case ISD::MUL: + case ISD::SDIV: + case ISD::UDIV: + case ISD::SREM: + case ISD::UREM: + case ISD::FADD: + case ISD::FSUB: + case ISD::FMUL: + case ISD::FDIV: + case ISD::FREM: + case ISD::AND: + case ISD::OR: + case ISD::XOR: + case ISD::SHL: + case ISD::SRA: + case ISD::SRL: + case ISD::ROTL: + case ISD::ROTR: + case ISD::CTTZ: + case ISD::CTLZ: + case ISD::CTPOP: + case ISD::SELECT: + case ISD::SELECT_CC: + case ISD::SINT_TO_FP: + case ISD::UINT_TO_FP: + case ISD::FP_TO_SINT: + case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) { + case TargetLowering::Promote: + Result = PromoteVectorOp(SDValue(Result, 0)).getNode(); + break; + case TargetLowering::Legal: break; + case TargetLowering::Custom: { + SDValue Tmp1 = TLI.LowerOperation(SDValue(Result, 0), DAG); + if (Tmp1.getNode()) { + // FIXME: Should the returned value be recursively checked? + Result = Tmp1.getNode(); + break; + } + // FALL THROUGH + } + case TargetLowering::Expand: + // FIXME: Handle some special cases: FNEG->FSUB + Result = UnrollVectorOp(SDValue(Result, 0)).getNode(); + break; + } + break; + } + if (&*I != Result) { + Changed = true; + DAG.ReplaceAllUsesWith(I, Result); + } + } + + // Remove dead nodes now. + DAG.RemoveDeadNodes(); + + return Changed; +} + +SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { + MVT VT = Op.getValueType(); + assert(Op.getNode()->getNumValues() == 1 && + "Can't promote a vector with multiple results!"); + MVT NVT = TLI.getTypeToPromoteTo(Op.getOpcode(), VT); + DebugLoc dl = Op.getDebugLoc(); + SmallVector Operands(Op.getNumOperands()); + + for (unsigned j = 0; j != Op.getNumOperands(); ++j) { + if (Op.getOperand(j).getValueType().isVector()) + Operands[j] = DAG.getNode(ISD::BIT_CONVERT, dl, NVT, Op.getOperand(j)); + else + Operands[j] = Op.getOperand(j); + } + + Op = DAG.getNode(Op.getOpcode(), dl, NVT, &Operands[0], Operands.size()); + + return DAG.getNode(ISD::BIT_CONVERT, dl, VT, Op); +} + +/// UnrollVectorOp - We know that the given vector has a legal type, however +/// the operation it performs is not legal, and the target has requested that +/// the operation be expanded. "Unroll" the vector, splitting out the scalars +/// and operating on each element individually. +SDValue VectorLegalizer::UnrollVectorOp(SDValue Op) { + MVT VT = Op.getValueType(); + assert(Op.getNode()->getNumValues() == 1 && + "Can't unroll a vector with multiple results!"); + unsigned NE = VT.getVectorNumElements(); + MVT EltVT = VT.getVectorElementType(); + DebugLoc dl = Op.getDebugLoc(); + + SmallVector Scalars; + SmallVector Operands(Op.getNumOperands()); + for (unsigned i = 0; i != NE; ++i) { + for (unsigned j = 0; j != Op.getNumOperands(); ++j) { + SDValue Operand = Op.getOperand(j); + MVT OperandVT = Operand.getValueType(); + if (OperandVT.isVector()) { + // A vector operand; extract a single element. + MVT OperandEltVT = OperandVT.getVectorElementType(); + Operands[j] = DAG.getNode(ISD::EXTRACT_VECTOR_ELT, dl, + OperandEltVT, + Operand, + DAG.getConstant(i, MVT::i32)); + } else { + // A scalar operand; just use it as is. + Operands[j] = Operand; + } + } + + switch (Op.getOpcode()) { + default: + Scalars.push_back(DAG.getNode(Op.getOpcode(), dl, EltVT, + &Operands[0], Operands.size())); + break; + case ISD::SHL: + case ISD::SRA: + case ISD::SRL: + case ISD::ROTL: + case ISD::ROTR: + Scalars.push_back(DAG.getNode(Op.getOpcode(), dl, EltVT, Operands[0], + DAG.getShiftAmountOperand(Operands[1]))); + break; + } + } + + return DAG.getNode(ISD::BUILD_VECTOR, dl, VT, &Scalars[0], Scalars.size()); +} + +} + +bool SelectionDAG::LegalizeVectors() { + return VectorLegalizer(*this).Run(); +} Index: lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (revision 72159) +++ lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (working copy) @@ -495,7 +495,7 @@ // types here except for target constants (the type legalizer does not touch // those) or for build vector used as a mask for a vector shuffle. assert((TypesNeedLegalizing || getTypeAction(VT) == Legal || - IsLegalizingCallArgs || Op.getOpcode() == ISD::TargetConstant) && + Op.getOpcode() == ISD::TargetConstant) && "Illegal type introduced after type legalization?"); switch (getTypeAction(VT)) { default: assert(0 && "Bad type action!"); Index: lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp =================================================================== --- lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp (revision 72159) +++ lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp (working copy) @@ -611,6 +611,36 @@ DOUT << "Optimized type-legalized selection DAG:\n"; DEBUG(CurDAG->dump()); } + + if (TimePassesIsEnabled) { + NamedRegionTimer T("Vector Legalization", GroupName); + Changed = CurDAG->LegalizeVectors(); + } else { + Changed = CurDAG->LegalizeVectors(); + } + + if (Changed) { + if (TimePassesIsEnabled) { + NamedRegionTimer T("Type Legalization 2", GroupName); + Changed = CurDAG->LegalizeTypes(); + } else { + Changed = CurDAG->LegalizeTypes(); + } + + if (ViewDAGCombineLT) + CurDAG->viewGraph("dag-combine-lv input for " + BlockName); + + // Run the DAG combiner in post-type-legalize mode. + if (TimePassesIsEnabled) { + NamedRegionTimer T("DAG Combining after legalize vectors", GroupName); + CurDAG->Combine(NoIllegalOperations, *AA, OptLevel); + } else { + CurDAG->Combine(NoIllegalOperations, *AA, OptLevel); + } + + DOUT << "Optimized vector-legalized selection DAG:\n"; + DEBUG(CurDAG->dump()); + } } if (ViewLegalizeDAGs) CurDAG->viewGraph("legalize input for " + BlockName); Index: include/llvm/CodeGen/SelectionDAG.h =================================================================== --- include/llvm/CodeGen/SelectionDAG.h (revision 72159) +++ include/llvm/CodeGen/SelectionDAG.h (working copy) @@ -220,6 +220,13 @@ /// the graph. void Legalize(bool TypesNeedLegalizing, CodeGenOpt::Level OptLevel); + /// LegalizeVectors - This transforms the SelectionDAG into a SelectionDAG + /// that only uses vector operations supported by the target. + /// + /// Note that this is an involved process that may invalidate pointers into + /// the graph. + bool LegalizeVectors(); + /// RemoveDeadNodes - This method deletes all unreachable nodes in the /// SelectionDAG. void RemoveDeadNodes(); From clattner at apple.com Wed May 20 15:29:32 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 20 May 2009 13:29:32 -0700 Subject: [LLVMdev] memory lifetime and invariance In-Reply-To: <85dfcd7f0905200925k3cf8650bp4bfe851905b45f58@mail.gmail.com> References: <85dfcd7f0905200925k3cf8650bp4bfe851905b45f58@mail.gmail.com> Message-ID: <66C38C13-F693-469D-B006-FB70372BD8E7@apple.com> On May 20, 2009, at 9:25 AM, Andrew Lenharth wrote: > On Mon, May 18, 2009 at 3:02 PM, Chris Lattner > wrote: >> FYI, I wrote up some thoughts on this here: >> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >> >> The intention is to allow front-ends to express things like "I know >> this memory is a constant in this region" and to allow the optimizer/ >> codegen to perform more aggressive stack slot merging. > > It seems no more prone to abuse to reserve an address space for const > memory. Within a const region, all pointers to the const data are in > the const address space. So rather than starting with a intrinsic, > you start with a ptrcast. This would also make checking trivial > stores to const regions easy in the verifier. I don't see how this helps. Fundamentally, you have something like this: store x -> ptr load ptr ... The trick is to know that ptr does not alias the loads and stores. The further issue is that you don't know when the load is generated whether it is in the const section or not, so you couldn't bitcast its pointer operand even if you knew that. A silly C++ example is: class foo{ int ivar; foo() ... int bar() { return ivar; } }; If "bar" is called from the constructor, then the load is from a potentially varying value, if it is called from code after the constructor, it is known const (assuming the instance was declared const). -Chris From clattner at apple.com Wed May 20 15:29:54 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 20 May 2009 13:29:54 -0700 Subject: [LLVMdev] memory lifetime and invariance In-Reply-To: <4A1371E7.8070602@mxc.ca> References: <4A126096.9060803@mxc.ca> <4A1371E7.8070602@mxc.ca> Message-ID: On May 19, 2009, at 7:58 PM, Nick Lewycky wrote: > Chris Lattner wrote: >> On May 19, 2009, at 12:32 AM, Nick Lewycky wrote: >> >>> Chris Lattner wrote: >>>> FYI, I wrote up some thoughts on this here: >>>> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt >>>> >>>> The intention is to allow front-ends to express things like "I know >>>> this memory is a constant in this region" and to allow the >>>> optimizer/ >>>> codegen to perform more aggressive stack slot merging. >>> Very nice! >>> >>> Why does @llvm.invariant.end restate the size when it already takes >>> the >>> call to @llvm.invariant.start as its first argument? Did you really >>> mean >>> to allow for the case where part of an object is still invariant and >>> part isn't? If so, isn't it missing an offset as well? >> >> It is basically because the invariant.start may not be the immediate >> operand of the invariant.end. You may end up having phi nodes >> connecting the two when various phi translation cases occur. > > The verifier rejects phi nodes of {} type. Do you actually have a case > where you want this to happen? That sounds like a serious bug then: {} should be a first class value just like {i32}. -Chris From eli.friedman at gmail.com Wed May 20 15:34:32 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 20 May 2009 13:34:32 -0700 Subject: [LLVMdev] [PATCH] Add new phase to legalization to handle vector operations In-Reply-To: References: Message-ID: On Wed, May 20, 2009 at 1:19 PM, Eli Friedman wrote: > Per subject, this patch adding an additional pass to handle vector > operations; the idea is that this allows removing the code from > LegalizeDAG that handles illegal types, which should be a significant > simplification. ?There are still some issues with this patch, but does > the approach look sane? New version with a few minor changes and fixed-up comments; the previous version had some comments with inaccurate statements, which might be confusing for reviewing. -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) +++ lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) @@ -0,0 +1,239 @@ +//===-- LegalizeVectorOps.cpp - Implement SelectionDAG::LegalizeVectors ---===// +// +// The LLVM Compiler Infrastructure +// +// This file is distributed under the University of Illinois Open Source +// License. See LICENSE.TXT for details. +// +//===----------------------------------------------------------------------===// +// +// This file implements the SelectionDAG::LegalizeVectors method. +// +//===----------------------------------------------------------------------===// + +#include "llvm/CodeGen/SelectionDAG.h" +#include "llvm/Target/TargetLowering.h" +using namespace llvm; + +namespace { +class VectorLegalizer { + SelectionDAG& DAG; + TargetLowering& TLI; + SDValue UnrollVectorOp(SDValue Op); + SDValue PromoteVectorOp(SDValue Op); + + public: + bool Run(); + VectorLegalizer(SelectionDAG& dag) : + DAG(dag), TLI(dag.getTargetLoweringInfo()) {} +}; + +bool VectorLegalizer::Run() { + bool Changed = false; + + // The vector legalizer is a relatively simple process because it doesn't + // need to legalize everything: it just needs to catch vector operations + // which might need to be unrolled. + DAG.AssignTopologicalOrder(); + for (SelectionDAG::allnodes_iterator I = DAG.allnodes_begin(), + E = prior(DAG.allnodes_end()); I != next(E); ++I) { + bool HasVectorValue = false; + for (SDNode::value_iterator J = I->value_begin(); J != I->value_end(); ++J) + HasVectorValue |= J->isVector(); + if (!HasVectorValue) continue; + SDNode* Result = I; + switch (I->getOpcode()) { + default: + assert(I->getOpcode() > ISD::BUILTIN_OP_END && "Unexpected node!"); + break; + case ISD::UNDEF: + case ISD::FORMAL_ARGUMENTS: + case ISD::CALL: + case ISD::MERGE_VALUES: + case ISD::RET: + case ISD::VAARG: + case ISD::Register: + case ISD::INTRINSIC_WO_CHAIN: + case ISD::INTRINSIC_W_CHAIN: + case ISD::INTRINSIC_VOID: + case ISD::CopyToReg: + case ISD::CopyFromReg: + case ISD::AssertSext: + case ISD::AssertZext: + // Node cannot be illegal if types are legal + break; + case ISD::BUILD_VECTOR: + case ISD::INSERT_VECTOR_ELT: + case ISD::EXTRACT_VECTOR_ELT: + case ISD::CONCAT_VECTORS: + case ISD::EXTRACT_SUBVECTOR: + case ISD::VECTOR_SHUFFLE: + case ISD::SCALAR_TO_VECTOR: + case ISD::BIT_CONVERT: + case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could potentially be unrolled to + // illegal types. Leaving them around can also help optimization. + break; + case ISD::VSETCC: + // FIXME: Needs handling; could be unrolled + break; + case ISD::ADD: + case ISD::SUB: + case ISD::MUL: + case ISD::SDIV: + case ISD::UDIV: + case ISD::SREM: + case ISD::UREM: + case ISD::FADD: + case ISD::FSUB: + case ISD::FMUL: + case ISD::FDIV: + case ISD::FREM: + case ISD::AND: + case ISD::OR: + case ISD::XOR: + case ISD::SHL: + case ISD::SRA: + case ISD::SRL: + case ISD::ROTL: + case ISD::ROTR: + case ISD::CTTZ: + case ISD::CTLZ: + case ISD::CTPOP: + case ISD::SELECT: + case ISD::SELECT_CC: + case ISD::ZERO_EXTEND: + case ISD::ANY_EXTEND: + case ISD::TRUNCATE: + case ISD::SIGN_EXTEND: + case ISD::SINT_TO_FP: + case ISD::UINT_TO_FP: + case ISD::FP_TO_SINT: + case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) { + case TargetLowering::Promote: + Result = PromoteVectorOp(SDValue(Result, 0)).getNode(); + break; + case TargetLowering::Legal: break; + case TargetLowering::Custom: { + SDValue Tmp1 = TLI.LowerOperation(SDValue(Result, 0), DAG); + if (Tmp1.getNode()) { + // FIXME: Should the returned value be recursively checked? + Result = Tmp1.getNode(); + break; + } + // FALL THROUGH + } + case TargetLowering::Expand: + // FIXME: Handle some special cases: FNEG->FSUB + Result = UnrollVectorOp(SDValue(Result, 0)).getNode(); + break; + } + break; + } + if (&*I != Result) { + Changed = true; + DAG.ReplaceAllUsesWith(I, Result); + } + } + + // Remove dead nodes now. + DAG.RemoveDeadNodes(); + + return Changed; +} + +SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { + MVT VT = Op.getValueType(); + assert(Op.getNode()->getNumValues() == 1 && + "Can't promote a vector with multiple results!"); + MVT NVT = TLI.getTypeToPromoteTo(Op.getOpcode(), VT); + DebugLoc dl = Op.getDebugLoc(); + SmallVector Operands(Op.getNumOperands()); + + for (unsigned j = 0; j != Op.getNumOperands(); ++j) { + if (Op.getOperand(j).getValueType().isVector()) + Operands[j] = DAG.getNode(ISD::BIT_CONVERT, dl, NVT, Op.getOperand(j)); + else + Operands[j] = Op.getOperand(j); + } + + Op = DAG.getNode(Op.getOpcode(), dl, NVT, &Operands[0], Operands.size()); + + return DAG.getNode(ISD::BIT_CONVERT, dl, VT, Op); +} + +/// UnrollVectorOp - We know that the given vector has a legal type, however +/// the operation it performs is not legal, and the target has requested that +/// the operation be expanded. "Unroll" the vector, splitting out the scalars +/// and operating on each element individually. +SDValue VectorLegalizer::UnrollVectorOp(SDValue Op) { + MVT VT = Op.getValueType(); + assert(Op.getNode()->getNumValues() == 1 && + "Can't unroll a vector with multiple results!"); + unsigned NE = VT.getVectorNumElements(); + MVT EltVT = VT.getVectorElementType(); + DebugLoc dl = Op.getDebugLoc(); + + SmallVector Scalars; + SmallVector Operands(Op.getNumOperands()); + for (unsigned i = 0; i != NE; ++i) { + for (unsigned j = 0; j != Op.getNumOperands(); ++j) { + SDValue Operand = Op.getOperand(j); + MVT OperandVT = Operand.getValueType(); + if (OperandVT.isVector()) { + // A vector operand; extract a single element. + MVT OperandEltVT = OperandVT.getVectorElementType(); + Operands[j] = DAG.getNode(ISD::EXTRACT_VECTOR_ELT, dl, + OperandEltVT, + Operand, + DAG.getConstant(i, MVT::i32)); + } else { + // A scalar operand; just use it as is. + Operands[j] = Operand; + } + } + + switch (Op.getOpcode()) { + default: + Scalars.push_back(DAG.getNode(Op.getOpcode(), dl, EltVT, + &Operands[0], Operands.size())); + break; + case ISD::SHL: + case ISD::SRA: + case ISD::SRL: + case ISD::ROTL: + case ISD::ROTR: + Scalars.push_back(DAG.getNode(Op.getOpcode(), dl, EltVT, Operands[0], + DAG.getShiftAmountOperand(Operands[1]))); + break; + } + } + + return DAG.getNode(ISD::BUILD_VECTOR, dl, VT, &Scalars[0], Scalars.size()); +} + +} + +bool SelectionDAG::LegalizeVectors() { + return VectorLegalizer(*this).Run(); +} Index: lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (revision 72159) +++ lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (working copy) @@ -495,7 +495,7 @@ // types here except for target constants (the type legalizer does not touch // those) or for build vector used as a mask for a vector shuffle. assert((TypesNeedLegalizing || getTypeAction(VT) == Legal || - IsLegalizingCallArgs || Op.getOpcode() == ISD::TargetConstant) && + Op.getOpcode() == ISD::TargetConstant) && "Illegal type introduced after type legalization?"); switch (getTypeAction(VT)) { default: assert(0 && "Bad type action!"); Index: lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp =================================================================== --- lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp (revision 72159) +++ lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp (working copy) @@ -611,6 +611,36 @@ DOUT << "Optimized type-legalized selection DAG:\n"; DEBUG(CurDAG->dump()); } + + if (TimePassesIsEnabled) { + NamedRegionTimer T("Vector Legalization", GroupName); + Changed = CurDAG->LegalizeVectors(); + } else { + Changed = CurDAG->LegalizeVectors(); + } + + if (Changed) { + if (TimePassesIsEnabled) { + NamedRegionTimer T("Type Legalization 2", GroupName); + Changed = CurDAG->LegalizeTypes(); + } else { + Changed = CurDAG->LegalizeTypes(); + } + + if (ViewDAGCombineLT) + CurDAG->viewGraph("dag-combine-lv input for " + BlockName); + + // Run the DAG combiner in post-type-legalize mode. + if (TimePassesIsEnabled) { + NamedRegionTimer T("DAG Combining after legalize vectors", GroupName); + CurDAG->Combine(NoIllegalOperations, *AA, OptLevel); + } else { + CurDAG->Combine(NoIllegalOperations, *AA, OptLevel); + } + + DOUT << "Optimized vector-legalized selection DAG:\n"; + DEBUG(CurDAG->dump()); + } } if (ViewLegalizeDAGs) CurDAG->viewGraph("legalize input for " + BlockName); Index: include/llvm/CodeGen/SelectionDAG.h =================================================================== --- include/llvm/CodeGen/SelectionDAG.h (revision 72159) +++ include/llvm/CodeGen/SelectionDAG.h (working copy) @@ -220,6 +220,13 @@ /// the graph. void Legalize(bool TypesNeedLegalizing, CodeGenOpt::Level OptLevel); + /// LegalizeVectors - This transforms the SelectionDAG into a SelectionDAG + /// that only uses vector operations supported by the target. + /// + /// Note that this is an involved process that may invalidate pointers into + /// the graph. + bool LegalizeVectors(); + /// RemoveDeadNodes - This method deletes all unreachable nodes in the /// SelectionDAG. void RemoveDeadNodes(); From chuckr at telenix.org Wed May 20 15:38:15 2009 From: chuckr at telenix.org (Chuck Robey) Date: Wed, 20 May 2009 16:38:15 -0400 Subject: [LLVMdev] Arm port In-Reply-To: <305d6f60905201251r1389a9b8g2730d6b924cc597c@mail.gmail.com> References: <4A1457C0.6000601@telenix.org> <305d6f60905201251r1389a9b8g2730d6b924cc597c@mail.gmail.com> Message-ID: <4A146A37.3030808@telenix.org> Sandeep Patel wrote: > I am currently working on support for the Cortex-A9, but as all > compiler testing is more easily done on an Cortex-A8 today, A8 support > is implicit. > > What specific ISA changes are you most interested in? Are you able to > develop patches if we coordinate which areas to work on? Hmm. Well, my motivation is that I recently bought a Pandora (it has the Cortex-A8). It's not going to arrive here for a couple more months, I think. When it does finally arrive, I want to be able to immediately begin work on replacing the Linux that comes pre-installed with FreeBSD-arm. I'm not any kind of compiler specialist, and on top of that, the last 2-3 years have seen me medically retired, so I can't code at the same rate I used to. I'm perfectly willing to help you if there is some specific task you wanted to give me, but I only really wanted to see A8 compatibility. If I can help you with A9, I'm willing to do whatever reading is needed, if you think I might be of help, but my experience at doing compilers is very minimal. It seems to me that any time I spend helping out (assuming you decide there is anything I could do) would help me when I got to the FreeBSD porting task. OSes I *have* worked on, that part doesn't worry me, I wrote 3 of them. If you want my help, that's great, but if not, I'm still curious to get your feeling on how long it might be before something testable (not really release level) might be available for testing? At least to begin with, I could start coding on my own ultimate project without actually having the compiler, but it will start hurting me in not very long ... maybe I could start work with gcc-4.3.1 and move to llvm when it becomes a possibility, that might work out. Well, let me know if I might be of some help. From eli.friedman at gmail.com Wed May 20 15:46:11 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 20 May 2009 13:46:11 -0700 Subject: [LLVMdev] memory lifetime and invariance In-Reply-To: References: <4A126096.9060803@mxc.ca> <4A1371E7.8070602@mxc.ca> Message-ID: On Wed, May 20, 2009 at 1:29 PM, Chris Lattner wrote: >> The verifier rejects phi nodes of {} type. Do you actually have a case >> where you want this to happen? > > That sounds like a serious bug then: {} should be a first class value > just like {i32}. But in any case, it doesn't really make sense; wouldn't any value of type {} fold to the constant "{} {}"? If you need an opaque value, i8* seems much more appropriate. -Eli From bob.wilson at apple.com Wed May 20 16:02:51 2009 From: bob.wilson at apple.com (Bob Wilson) Date: Wed, 20 May 2009 14:02:51 -0700 Subject: [LLVMdev] Arm port In-Reply-To: <4A146A37.3030808@telenix.org> References: <4A1457C0.6000601@telenix.org> <305d6f60905201251r1389a9b8g2730d6b924cc597c@mail.gmail.com> <4A146A37.3030808@telenix.org> Message-ID: <929C10B1-1FD5-4EC3-8C78-B683280D1677@apple.com> On May 20, 2009, at 1:38 PM, Chuck Robey wrote: > Hmm. Well, my motivation is that I recently bought a Pandora (it > has the > Cortex-A8). It's not going to arrive here for a couple more months, > I think. > When it does finally arrive, I want to be able to immediately begin > work on > replacing the Linux that comes pre-installed with FreeBSD-arm. Hi Chuck, I'm not very familiar with the Pandora, but as far as I know ARM is pretty good about backward compatibility. You should be able to run ARM code compiled by LLVM on it. LLVM currently only generates code for version 6 of the ARM architecture, so you wouldn't be taking full advantage of the Pandora's processor but it may not matter, depending on what you're trying to do with it. If you are able to try out LLVM for ARM, we would welcome your feedback and contributions! --Bob From dnmh68 at hotmail.com Wed May 20 16:22:02 2009 From: dnmh68 at hotmail.com (dan mihai) Date: Wed, 20 May 2009 21:22:02 +0000 Subject: [LLVMdev] jump to function Message-ID: Hello, Is it possible to jump from one function to the beginning of another function? For instance, assume wrapper_FOO is a wrapper for FOO. I replace the code .............................. bar() { FOO(...) } .............................. with .............................. bar() { wrapper_FOO(...) } .............................. Now, for efficiency, I'd like to have wrapper_FOO() { jump FOO; } Thank you, Dan _________________________________________________________________ Insert movie times and more without leaving Hotmail?. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090520/69c04440/attachment.html From dalej at apple.com Wed May 20 16:34:09 2009 From: dalej at apple.com (Dale Johannesen) Date: Wed, 20 May 2009 14:34:09 -0700 Subject: [LLVMdev] jump to function In-Reply-To: References: Message-ID: <4B8F08CF-668A-4E6C-800F-82A3B188B21F@apple.com> On May 20, 2009, at 2:22 PMPDT, dan mihai wrote: > Hello, > > Is it possible to jump from one function to the beginning of another > function? This can't be represented in llvm IR (or in standard C/C++). An optimization called (in LLVM) "tail call" will generate this at the assembly level, but not all back ends have this implemented. > For instance, assume wrapper_FOO is a wrapper for FOO. I replace the > code > .............................. > bar() { > FOO(...) > } > .............................. > with > .............................. > bar() { > wrapper_FOO(...) > } > .............................. > > Now, for efficiency, I'd like to have > wrapper_FOO() { > > jump FOO; > } > > Thank you, > Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090520/e6a62892/attachment.html From richard at xmos.com Wed May 20 16:44:11 2009 From: richard at xmos.com (Richard Osborne) Date: Wed, 20 May 2009 22:44:11 +0100 Subject: [LLVMdev] jump to function In-Reply-To: References: Message-ID: <4A1479AB.30800@xmos.com> dan mihai wrote: > Hello, > > Is it possible to jump from one function to the beginning of another > function? > > For instance, assume wrapper_FOO is a wrapper for FOO. I replace the code > .............................. > bar() { > FOO(...) > } > .............................. > with > .............................. > bar() { > wrapper_FOO(...) > } > .............................. > > Now, for efficiency, I'd like to have > wrapper_FOO() { > > jump FOO; > } Tail call optimization can optimize calls into jumps. See http://llvm.org/docs/CodeGenerator.html#tailcallopt for details. -- Richard Osborne | XMOS http://www.xmos.com From chuckr at telenix.org Wed May 20 17:13:01 2009 From: chuckr at telenix.org (Chuck Robey) Date: Wed, 20 May 2009 18:13:01 -0400 Subject: [LLVMdev] Arm port In-Reply-To: <929C10B1-1FD5-4EC3-8C78-B683280D1677@apple.com> References: <4A1457C0.6000601@telenix.org> <305d6f60905201251r1389a9b8g2730d6b924cc597c@mail.gmail.com> <4A146A37.3030808@telenix.org> <929C10B1-1FD5-4EC3-8C78-B683280D1677@apple.com> Message-ID: <4A14806D.8050405@telenix.org> Bob Wilson wrote: > On May 20, 2009, at 1:38 PM, Chuck Robey wrote: >> Hmm. Well, my motivation is that I recently bought a Pandora (it >> has the >> Cortex-A8). It's not going to arrive here for a couple more months, >> I think. >> When it does finally arrive, I want to be able to immediately begin >> work on >> replacing the Linux that comes pre-installed with FreeBSD-arm. > > Hi Chuck, > > I'm not very familiar with the Pandora, but as far as I know ARM is > pretty good about backward compatibility. You should be able to run > ARM code compiled by LLVM on it. LLVM currently only generates code > for version 6 of the ARM architecture, so you wouldn't be taking full > advantage of the Pandora's processor but it may not matter, depending > on what you're trying to do with it. > > If you are able to try out LLVM for ARM, we would welcome your > feedback and contributions! Certainly, I'll test it out. In fact, I think now, that I do have a Nokia N800, and it runs the same TI OMAP3530 (I think, but I'm going to have to go doublecheck that) so I might well be able to test immediately. Tell you what: beginning immediately, I'll start reading all of the documents I can find at your site, so I'm not quite so dumb at it. I haven't seen that the code was up for download (or checkout?) but if it is, I'll fetch it and begin looking things over. If there is anything concrete that I could contribute, I'll do that. But, just doing all that reading is going to take me some time (to really learn it all). If you folks can offer me a compiler tool which I can ultimately use for the porting of FreeBSD to the Pandora (or the N800?), then I'm going to really owe you something, I think. That means, I'll likely disappear now that I can start reading things. I haven't gone away, I'm just trying to get to the point that I'm of use. From deeppatel1987 at gmail.com Wed May 20 18:06:51 2009 From: deeppatel1987 at gmail.com (Sandeep Patel) Date: Wed, 20 May 2009 16:06:51 -0700 Subject: [LLVMdev] Arm port In-Reply-To: <4A14806D.8050405@telenix.org> References: <4A1457C0.6000601@telenix.org> <305d6f60905201251r1389a9b8g2730d6b924cc597c@mail.gmail.com> <4A146A37.3030808@telenix.org> <929C10B1-1FD5-4EC3-8C78-B683280D1677@apple.com> <4A14806D.8050405@telenix.org> Message-ID: <305d6f60905201606k6103277ax65ea75d073bad08@mail.gmail.com> The Nokia N800 is an OMAP 2420 which is an ARM11. If you want an OMAP 3530 today, I think the cheapest route is the Beagleboard. deep On Wed, May 20, 2009 at 3:13 PM, Chuck Robey wrote: > Bob Wilson wrote: >> On May 20, 2009, at 1:38 PM, Chuck Robey wrote: >>> Hmm. ?Well, my motivation is that I recently bought a Pandora (it >>> has the >>> Cortex-A8). ?It's not going to arrive here for a couple more months, >>> I think. >>> When it does finally arrive, I want to be able to immediately begin >>> work on >>> replacing the Linux that comes pre-installed with FreeBSD-arm. >> >> Hi Chuck, >> >> I'm not very familiar with the Pandora, but as far as I know ARM is >> pretty good about backward compatibility. ?You should be able to run >> ARM code compiled by LLVM on it. ?LLVM currently only generates code >> for version 6 of the ARM architecture, so you wouldn't be taking full >> advantage of the Pandora's processor but it may not matter, depending >> on what you're trying to do with it. >> >> If you are able to try out LLVM for ARM, we would welcome your >> feedback and contributions! > > Certainly, I'll test it out. ?In fact, I think now, that I do have a Nokia N800, > and it runs the same TI OMAP3530 (I think, but I'm going to have to go > doublecheck that) so I might well be able to test immediately. > > Tell you what: beginning immediately, I'll start reading all of the documents I > can find at your site, so I'm not quite so dumb at it. ?I haven't seen that the > code was up for download (or checkout?) but if it is, I'll fetch it and begin > looking things over. ?If there is anything concrete that I could contribute, > I'll do that. ?But, just doing all that reading is going to take me some time > (to really learn it all). ?If you folks can offer me a compiler tool which I can > ultimately use for the porting of FreeBSD to the Pandora (or the N800?), then > I'm going to really owe you something, I think. > > That means, I'll likely disappear now that I can start reading things. ?I > haven't gone away, I'm just trying to get to the point that I'm of use. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From chuckr at telenix.org Wed May 20 18:53:47 2009 From: chuckr at telenix.org (Chuck Robey) Date: Wed, 20 May 2009 19:53:47 -0400 Subject: [LLVMdev] Arm port In-Reply-To: <305d6f60905201606k6103277ax65ea75d073bad08@mail.gmail.com> References: <4A1457C0.6000601@telenix.org> <305d6f60905201251r1389a9b8g2730d6b924cc597c@mail.gmail.com> <4A146A37.3030808@telenix.org> <929C10B1-1FD5-4EC3-8C78-B683280D1677@apple.com> <4A14806D.8050405@telenix.org> <305d6f60905201606k6103277ax65ea75d073bad08@mail.gmail.com> Message-ID: <4A14980B.5050308@telenix.org> Sandeep Patel wrote: > The Nokia N800 is an OMAP 2420 which is an ARM11. > > If you want an OMAP 3530 today, I think the cheapest route is the Beagleboard. Yeah, I see that now, about the N800. About the BeagleBoard, if you're going after an equivalent # of peripherals (screen and keyboard are things I wanted) then, really, I think that the Pandora is cheapest. I will say, without reservation, that the BeagleBoard is the goddamndest best single board computer that I've EVER seen, and I've put together a pretty large set of them, for one communications company or another. It's just my opinion, but I think that covering that OMAP3530 is really important, cause you're covering a pretty darn big slice of homebrew enthusiasts, as opposed to people who'd let their computers end up as doorstops. Besides, I've already bought the Pandora, it's kinda late to change my mind. It hasn't arrived here yet, though, and I expect it to be another month or two before it finally does. It's being produced by a set of open software guys, who are great at putting together a good list of peripherals, but they really don't seem to understand deadlines all that well. I guess it won't kill me to wait a little. What was actually important to me was getting a compiler to assist a FreeBSD porting effort, and I just hope that llvm becomes available for the Cortex-A8 (or A9, as you said) soonest. I'm reading the llvm docs now, and referring to my old college compiler books. Unfortunately, I concentrated in OSes when I was in school. I did get a piece of luck, and was able to pick up a copy of that great compiler book, cheaply, even (that guy didn't ever want to be reminded what compilers were!) > > deep > > On Wed, May 20, 2009 at 3:13 PM, Chuck Robey wrote: >> Bob Wilson wrote: >>> On May 20, 2009, at 1:38 PM, Chuck Robey wrote: >>>> Hmm. Well, my motivation is that I recently bought a Pandora (it >>>> has the >>>> Cortex-A8). It's not going to arrive here for a couple more months, >>>> I think. >>>> When it does finally arrive, I want to be able to immediately begin >>>> work on >>>> replacing the Linux that comes pre-installed with FreeBSD-arm. >>> Hi Chuck, >>> >>> I'm not very familiar with the Pandora, but as far as I know ARM is >>> pretty good about backward compatibility. You should be able to run >>> ARM code compiled by LLVM on it. LLVM currently only generates code >>> for version 6 of the ARM architecture, so you wouldn't be taking full >>> advantage of the Pandora's processor but it may not matter, depending >>> on what you're trying to do with it. >>> >>> If you are able to try out LLVM for ARM, we would welcome your >>> feedback and contributions! >> Certainly, I'll test it out. In fact, I think now, that I do have a Nokia N800, >> and it runs the same TI OMAP3530 (I think, but I'm going to have to go >> doublecheck that) so I might well be able to test immediately. >> >> Tell you what: beginning immediately, I'll start reading all of the documents I >> can find at your site, so I'm not quite so dumb at it. I haven't seen that the >> code was up for download (or checkout?) but if it is, I'll fetch it and begin >> looking things over. If there is anything concrete that I could contribute, >> I'll do that. But, just doing all that reading is going to take me some time >> (to really learn it all). If you folks can offer me a compiler tool which I can >> ultimately use for the porting of FreeBSD to the Pandora (or the N800?), then >> I'm going to really owe you something, I think. >> >> That means, I'll likely disappear now that I can start reading things. I >> haven't gone away, I'm just trying to get to the point that I'm of use. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From gohman at apple.com Wed May 20 18:55:39 2009 From: gohman at apple.com (Dan Gohman) Date: Wed, 20 May 2009 16:55:39 -0700 Subject: [LLVMdev] [PATCH] Add new phase to legalization to handle vector operations In-Reply-To: References: Message-ID: <3FADFF11-74A1-4F71-9682-4E5AEDB4672C@apple.com> On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant >> >> simplification. There are still some issues with this patch, but >> does >> >> the approach look sane? Can you explain why you chose the approach of using a new pass? I pictured removing LegalizeDAG's type legalization code would mostly consist of finding all the places that use TLI.getTypeAction and just deleting code for handling its Expand and Promote. Are you anticipating something more complicated? Dan From eli.friedman at gmail.com Wed May 20 19:26:42 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 20 May 2009 17:26:42 -0700 Subject: [LLVMdev] [PATCH] Add new phase to legalization to handle vector operations In-Reply-To: <3FADFF11-74A1-4F71-9682-4E5AEDB4672C@apple.com> References: <3FADFF11-74A1-4F71-9682-4E5AEDB4672C@apple.com> Message-ID: On Wed, May 20, 2009 at 4:55 PM, Dan Gohman wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more complicated? Consider the case of an illegal operation (like division) on a <2 x i64> on x86-32. If we unroll it, the result has to go through type legalization. Therefore, if we want to remove the type legalization code from LegalizeDAG, we have to unroll vector operations first, then run a round of type legalization. (There are potential alternatives, like making LegalizeDAG call back into type legalization, but it gets messy.) Actually, I went ahead and tried writing the patch to remove type legalization from LegalizeDAG; I actually ran into another issue, which is the legalization of i32 UINT_TO_FP. We want to legalize it into an i64 UINT_TO_FP, but that requires type legalization. I'm not quite sure what to do about that; if I can't come up with a better solution, I'll force the x86 backend to custom-lower that case. -Eli From sricketts at maxentric.com Wed May 20 21:31:30 2009 From: sricketts at maxentric.com (Scott Ricketts) Date: Wed, 20 May 2009 19:31:30 -0700 Subject: [LLVMdev] Passing a pointer to a function Message-ID: <6d9073030905201931l69c55699u94668e078ec3df0e@mail.gmail.com> I recently began hacking around with my first LLVM pass. The big picture is that I would like to insert function calls for each instruction type, and pass some parameters based on the instruction type. Then I will link the output to some C file that implements those functions. Things were going well until I started trying to make function calls with a pointer as a parameter. For example, I would like to do something like: void visitLoadInst(LoadInst &I) { Value *P; P = I.getPointerOperand(); CallInst::Create(load_fcall, P, "", &I); } Where load_fcall is build using a call to Module::getOrInsertFunction as in the example here: http://wiki.llvm.org/HowTo:_Insert_a_function_call My question is, what do I pass as the argument type for P above? The following seems to work, as long as there are no floating point ops: PointerType::getUnqual(IntegerType::get(32)) So I tried using just a void pointer type, as in: PointerType::getUnqual(Type::VoidTy) But then Type.cpp throws this assertion. Assertion `ValueType != Type::VoidTy && "Pointer to void is not valid, use sbyte* instead!"' failed. I can try checking the type before building the function, as in: void visitLoadInst(LoadInst &I) { Value *P; P = I.getPointerOperand(); PointerType* PtrTy = (PointerType*)(P); Constant* fcall; if (PtrTy->getElementType()->isInteger()) { fcall = buildFcallMem(*theModule, "load_int", Type::Int32Ty); CallInst::Create(fcall, P, "", &I); } else if (PtrTy->getElementType()->isInteger()){ fcall = buildFcallMem(*theModule, "load_float", Type::FloatTy); CallInst::Create(fcall, P, "", &I); } } But then I get segfaults or assertions fail in Type.h (it's a huge mess). I could be more specific, but I have tried several different approaches and am trying to be brief here. Perhaps I am overlooking an obvious approach. I will continue snooping through the code to attempt to learn what is going on, but if anyone could nudge me in the right direction or point out where I am completely off, that would probably be helpful. Thanks, Scott From eli.friedman at gmail.com Wed May 20 21:45:59 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 20 May 2009 19:45:59 -0700 Subject: [LLVMdev] Passing a pointer to a function In-Reply-To: <6d9073030905201931l69c55699u94668e078ec3df0e@mail.gmail.com> References: <6d9073030905201931l69c55699u94668e078ec3df0e@mail.gmail.com> Message-ID: On Wed, May 20, 2009 at 7:31 PM, Scott Ricketts wrote: > Where load_fcall is build using a call to Module::getOrInsertFunction > as in the example here: > > http://wiki.llvm.org/HowTo:_Insert_a_function_call > > My question is, what do I pass as the argument type for P above? The > following seems to work, as long as there are no floating point ops: I would suggest bit-casting p to an i8*. > So I tried using just a void pointer type, as in: > PointerType::getUnqual(Type::VoidTy) > > But then Type.cpp throws this assertion. > Assertion `ValueType != Type::VoidTy && "Pointer to void is not valid, > use sbyte* instead!"' failed. Yeah, void* in C == i8* in LLVM. VoidTy is only used for function return types. I'm not sure why you're getting crashes with the last approach; it looks like it should work. -Eli From eli.friedman at gmail.com Wed May 20 23:14:28 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 20 May 2009 21:14:28 -0700 Subject: [LLVMdev] [PATCH] Add new phase to legalization to handle vector operations In-Reply-To: References: <3FADFF11-74A1-4F71-9682-4E5AEDB4672C@apple.com> Message-ID: On Wed, May 20, 2009 at 5:26 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction >> and just deleting code for handling its Expand and Promote. Are you >> anticipating something more complicated? > > Consider the case of an illegal operation (like division) on a <2 x > i64> on x86-32. ?If we unroll it, the result has to go through type > legalization. ?Therefore, if we want to remove the type legalization > code from LegalizeDAG, we have to unroll vector operations first, then > run a round of type legalization. ?(There are potential alternatives, > like making LegalizeDAG call back into type legalization, but it gets > messy.) > > Actually, I went ahead and tried writing the patch to remove type > legalization from LegalizeDAG; I actually ran into another issue, > which is the legalization of i32 UINT_TO_FP. ?We want to legalize it > into an i64 UINT_TO_FP, but that requires type legalization. ?I'm not > quite sure what to do about that; if I can't come up with a better > solution, I'll force the x86 backend to custom-lower that case. Attached is a more complete version, including the simplification of LegalizeDAG and the fixes for UINT_TO_FP and FP_TO_UINT on x86. It passes regression tests except for one failure due to a missing implementation of legalization for EXTRACT_SUBVECTOR where both types are legal. -Eli -------------- next part -------------- Index: test/CodeGen/X86/widen_cast-4.ll =================================================================== --- test/CodeGen/X86/widen_cast-4.ll (revision 72159) +++ test/CodeGen/X86/widen_cast-4.ll (working copy) @@ -1,5 +1,5 @@ ; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse42 -disable-mmx -o %t -f -; RUN: grep sarb %t | count 16 +; RUN: grep sarb %t | count 8 ; v8i8 that is widen to v16i8 then split ; FIXME: This is widen to v16i8 and split to 16 and we then rebuild the vector. Index: include/llvm/CodeGen/SelectionDAG.h =================================================================== --- include/llvm/CodeGen/SelectionDAG.h (revision 72159) +++ include/llvm/CodeGen/SelectionDAG.h (working copy) @@ -220,6 +220,13 @@ /// the graph. void Legalize(bool TypesNeedLegalizing, CodeGenOpt::Level OptLevel); + /// LegalizeVectors - This transforms the SelectionDAG into a SelectionDAG + /// that only uses vector operations supported by the target. + /// + /// Note that this is an involved process that may invalidate pointers into + /// the graph. + bool LegalizeVectors(); + /// RemoveDeadNodes - This method deletes all unreachable nodes in the /// SelectionDAG. void RemoveDeadNodes(); Index: lib/Target/X86/X86ISelLowering.cpp =================================================================== --- lib/Target/X86/X86ISelLowering.cpp (revision 72159) +++ lib/Target/X86/X86ISelLowering.cpp (working copy) @@ -117,15 +117,18 @@ setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Promote); setOperationAction(ISD::UINT_TO_FP , MVT::i64 , Expand); } else { - if (!UseSoftFloat && !NoImplicitFloat && X86ScalarSSEf64) { + if (!UseSoftFloat && X86ScalarSSEf64) { // We have an impenetrably clever algorithm for ui64->double only. setOperationAction(ISD::UINT_TO_FP , MVT::i64 , Custom); - - // We have faster algorithm for ui32->single only. - setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Custom); } else { - setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Promote); + // Otherwise, let the legalizer turn this into an SINT_TO_FP + setOperationAction(ISD::UINT_TO_FP , MVT::i64 , Expand); } + if (!UseSoftFloat) { + // We have an algorithm for SSE2, and we turn this into a 64-bit + // FILD on other platforms. + setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Custom); + } } // Promote i1/i8 SINT_TO_FP to larger SINT_TO_FP's, as X86 doesn't have @@ -176,15 +179,16 @@ if (Subtarget->is64Bit()) { setOperationAction(ISD::FP_TO_UINT , MVT::i64 , Expand); setOperationAction(ISD::FP_TO_UINT , MVT::i32 , Promote); - } else { + } else if (!UseSoftFloat) { if (X86ScalarSSEf32 && !Subtarget->hasSSE3()) // Expand FP_TO_UINT into a select. // FIXME: We would like to use a Custom expander here eventually to do // the optimal thing for SSE vs. the default expansion in the legalizer. - setOperationAction(ISD::FP_TO_UINT , MVT::i32 , Expand); + setOperationAction(ISD::FP_TO_UINT , MVT::i32, Expand); else - // With SSE3 we can use fisttpll to convert to a signed i64. - setOperationAction(ISD::FP_TO_UINT , MVT::i32 , Promote); + // With SSE3 we can use fisttpll to convert to a signed i64; without + // SSE, we're stuck with a fistpll. + setOperationAction(ISD::FP_TO_UINT , MVT::i32 , Custom); } // TODO: when we have SSE, these could be more efficient, by using movd/movq. @@ -4608,8 +4612,14 @@ SDValue Chain = DAG.getStore(DAG.getEntryNode(), dl, Op.getOperand(0), StackSlot, PseudoSourceValue::getFixedStack(SSFI), 0); + return BuildFILD(Op, SrcVT, Chain, StackSlot, DAG); +} +SDValue X86TargetLowering::BuildFILD(SDValue Op, MVT SrcVT, SDValue Chain, + SDValue StackSlot, + SelectionDAG &DAG) { // Build the FILD + DebugLoc dl = Op.getDebugLoc(); SDVTList Tys; bool useSSE = isScalarFPTypeInSSEReg(Op.getValueType()); if (useSSE) @@ -4792,36 +4802,54 @@ return SDValue(); return LowerUINT_TO_FP_i64(Op, DAG); - } else if (SrcVT == MVT::i32) { + } else if (SrcVT == MVT::i32 && X86ScalarSSEf64) { return LowerUINT_TO_FP_i32(Op, DAG); } - assert(0 && "Unknown UINT_TO_FP to lower!"); - return SDValue(); + assert(SrcVT == MVT::i32 && "Unknown UINT_TO_FP to lower!"); + + // Make a 64-bit buffer, and use it to build an FILD. + SDValue StackSlot = DAG.CreateStackTemporary(MVT::i64); + SDValue WordOff = DAG.getConstant(4, getPointerTy()); + SDValue OffsetSlot = DAG.getNode(ISD::ADD, dl, + getPointerTy(), StackSlot, WordOff); + SDValue Store1 = DAG.getStore(DAG.getEntryNode(), dl, Op, StackSlot, NULL, 0); + SDValue Store2 = DAG.getStore(Store1, dl, DAG.getConstant(0, MVT::i32), + OffsetSlot, NULL, 0); + return BuildFILD(Op, MVT::i64, Store2, StackSlot, DAG); } std::pair X86TargetLowering:: -FP_TO_SINTHelper(SDValue Op, SelectionDAG &DAG) { +FP_TO_INTHelper(SDValue Op, SelectionDAG &DAG, bool IsSigned) { DebugLoc dl = Op.getDebugLoc(); - assert(Op.getValueType().getSimpleVT() <= MVT::i64 && - Op.getValueType().getSimpleVT() >= MVT::i16 && + + MVT DstTy = Op.getValueType(); + + if (!IsSigned) { + assert(DstTy == MVT::i32 && "Unexpected FP_TO_UINT"); + DstTy = MVT::i64; + } + + assert(DstTy.getSimpleVT() <= MVT::i64 && + DstTy.getSimpleVT() >= MVT::i16 && "Unknown FP_TO_SINT to lower!"); // These are really Legal. - if (Op.getValueType() == MVT::i32 && + if (DstTy == MVT::i32 && isScalarFPTypeInSSEReg(Op.getOperand(0).getValueType())) return std::make_pair(SDValue(), SDValue()); if (Subtarget->is64Bit() && - Op.getValueType() == MVT::i64 && + DstTy == MVT::i64 && Op.getOperand(0).getValueType() != MVT::f80) return std::make_pair(SDValue(), SDValue()); // We lower FP->sint64 into FISTP64, followed by a load, all to a temporary // stack slot. MachineFunction &MF = DAG.getMachineFunction(); - unsigned MemSize = Op.getValueType().getSizeInBits()/8; + unsigned MemSize = DstTy.getSizeInBits()/8; int SSFI = MF.getFrameInfo()->CreateStackObject(MemSize, MemSize); SDValue StackSlot = DAG.getFrameIndex(SSFI, getPointerTy()); + unsigned Opc; switch (Op.getValueType().getSimpleVT()) { default: assert(0 && "Invalid FP_TO_SINT to lower!"); @@ -4833,7 +4861,7 @@ SDValue Chain = DAG.getEntryNode(); SDValue Value = Op.getOperand(0); if (isScalarFPTypeInSSEReg(Op.getOperand(0).getValueType())) { - assert(Op.getValueType() == MVT::i64 && "Invalid FP_TO_SINT to lower!"); + assert(DstTy == MVT::i64 && "Invalid FP_TO_SINT to lower!"); Chain = DAG.getStore(Chain, dl, Value, StackSlot, PseudoSourceValue::getFixedStack(SSFI), 0); SDVTList Tys = DAG.getVTList(Op.getOperand(0).getValueType(), MVT::Other); @@ -4854,7 +4882,7 @@ } SDValue X86TargetLowering::LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG) { - std::pair Vals = FP_TO_SINTHelper(Op, DAG); + std::pair Vals = FP_TO_INTHelper(Op, DAG, true); SDValue FIST = Vals.first, StackSlot = Vals.second; if (FIST.getNode() == 0) return SDValue(); @@ -4863,6 +4891,16 @@ FIST, StackSlot, NULL, 0); } +SDValue X86TargetLowering::LowerFP_TO_UINT(SDValue Op, SelectionDAG &DAG) { + std::pair Vals = FP_TO_INTHelper(Op, DAG, false); + SDValue FIST = Vals.first, StackSlot = Vals.second; + assert(FIST.getNode() && "Unexpected failure"); + + // Load the result. + return DAG.getLoad(Op.getValueType(), Op.getDebugLoc(), + FIST, StackSlot, NULL, 0); +} + SDValue X86TargetLowering::LowerFABS(SDValue Op, SelectionDAG &DAG) { DebugLoc dl = Op.getDebugLoc(); MVT VT = Op.getValueType(); @@ -6555,6 +6593,7 @@ case ISD::SINT_TO_FP: return LowerSINT_TO_FP(Op, DAG); case ISD::UINT_TO_FP: return LowerUINT_TO_FP(Op, DAG); case ISD::FP_TO_SINT: return LowerFP_TO_SINT(Op, DAG); + case ISD::FP_TO_UINT: return LowerFP_TO_UINT(Op, DAG); case ISD::FABS: return LowerFABS(Op, DAG); case ISD::FNEG: return LowerFNEG(Op, DAG); case ISD::FCOPYSIGN: return LowerFCOPYSIGN(Op, DAG); @@ -6626,7 +6665,8 @@ assert(false && "Do not know how to custom type legalize this operation!"); return; case ISD::FP_TO_SINT: { - std::pair Vals = FP_TO_SINTHelper(SDValue(N, 0), DAG); + std::pair Vals = + FP_TO_INTHelper(SDValue(N, 0), DAG, true); SDValue FIST = Vals.first, StackSlot = Vals.second; if (FIST.getNode() != 0) { MVT VT = N->getValueType(0); Index: lib/Target/X86/X86ISelLowering.h =================================================================== --- lib/Target/X86/X86ISelLowering.h (revision 72159) +++ lib/Target/X86/X86ISelLowering.h (working copy) @@ -569,8 +569,8 @@ NameDecorationStyle NameDecorationForFORMAL_ARGUMENTS(SDValue Op); unsigned GetAlignedArgumentStackSize(unsigned StackSize, SelectionDAG &DAG); - std::pair FP_TO_SINTHelper(SDValue Op, - SelectionDAG &DAG); + std::pair FP_TO_INTHelper(SDValue Op, SelectionDAG &DAG, + bool isSigned); SDValue LowerBUILD_VECTOR(SDValue Op, SelectionDAG &DAG); SDValue LowerVECTOR_SHUFFLE(SDValue Op, SelectionDAG &DAG); @@ -586,11 +586,16 @@ SDValue LowerGlobalTLSAddress(SDValue Op, SelectionDAG &DAG); SDValue LowerExternalSymbol(SDValue Op, SelectionDAG &DAG); SDValue LowerShift(SDValue Op, SelectionDAG &DAG); + SDValue BuildFILD(SDValue Op, MVT SrcVT, SDValue Chain, SDValue StackSlot, + SelectionDAG &DAG); + SDValue BuildFIST(SDValue Op, MVT DstVT, SDValue Chain, SDValue StackSlot, + SelectionDAG &DAG); SDValue LowerSINT_TO_FP(SDValue Op, SelectionDAG &DAG); SDValue LowerUINT_TO_FP(SDValue Op, SelectionDAG &DAG); SDValue LowerUINT_TO_FP_i64(SDValue Op, SelectionDAG &DAG); SDValue LowerUINT_TO_FP_i32(SDValue Op, SelectionDAG &DAG); SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG); + SDValue LowerFP_TO_UINT(SDValue Op, SelectionDAG &DAG); SDValue LowerFABS(SDValue Op, SelectionDAG &DAG); SDValue LowerFNEG(SDValue Op, SelectionDAG &DAG); SDValue LowerFCOPYSIGN(SDValue Op, SelectionDAG &DAG); Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) +++ lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (revision 0) @@ -0,0 +1,276 @@ +//===-- LegalizeVectorOps.cpp - Implement SelectionDAG::LegalizeVectors ---===// +// +// The LLVM Compiler Infrastructure +// +// This file is distributed under the University of Illinois Open Source +// License. See LICENSE.TXT for details. +// +//===----------------------------------------------------------------------===// +// +// This file implements the SelectionDAG::LegalizeVectors method. +// +//===----------------------------------------------------------------------===// + +#include "llvm/CodeGen/SelectionDAG.h" +#include "llvm/Target/TargetLowering.h" +using namespace llvm; + +namespace { +class VectorLegalizer { + SelectionDAG& DAG; + TargetLowering& TLI; + SDValue UnrollVectorOp(SDValue Op); + SDValue UnrollVSETCC(SDValue Op); + SDValue ExpandFNEG(SDValue Op); + SDValue PromoteVectorOp(SDValue Op); + + public: + bool Run(); + VectorLegalizer(SelectionDAG& dag) : + DAG(dag), TLI(dag.getTargetLoweringInfo()) {} +}; + +bool VectorLegalizer::Run() { + bool Changed = false; + + // The vector legalizer is a relatively simple process because it doesn't + // need to legalize everything: it just needs to catch vector operations + // which might need to be unrolled. + DAG.AssignTopologicalOrder(); + for (SelectionDAG::allnodes_iterator I = DAG.allnodes_begin(), + E = prior(DAG.allnodes_end()); I != next(E); ++I) { + bool HasVectorValue = false; + for (SDNode::value_iterator J = I->value_begin(); J != I->value_end(); ++J) + HasVectorValue |= J->isVector(); + if (!HasVectorValue) continue; + SDNode* Result = I; + switch (I->getOpcode()) { + default: + assert(I->getOpcode() > ISD::BUILTIN_OP_END && "Unexpected node!"); + break; + case ISD::UNDEF: + case ISD::FORMAL_ARGUMENTS: + case ISD::CALL: + case ISD::MERGE_VALUES: + case ISD::RET: + case ISD::VAARG: + case ISD::Register: + case ISD::INTRINSIC_WO_CHAIN: + case ISD::INTRINSIC_W_CHAIN: + case ISD::INTRINSIC_VOID: + case ISD::CopyToReg: + case ISD::CopyFromReg: + case ISD::AssertSext: + case ISD::AssertZext: + // Node cannot be illegal if types are legal + break; + case ISD::BUILD_VECTOR: + case ISD::INSERT_VECTOR_ELT: + case ISD::EXTRACT_VECTOR_ELT: + case ISD::CONCAT_VECTORS: + case ISD::EXTRACT_SUBVECTOR: + case ISD::VECTOR_SHUFFLE: + case ISD::SCALAR_TO_VECTOR: + case ISD::BIT_CONVERT: + case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could potentially be unrolled to + // illegal types. Leaving them around can also help optimization. + break; + case ISD::ADD: + case ISD::SUB: + case ISD::MUL: + case ISD::SDIV: + case ISD::UDIV: + case ISD::SREM: + case ISD::UREM: + case ISD::FADD: + case ISD::FSUB: + case ISD::FMUL: + case ISD::FDIV: + case ISD::FREM: + case ISD::AND: + case ISD::OR: + case ISD::XOR: + case ISD::SHL: + case ISD::SRA: + case ISD::SRL: + case ISD::ROTL: + case ISD::ROTR: + case ISD::CTTZ: + case ISD::CTLZ: + case ISD::CTPOP: + case ISD::SELECT: + case ISD::SELECT_CC: + case ISD::VSETCC: + case ISD::ZERO_EXTEND: + case ISD::ANY_EXTEND: + case ISD::TRUNCATE: + case ISD::SIGN_EXTEND: + case ISD::SINT_TO_FP: + case ISD::UINT_TO_FP: + case ISD::FP_TO_SINT: + case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) { + case TargetLowering::Promote: + Result = PromoteVectorOp(SDValue(Result, 0)).getNode(); + break; + case TargetLowering::Legal: break; + case TargetLowering::Custom: { + SDValue Tmp1 = TLI.LowerOperation(SDValue(Result, 0), DAG); + if (Tmp1.getNode()) { + // FIXME: Should the returned value be recursively checked? + Result = Tmp1.getNode(); + break; + } + // FALL THROUGH + } + case TargetLowering::Expand: + // FIXME: Handle some special cases: FNEG->FSUB + if (I->getOpcode() == ISD::FNEG) + Result = ExpandFNEG(SDValue(Result, 0)).getNode(); + else if (I->getOpcode() == ISD::VSETCC) + Result = UnrollVSETCC(SDValue(Result, 0)).getNode(); + else + Result = UnrollVectorOp(SDValue(Result, 0)).getNode(); + break; + } + break; + } + if (&*I != Result) { + Changed = true; + DAG.ReplaceAllUsesWith(I, Result); + } + } + + // Remove dead nodes now. + DAG.RemoveDeadNodes(); + + return Changed; +} + +SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { + MVT VT = Op.getValueType(); + assert(Op.getNode()->getNumValues() == 1 && + "Can't promote a vector with multiple results!"); + MVT NVT = TLI.getTypeToPromoteTo(Op.getOpcode(), VT); + DebugLoc dl = Op.getDebugLoc(); + SmallVector Operands(Op.getNumOperands()); + + for (unsigned j = 0; j != Op.getNumOperands(); ++j) { + if (Op.getOperand(j).getValueType().isVector()) + Operands[j] = DAG.getNode(ISD::BIT_CONVERT, dl, NVT, Op.getOperand(j)); + else + Operands[j] = Op.getOperand(j); + } + + Op = DAG.getNode(Op.getOpcode(), dl, NVT, &Operands[0], Operands.size()); + + return DAG.getNode(ISD::BIT_CONVERT, dl, VT, Op); +} + +SDValue VectorLegalizer::ExpandFNEG(SDValue Op) { + if (TLI.isOperationLegalOrCustom(ISD::FSUB, Op.getValueType())) { + SDValue Zero = DAG.getConstantFP(-0.0, Op.getValueType()); + return DAG.getNode(ISD::FSUB, Op.getDebugLoc(), Op.getValueType(), + Zero, Op.getOperand(0)); + } + return UnrollVectorOp(Op); +} + +SDValue VectorLegalizer::UnrollVSETCC(SDValue Op) { + MVT VT = Op.getValueType(); + unsigned NumElems = VT.getVectorNumElements(); + MVT EltVT = VT.getVectorElementType(); + SDValue LHS = Op.getOperand(0), RHS = Op.getOperand(1), CC = Op.getOperand(2); + MVT TmpEltVT = LHS.getValueType().getVectorElementType(); + DebugLoc dl = Op.getDebugLoc(); + SmallVector Ops(NumElems); + for (unsigned i = 0; i < NumElems; ++i) { + SDValue LHSElem = DAG.getNode(ISD::EXTRACT_VECTOR_ELT, dl, TmpEltVT, LHS, + DAG.getIntPtrConstant(i)); + SDValue RHSElem = DAG.getNode(ISD::EXTRACT_VECTOR_ELT, dl, TmpEltVT, RHS, + DAG.getIntPtrConstant(i)); + Ops[i] = DAG.getNode(ISD::SETCC, dl, TLI.getSetCCResultType(TmpEltVT), + LHSElem, RHSElem, CC); + Ops[i] = DAG.getNode(ISD::SELECT, dl, EltVT, Ops[i], + DAG.getConstant(APInt::getAllOnesValue + (EltVT.getSizeInBits()), EltVT), + DAG.getConstant(0, EltVT)); + } + return DAG.getNode(ISD::BUILD_VECTOR, dl, VT, &Ops[0], NumElems); +} + +/// UnrollVectorOp - We know that the given vector has a legal type, however +/// the operation it performs is not legal, and the target has requested that +/// the operation be expanded. "Unroll" the vector, splitting out the scalars +/// and operating on each element individually. +SDValue VectorLegalizer::UnrollVectorOp(SDValue Op) { + MVT VT = Op.getValueType(); + assert(Op.getNode()->getNumValues() == 1 && + "Can't unroll a vector with multiple results!"); + unsigned NE = VT.getVectorNumElements(); + MVT EltVT = VT.getVectorElementType(); + DebugLoc dl = Op.getDebugLoc(); + + SmallVector Scalars; + SmallVector Operands(Op.getNumOperands()); + for (unsigned i = 0; i != NE; ++i) { + for (unsigned j = 0; j != Op.getNumOperands(); ++j) { + SDValue Operand = Op.getOperand(j); + MVT OperandVT = Operand.getValueType(); + if (OperandVT.isVector()) { + // A vector operand; extract a single element. + MVT OperandEltVT = OperandVT.getVectorElementType(); + Operands[j] = DAG.getNode(ISD::EXTRACT_VECTOR_ELT, dl, + OperandEltVT, + Operand, + DAG.getConstant(i, MVT::i32)); + } else { + // A scalar operand; just use it as is. + Operands[j] = Operand; + } + } + + switch (Op.getOpcode()) { + default: + Scalars.push_back(DAG.getNode(Op.getOpcode(), dl, EltVT, + &Operands[0], Operands.size())); + break; + case ISD::SHL: + case ISD::SRA: + case ISD::SRL: + case ISD::ROTL: + case ISD::ROTR: + Scalars.push_back(DAG.getNode(Op.getOpcode(), dl, EltVT, Operands[0], + DAG.getShiftAmountOperand(Operands[1]))); + break; + } + } + + return DAG.getNode(ISD::BUILD_VECTOR, dl, VT, &Scalars[0], Scalars.size()); +} + +} + +bool SelectionDAG::LegalizeVectors() { + return VectorLegalizer(*this).Run(); +} Index: lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (revision 72159) +++ lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (working copy) @@ -70,11 +70,6 @@ /// being legalized (which could lead to non-serialized call sequences). bool IsLegalizingCall; - /// IsLegalizingCallArguments - This member is used only for the purpose - /// of providing assert to check for LegalizeTypes because legalizing an - /// operation might introduce call nodes that might need type legalization. - bool IsLegalizingCallArgs; - enum LegalizeAction { Legal, // The target natively supports this operation. Promote, // This operation should be executed in a larger type. @@ -91,51 +86,12 @@ /// allows us to avoid legalizing the same thing more than once. DenseMap LegalizedNodes; - /// PromotedNodes - For nodes that are below legal width, and that have more - /// than one use, this map indicates what promoted value to use. This allows - /// us to avoid promoting the same thing more than once. - DenseMap PromotedNodes; - - /// ExpandedNodes - For nodes that need to be expanded this map indicates - /// which operands are the expanded version of the input. This allows - /// us to avoid expanding the same node more than once. - DenseMap > ExpandedNodes; - - /// SplitNodes - For vector nodes that need to be split, this map indicates - /// which operands are the split version of the input. This allows us - /// to avoid splitting the same node more than once. - std::map > SplitNodes; - - /// ScalarizedNodes - For nodes that need to be converted from vector types to - /// scalar types, this contains the mapping of ones we have already - /// processed to the result. - std::map ScalarizedNodes; - - /// WidenNodes - For nodes that need to be widened from one vector type to - /// another, this contains the mapping of those that we have already widen. - /// This allows us to avoid widening more than once. - std::map WidenNodes; - void AddLegalizedOperand(SDValue From, SDValue To) { LegalizedNodes.insert(std::make_pair(From, To)); // If someone requests legalization of the new node, return itself. if (From != To) LegalizedNodes.insert(std::make_pair(To, To)); } - void AddPromotedOperand(SDValue From, SDValue To) { - bool isNew = PromotedNodes.insert(std::make_pair(From, To)).second; - assert(isNew && "Got into the map somehow?"); - isNew = isNew; - // If someone requests legalization of the new node, return itself. - LegalizedNodes.insert(std::make_pair(To, To)); - } - void AddWidenedOperand(SDValue From, SDValue To) { - bool isNew = WidenNodes.insert(std::make_pair(From, To)).second; - assert(isNew && "Got into the map somehow?"); - isNew = isNew; - // If someone requests legalization of the new node, return itself. - LegalizedNodes.insert(std::make_pair(To, To)); - } public: explicit SelectionDAGLegalize(SelectionDAG &DAG, bool TypesNeedLegalizing, @@ -157,21 +113,11 @@ void LegalizeDAG(); private: - /// HandleOp - Legalize, Promote, or Expand the specified operand as - /// appropriate for its type. - void HandleOp(SDValue Op); - /// LegalizeOp - We know that the specified value has a legal type. /// Recursively ensure that the operands have legal types, then return the /// result. SDValue LegalizeOp(SDValue O); - /// UnrollVectorOp - We know that the given vector has a legal type, however - /// the operation it performs is not legal and is an operation that we have - /// no way of lowering. "Unroll" the vector, splitting out the scalars and - /// operating on each element individually. - SDValue UnrollVectorOp(SDValue O); - /// PerformInsertVectorEltInMemory - Some target cannot handle a variable /// insertion index for the INSERT_VECTOR_ELT instruction. In this case, it /// is necessary to spill the vector being inserted into to memory, perform @@ -179,94 +125,9 @@ SDValue PerformInsertVectorEltInMemory(SDValue Vec, SDValue Val, SDValue Idx, DebugLoc dl); - /// PromoteOp - Given an operation that produces a value in an invalid type, - /// promote it to compute the value into a larger type. The produced value - /// will have the correct bits for the low portion of the register, but no - /// guarantee is made about the top bits: it may be zero, sign-extended, or - /// garbage. - SDValue PromoteOp(SDValue O); - - /// ExpandOp - Expand the specified SDValue into its two component pieces - /// Lo&Hi. Note that the Op MUST be an expanded type. As a result of this, - /// the LegalizedNodes map is filled in for any results that are not expanded, - /// the ExpandedNodes map is filled in for any results that are expanded, and - /// the Lo/Hi values are returned. This applies to integer types and Vector - /// types. - void ExpandOp(SDValue O, SDValue &Lo, SDValue &Hi); - - /// WidenVectorOp - Widen a vector operation to a wider type given by WidenVT - /// (e.g., v3i32 to v4i32). The produced value will have the correct value - /// for the existing elements but no guarantee is made about the new elements - /// at the end of the vector: it may be zero, ones, or garbage. This is useful - /// when we have an instruction operating on an illegal vector type and we - /// want to widen it to do the computation on a legal wider vector type. - SDValue WidenVectorOp(SDValue Op, MVT WidenVT); - - /// SplitVectorOp - Given an operand of vector type, break it down into - /// two smaller values. - void SplitVectorOp(SDValue O, SDValue &Lo, SDValue &Hi); - - /// ScalarizeVectorOp - Given an operand of single-element vector type - /// (e.g. v1f32), convert it into the equivalent operation that returns a - /// scalar (e.g. f32) value. - SDValue ScalarizeVectorOp(SDValue O); - /// Useful 16 element vector type that is used to pass operands for widening. typedef SmallVector SDValueVector; - /// LoadWidenVectorOp - Load a vector for a wider type. Returns true if - /// the LdChain contains a single load and false if it contains a token - /// factor for multiple loads. It takes - /// Result: location to return the result - /// LdChain: location to return the load chain - /// Op: load operation to widen - /// NVT: widen vector result type we want for the load - bool LoadWidenVectorOp(SDValue& Result, SDValue& LdChain, - SDValue Op, MVT NVT); - - /// Helper genWidenVectorLoads - Helper function to generate a set of - /// loads to load a vector with a resulting wider type. It takes - /// LdChain: list of chains for the load we have generated - /// Chain: incoming chain for the ld vector - /// BasePtr: base pointer to load from - /// SV: memory disambiguation source value - /// SVOffset: memory disambiugation offset - /// Alignment: alignment of the memory - /// isVolatile: volatile load - /// LdWidth: width of memory that we want to load - /// ResType: the wider result result type for the resulting loaded vector - SDValue genWidenVectorLoads(SDValueVector& LdChain, SDValue Chain, - SDValue BasePtr, const Value *SV, - int SVOffset, unsigned Alignment, - bool isVolatile, unsigned LdWidth, - MVT ResType, DebugLoc dl); - - /// StoreWidenVectorOp - Stores a widen vector into non widen memory - /// location. It takes - /// ST: store node that we want to replace - /// Chain: incoming store chain - /// BasePtr: base address of where we want to store into - SDValue StoreWidenVectorOp(StoreSDNode *ST, SDValue Chain, - SDValue BasePtr); - - /// Helper genWidenVectorStores - Helper function to generate a set of - /// stores to store a widen vector into non widen memory - // It takes - // StChain: list of chains for the stores we have generated - // Chain: incoming chain for the ld vector - // BasePtr: base pointer to load from - // SV: memory disambiguation source value - // SVOffset: memory disambiugation offset - // Alignment: alignment of the memory - // isVolatile: volatile lod - // ValOp: value to store - // StWidth: width of memory that we want to store - void genWidenVectorStores(SDValueVector& StChain, SDValue Chain, - SDValue BasePtr, const Value *SV, - int SVOffset, unsigned Alignment, - bool isVolatile, SDValue ValOp, - unsigned StWidth, DebugLoc dl); - /// ShuffleWithNarrowerEltType - Return a vector shuffle operation which /// performs the same shuffe in terms of order or result bytes, but on a type /// whose vector element type is narrower than the original shuffle type. @@ -278,19 +139,17 @@ bool LegalizeAllNodesNotLeadingTo(SDNode *N, SDNode *Dest, SmallPtrSet &NodesLeadingTo); - void LegalizeSetCCOperands(SDValue &LHS, SDValue &RHS, SDValue &CC, - DebugLoc dl); void LegalizeSetCCCondCode(MVT VT, SDValue &LHS, SDValue &RHS, SDValue &CC, DebugLoc dl); void LegalizeSetCC(MVT VT, SDValue &LHS, SDValue &RHS, SDValue &CC, DebugLoc dl) { - LegalizeSetCCOperands(LHS, RHS, CC, dl); + LHS = LegalizeOp(LHS); + RHS = LegalizeOp(RHS); LegalizeSetCCCondCode(VT, LHS, RHS, CC, dl); } SDValue ExpandLibCall(RTLIB::Libcall LC, SDNode *Node, bool isSigned, SDValue &Hi); - SDValue ExpandIntToFP(bool isSigned, MVT DestTy, SDValue Source, DebugLoc dl); SDValue EmitStackConvert(SDValue SrcOp, MVT SlotVT, MVT DestVT, DebugLoc dl); SDValue ExpandBUILD_VECTOR(SDNode *Node); @@ -306,12 +165,7 @@ SDValue ExpandBSWAP(SDValue Op, DebugLoc dl); SDValue ExpandBitCount(unsigned Opc, SDValue Op, DebugLoc dl); - bool ExpandShift(unsigned Opc, SDValue Op, SDValue Amt, - SDValue &Lo, SDValue &Hi, DebugLoc dl); - void ExpandShiftParts(unsigned NodeOp, SDValue Op, SDValue Amt, - SDValue &Lo, SDValue &Hi, DebugLoc dl); - SDValue ExpandEXTRACT_SUBVECTOR(SDValue Op); SDValue ExpandEXTRACT_VECTOR_ELT(SDValue Op); }; } @@ -360,7 +214,6 @@ void SelectionDAGLegalize::LegalizeDAG() { LastCALLSEQ_END = DAG.getEntryNode(); IsLegalizingCall = false; - IsLegalizingCallArgs = false; // The legalize process is inherently a bottom-up recursive process (users // legalize their uses before themselves). Given infinite stack space, we @@ -371,19 +224,14 @@ DAG.AssignTopologicalOrder(); for (SelectionDAG::allnodes_iterator I = DAG.allnodes_begin(), E = prior(DAG.allnodes_end()); I != next(E); ++I) - HandleOp(SDValue(I, 0)); + LegalizeOp(SDValue(I, 0)); // Finally, it's possible the root changed. Get the new root. SDValue OldRoot = DAG.getRoot(); assert(LegalizedNodes.count(OldRoot) && "Root didn't get legalized?"); DAG.setRoot(LegalizedNodes[OldRoot]); - ExpandedNodes.clear(); LegalizedNodes.clear(); - PromotedNodes.clear(); - SplitNodes.clear(); - ScalarizedNodes.clear(); - WidenNodes.clear(); // Remove dead nodes now. DAG.RemoveDeadNodes(); @@ -458,17 +306,7 @@ // If the first result of this node has been already legalized, then it cannot // reach N. - switch (getTypeAction(N->getValueType(0))) { - case Legal: - if (LegalizedNodes.count(SDValue(N, 0))) return false; - break; - case Promote: - if (PromotedNodes.count(SDValue(N, 0))) return false; - break; - case Expand: - if (ExpandedNodes.count(SDValue(N, 0))) return false; - break; - } + if (LegalizedNodes.count(SDValue(N, 0))) return false; // Okay, this node has not already been legalized. Check and legalize all // operands. If none lead to Dest, then we can legalize this node. @@ -483,59 +321,10 @@ } // Okay, this node looks safe, legalize it and return false. - HandleOp(SDValue(N, 0)); + LegalizeOp(SDValue(N, 0)); return false; } -/// HandleOp - Legalize, Promote, Widen, or Expand the specified operand as -/// appropriate for its type. -void SelectionDAGLegalize::HandleOp(SDValue Op) { - MVT VT = Op.getValueType(); - // If the type legalizer was run then we should never see any illegal result - // types here except for target constants (the type legalizer does not touch - // those) or for build vector used as a mask for a vector shuffle. - assert((TypesNeedLegalizing || getTypeAction(VT) == Legal || - IsLegalizingCallArgs || Op.getOpcode() == ISD::TargetConstant) && - "Illegal type introduced after type legalization?"); - switch (getTypeAction(VT)) { - default: assert(0 && "Bad type action!"); - case Legal: (void)LegalizeOp(Op); break; - case Promote: - if (!VT.isVector()) { - (void)PromoteOp(Op); - break; - } - else { - // See if we can widen otherwise use Expand to either scalarize or split - MVT WidenVT = TLI.getWidenVectorType(VT); - if (WidenVT != MVT::Other) { - (void) WidenVectorOp(Op, WidenVT); - break; - } - // else fall thru to expand since we can't widen the vector - } - case Expand: - if (!VT.isVector()) { - // If this is an illegal scalar, expand it into its two component - // pieces. - SDValue X, Y; - if (Op.getOpcode() == ISD::TargetConstant) - break; // Allow illegal target nodes. - ExpandOp(Op, X, Y); - } else if (VT.getVectorNumElements() == 1) { - // If this is an illegal single element vector, convert it to a - // scalar operation. - (void)ScalarizeVectorOp(Op); - } else { - // This is an illegal multiple element vector. - // Split it in half and legalize both parts. - SDValue X, Y; - SplitVectorOp(Op, X, Y); - } - break; - } -} - /// ExpandConstantFP - Expands the ConstantFP node to an integer constant or /// a load from the constant pool. static SDValue ExpandConstantFP(ConstantFPSDNode *CFP, bool UseCP, @@ -866,58 +655,6 @@ return DAG.getMergeValues(Ops, 2, dl); } -/// UnrollVectorOp - We know that the given vector has a legal type, however -/// the operation it performs is not legal and is an operation that we have -/// no way of lowering. "Unroll" the vector, splitting out the scalars and -/// operating on each element individually. -SDValue SelectionDAGLegalize::UnrollVectorOp(SDValue Op) { - MVT VT = Op.getValueType(); - assert(isTypeLegal(VT) && - "Caller should expand or promote operands that are not legal!"); - assert(Op.getNode()->getNumValues() == 1 && - "Can't unroll a vector with multiple results!"); - unsigned NE = VT.getVectorNumElements(); - MVT EltVT = VT.getVectorElementType(); - DebugLoc dl = Op.getDebugLoc(); - - SmallVector Scalars; - SmallVector Operands(Op.getNumOperands()); - for (unsigned i = 0; i != NE; ++i) { - for (unsigned j = 0; j != Op.getNumOperands(); ++j) { - SDValue Operand = Op.getOperand(j); - MVT OperandVT = Operand.getValueType(); - if (OperandVT.isVector()) { - // A vector operand; extract a single element. - MVT OperandEltVT = OperandVT.getVectorElementType(); - Operands[j] = DAG.getNode(ISD::EXTRACT_VECTOR_ELT, dl, - OperandEltVT, - Operand, - DAG.getConstant(i, MVT::i32)); - } else { - // A scalar operand; just use it as is. - Operands[j] = Operand; - } - } - - switch (Op.getOpcode()) { - default: - Scalars.push_back(DAG.getNode(Op.getOpcode(), dl, EltVT, - &Operands[0], Operands.size())); - break; - case ISD::SHL: - case ISD::SRA: - case ISD::SRL: - case ISD::ROTL: - case ISD::ROTR: - Scalars.push_back(DAG.getNode(Op.getOpcode(), dl, EltVT, Operands[0], - DAG.getShiftAmountOperand(Operands[1]))); - break; - } - } - - return DAG.getNode(ISD::BUILD_VECTOR, dl, VT, &Scalars[0], Scalars.size()); -} - /// GetFPLibCall - Return the right libcall for the given floating point type. static RTLIB::Libcall GetFPLibCall(MVT VT, RTLIB::Libcall Call_F32, @@ -985,21 +722,14 @@ if (Op.getOpcode() == ISD::TargetConstant) // Allow illegal target nodes. return Op; - assert(isTypeLegal(Op.getValueType()) && - "Caller should expand or promote operands that are not legal!"); SDNode *Node = Op.getNode(); DebugLoc dl = Node->getDebugLoc(); // If this operation defines any values that cannot be represented in a // register on this target, make sure to expand or promote them. - if (Node->getNumValues() > 1) { - for (unsigned i = 0, e = Node->getNumValues(); i != e; ++i) - if (getTypeAction(Node->getValueType(i)) != Legal) { - HandleOp(Op.getValue(i)); - assert(LegalizedNodes.count(Op) && - "Handling didn't add legal operands!"); - return LegalizedNodes[Op]; - } + for (unsigned i = 0, e = Node->getNumValues(); i != e; ++i) + assert(getTypeAction(Node->getValueType(i)) == Legal && + "Unexpected illegal type!"); { } // Note that LegalizeOp may be reentered even from single-use nodes, which @@ -1298,20 +1028,13 @@ if (Result.getNode()) break; case TargetLowering::Legal: { - LegalizeAction Action = getTypeAction(Node->getOperand(1).getValueType()); - if (Action == Legal && Tmp1 == Node->getOperand(0)) + if (Tmp1 == Node->getOperand(0)) break; SmallVector Ops; Ops.push_back(Tmp1); - if (Action == Legal) { - Ops.push_back(Node->getOperand(1)); // line # must be legal. - Ops.push_back(Node->getOperand(2)); // col # must be legal. - } else { - // Otherwise promote them. - Ops.push_back(PromoteOp(Node->getOperand(1))); - Ops.push_back(PromoteOp(Node->getOperand(2))); - } + Ops.push_back(Node->getOperand(1)); // line # must be legal. + Ops.push_back(Node->getOperand(2)); // col # must be legal. Ops.push_back(Node->getOperand(3)); // filename must be legal. Ops.push_back(Node->getOperand(4)); // working dir # must be legal. Result = DAG.UpdateNodeOperands(Result, &Ops[0], Ops.size()); @@ -1341,19 +1064,12 @@ switch (TLI.getOperationAction(ISD::DEBUG_LOC, MVT::Other)) { default: assert(0 && "This action is not supported yet!"); case TargetLowering::Legal: { - LegalizeAction Action = getTypeAction(Node->getOperand(1).getValueType()); Tmp1 = LegalizeOp(Node->getOperand(0)); // Legalize the chain. - if (Action == Legal && Tmp1 == Node->getOperand(0)) + if (Tmp1 == Node->getOperand(0)) break; - if (Action == Legal) { - Tmp2 = Node->getOperand(1); - Tmp3 = Node->getOperand(2); - Tmp4 = Node->getOperand(3); - } else { - Tmp2 = LegalizeOp(Node->getOperand(1)); // Legalize the line #. - Tmp3 = LegalizeOp(Node->getOperand(2)); // Legalize the col #. - Tmp4 = LegalizeOp(Node->getOperand(3)); // Legalize the source file id. - } + Tmp2 = Node->getOperand(1); + Tmp3 = Node->getOperand(2); + Tmp4 = Node->getOperand(3); Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2, Tmp3, Tmp4); break; } @@ -1402,8 +1118,6 @@ Ops[0] = LegalizeOp(Node->getOperand(0)); // Legalize the chain. for (int x = 1; x < 6; ++x) { Ops[x] = Node->getOperand(x); - if (!isTypeLegal(Ops[x].getValueType())) - Ops[x] = PromoteOp(Ops[x]); } Result = DAG.UpdateNodeOperands(Result, &Ops[0], 6); break; @@ -1590,17 +1304,7 @@ // The type of the value to insert may not be legal, even though the vector // type is legal. Legalize/Promote accordingly. We do not handle Expand // here. - switch (getTypeAction(Node->getOperand(1).getValueType())) { - default: assert(0 && "Cannot expand insert element operand"); - case Legal: Tmp2 = LegalizeOp(Node->getOperand(1)); break; - case Promote: Tmp2 = PromoteOp(Node->getOperand(1)); break; - case Expand: - // FIXME: An alternative would be to check to see if the target is not - // going to custom lower this operation, we could bitcast to half elt - // width and perform two inserts at that width, if that is legal. - Tmp2 = Node->getOperand(1); - break; - } + Tmp2 = LegalizeOp(Node->getOperand(1)); Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2, Tmp3); switch (TLI.getOperationAction(ISD::INSERT_VECTOR_ELT, @@ -1650,11 +1354,6 @@ } break; case ISD::SCALAR_TO_VECTOR: - if (!TLI.isTypeLegal(Node->getOperand(0).getValueType())) { - Result = LegalizeOp(ExpandSCALAR_TO_VECTOR(Node)); - break; - } - Tmp1 = LegalizeOp(Node->getOperand(0)); // InVal Result = DAG.UpdateNodeOperands(Result, Tmp1); switch (TLI.getOperationAction(ISD::SCALAR_TO_VECTOR, @@ -1746,7 +1445,9 @@ Tmp1 = Node->getOperand(0); Tmp2 = LegalizeOp(Node->getOperand(1)); Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2); - Result = ExpandEXTRACT_SUBVECTOR(Result); + assert(TLI.isOperationLegal(ISD::EXTRACT_SUBVECTOR, + Node->getValueType(0)) && + "Don't know how to legalize extract_subvector!"); break; case ISD::CONCAT_VECTORS: { @@ -1798,13 +1499,11 @@ // Recursively Legalize all of the inputs of the call end that do not lead // to this call start. This ensures that any libcalls that need be inserted // are inserted *before* the CALLSEQ_START. - IsLegalizingCallArgs = true; {SmallPtrSet NodesLeadingTo; for (unsigned i = 0, e = CallEnd->getNumOperands(); i != e; ++i) LegalizeAllNodesNotLeadingTo(CallEnd->getOperand(i).getNode(), Node, NodesLeadingTo); } - IsLegalizingCallArgs = false; // Now that we legalized all of the inputs (which may have inserted // libcalls) create the new CALLSEQ_START node. @@ -1994,12 +1693,7 @@ Tmp1 = LegalizeOp(Tmp1); LastCALLSEQ_END = DAG.getEntryNode(); - switch (getTypeAction(Node->getOperand(1).getValueType())) { - default: assert(0 && "Indirect target must be legal type (pointer)!"); - case Legal: - Tmp2 = LegalizeOp(Node->getOperand(1)); // Legalize the condition. - break; - } + Tmp2 = LegalizeOp(Node->getOperand(1)); // Legalize the condition. Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2); break; case ISD::BR_JT: @@ -2053,24 +1747,8 @@ Tmp1 = LegalizeOp(Tmp1); LastCALLSEQ_END = DAG.getEntryNode(); - switch (getTypeAction(Node->getOperand(1).getValueType())) { - case Expand: assert(0 && "It's impossible to expand bools"); - case Legal: - Tmp2 = LegalizeOp(Node->getOperand(1)); // Legalize the condition. - break; - case Promote: { - Tmp2 = PromoteOp(Node->getOperand(1)); // Promote the condition. + Tmp2 = LegalizeOp(Node->getOperand(1)); // Legalize the condition. - // The top bits of the promoted condition are not necessarily zero, ensure - // that the value is properly zero extended. - unsigned BitWidth = Tmp2.getValueSizeInBits(); - if (!DAG.MaskedValueIsZero(Tmp2, - APInt::getHighBitsSet(BitWidth, BitWidth-1))) - Tmp2 = DAG.getZeroExtendInReg(Tmp2, dl, MVT::i1); - break; - } - } - // Basic block destination (Op#2) is always legal. Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2, Node->getOperand(2)); @@ -2386,29 +2064,16 @@ } case ISD::EXTRACT_ELEMENT: { MVT OpTy = Node->getOperand(0).getValueType(); - switch (getTypeAction(OpTy)) { - default: assert(0 && "EXTRACT_ELEMENT action for type unimplemented!"); - case Legal: - if (cast(Node->getOperand(1))->getZExtValue()) { - // 1 -> Hi - Result = DAG.getNode(ISD::SRL, dl, OpTy, Node->getOperand(0), - DAG.getConstant(OpTy.getSizeInBits()/2, - TLI.getShiftAmountTy())); - Result = DAG.getNode(ISD::TRUNCATE, dl, Node->getValueType(0), Result); - } else { - // 0 -> Lo - Result = DAG.getNode(ISD::TRUNCATE, dl, Node->getValueType(0), - Node->getOperand(0)); - } - break; - case Expand: - // Get both the low and high parts. - ExpandOp(Node->getOperand(0), Tmp1, Tmp2); - if (cast(Node->getOperand(1))->getZExtValue()) - Result = Tmp2; // 1 -> Hi - else - Result = Tmp1; // 0 -> Lo - break; + if (cast(Node->getOperand(1))->getZExtValue()) { + // 1 -> Hi + Result = DAG.getNode(ISD::SRL, dl, OpTy, Node->getOperand(0), + DAG.getConstant(OpTy.getSizeInBits()/2, + TLI.getShiftAmountTy())); + Result = DAG.getNode(ISD::TRUNCATE, dl, Node->getValueType(0), Result); + } else { + // 0 -> Lo + Result = DAG.getNode(ISD::TRUNCATE, dl, Node->getValueType(0), + Node->getOperand(0)); } break; } @@ -2452,67 +2117,7 @@ case 3: // ret val Tmp2 = Node->getOperand(1); Tmp3 = Node->getOperand(2); // Signness - switch (getTypeAction(Tmp2.getValueType())) { - case Legal: - Result = DAG.UpdateNodeOperands(Result, Tmp1, LegalizeOp(Tmp2), Tmp3); - break; - case Expand: - if (!Tmp2.getValueType().isVector()) { - SDValue Lo, Hi; - ExpandOp(Tmp2, Lo, Hi); - - // Big endian systems want the hi reg first. - if (TLI.isBigEndian()) - std::swap(Lo, Hi); - - if (Hi.getNode()) - Result = DAG.getNode(ISD::RET, dl, MVT::Other, - Tmp1, Lo, Tmp3, Hi, Tmp3); - else - Result = DAG.getNode(ISD::RET, dl, MVT::Other, Tmp1, Lo, Tmp3); - Result = LegalizeOp(Result); - } else { - SDNode *InVal = Tmp2.getNode(); - int InIx = Tmp2.getResNo(); - unsigned NumElems = InVal->getValueType(InIx).getVectorNumElements(); - MVT EVT = InVal->getValueType(InIx).getVectorElementType(); - - // Figure out if there is a simple type corresponding to this Vector - // type. If so, convert to the vector type. - MVT TVT = MVT::getVectorVT(EVT, NumElems); - if (TLI.isTypeLegal(TVT)) { - // Turn this into a return of the vector type. - Tmp2 = LegalizeOp(Tmp2); - Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2, Tmp3); - } else if (NumElems == 1) { - // Turn this into a return of the scalar type. - Tmp2 = ScalarizeVectorOp(Tmp2); - Tmp2 = LegalizeOp(Tmp2); - Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2, Tmp3); - - // FIXME: Returns of gcc generic vectors smaller than a legal type - // should be returned in integer registers! - - // The scalarized value type may not be legal, e.g. it might require - // promotion or expansion. Relegalize the return. - Result = LegalizeOp(Result); - } else { - // FIXME: Returns of gcc generic vectors larger than a legal vector - // type should be returned by reference! - SDValue Lo, Hi; - SplitVectorOp(Tmp2, Lo, Hi); - Result = DAG.getNode(ISD::RET, dl, MVT::Other, - Tmp1, Lo, Tmp3, Hi, Tmp3); - Result = LegalizeOp(Result); - } - } - break; - case Promote: - Tmp2 = PromoteOp(Node->getOperand(1)); - Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2, Tmp3); - Result = LegalizeOp(Result); - break; - } + Result = DAG.UpdateNodeOperands(Result, Tmp1, LegalizeOp(Tmp2), Tmp3); break; case 1: // ret void Result = DAG.UpdateNodeOperands(Result, Tmp1); @@ -2520,34 +2125,12 @@ default: { // ret SmallVector NewValues; NewValues.push_back(Tmp1); - for (unsigned i = 1, e = Node->getNumOperands(); i < e; i += 2) - switch (getTypeAction(Node->getOperand(i).getValueType())) { - case Legal: - NewValues.push_back(LegalizeOp(Node->getOperand(i))); - NewValues.push_back(Node->getOperand(i+1)); - break; - case Expand: { - SDValue Lo, Hi; - assert(!Node->getOperand(i).getValueType().isExtended() && - "FIXME: TODO: implement returning non-legal vector types!"); - ExpandOp(Node->getOperand(i), Lo, Hi); - NewValues.push_back(Lo); - NewValues.push_back(Node->getOperand(i+1)); - if (Hi.getNode()) { - NewValues.push_back(Hi); - NewValues.push_back(Node->getOperand(i+1)); - } - break; - } - case Promote: - assert(0 && "Can't promote multiple return value yet!"); - } + for (unsigned i = 1, e = Node->getNumOperands(); i < e; i += 2) { + NewValues.push_back(LegalizeOp(Node->getOperand(i))); + NewValues.push_back(Node->getOperand(i+1)); + } - if (NewValues.size() == Node->getNumOperands()) - Result = DAG.UpdateNodeOperands(Result, &NewValues[0],NewValues.size()); - else - Result = DAG.getNode(ISD::RET, dl, MVT::Other, - &NewValues[0], NewValues.size()); + Result = DAG.UpdateNodeOperands(Result, &NewValues[0],NewValues.size()); break; } } @@ -2618,8 +2201,7 @@ } } - switch (getTypeAction(ST->getMemoryVT())) { - case Legal: { + { Tmp3 = LegalizeOp(ST->getValue()); Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp3, Tmp2, ST->getOffset()); @@ -2653,111 +2235,8 @@ } break; } - case Promote: - if (!ST->getMemoryVT().isVector()) { - // Truncate the value and store the result. - Tmp3 = PromoteOp(ST->getValue()); - Result = DAG.getTruncStore(Tmp1, dl, Tmp3, Tmp2, ST->getSrcValue(), - SVOffset, ST->getMemoryVT(), - isVolatile, Alignment); - break; - } - // Fall thru to expand for vector - case Expand: { - unsigned IncrementSize = 0; - SDValue Lo, Hi; - - // If this is a vector type, then we have to calculate the increment as - // the product of the element size in bytes, and the number of elements - // in the high half of the vector. - if (ST->getValue().getValueType().isVector()) { - SDNode *InVal = ST->getValue().getNode(); - int InIx = ST->getValue().getResNo(); - MVT InVT = InVal->getValueType(InIx); - unsigned NumElems = InVT.getVectorNumElements(); - MVT EVT = InVT.getVectorElementType(); - - // Figure out if there is a simple type corresponding to this Vector - // type. If so, convert to the vector type. - MVT TVT = MVT::getVectorVT(EVT, NumElems); - if (TLI.isTypeLegal(TVT)) { - // Turn this into a normal store of the vector type. - Tmp3 = LegalizeOp(ST->getValue()); - Result = DAG.getStore(Tmp1, dl, Tmp3, Tmp2, ST->getSrcValue(), - SVOffset, isVolatile, Alignment); - Result = LegalizeOp(Result); - break; - } else if (NumElems == 1) { - // Turn this into a normal store of the scalar type. - Tmp3 = ScalarizeVectorOp(ST->getValue()); - Result = DAG.getStore(Tmp1, dl, Tmp3, Tmp2, ST->getSrcValue(), - SVOffset, isVolatile, Alignment); - // The scalarized value type may not be legal, e.g. it might require - // promotion or expansion. Relegalize the scalar store. - Result = LegalizeOp(Result); - break; - } else { - // Check if we have widen this node with another value - std::map::iterator I = - WidenNodes.find(ST->getValue()); - if (I != WidenNodes.end()) { - Result = StoreWidenVectorOp(ST, Tmp1, Tmp2); - break; - } - else { - SplitVectorOp(ST->getValue(), Lo, Hi); - IncrementSize = Lo.getNode()->getValueType(0).getVectorNumElements() * - EVT.getSizeInBits()/8; - } - } - } else { - ExpandOp(ST->getValue(), Lo, Hi); - IncrementSize = Hi.getNode() ? Hi.getValueType().getSizeInBits()/8 : 0; - - if (Hi.getNode() && TLI.isBigEndian()) - std::swap(Lo, Hi); - } - - Lo = DAG.getStore(Tmp1, dl, Lo, Tmp2, ST->getSrcValue(), - SVOffset, isVolatile, Alignment); - - if (Hi.getNode() == NULL) { - // Must be int <-> float one-to-one expansion. - Result = Lo; - break; - } - - Tmp2 = DAG.getNode(ISD::ADD, dl, Tmp2.getValueType(), Tmp2, - DAG.getIntPtrConstant(IncrementSize)); - assert(isTypeLegal(Tmp2.getValueType()) && - "Pointers must be legal!"); - SVOffset += IncrementSize; - Alignment = MinAlign(Alignment, IncrementSize); - Hi = DAG.getStore(Tmp1, dl, Hi, Tmp2, ST->getSrcValue(), - SVOffset, isVolatile, Alignment); - Result = DAG.getNode(ISD::TokenFactor, dl, MVT::Other, Lo, Hi); - break; - } // case Expand - } } else { - switch (getTypeAction(ST->getValue().getValueType())) { - case Legal: - Tmp3 = LegalizeOp(ST->getValue()); - break; - case Promote: - if (!ST->getValue().getValueType().isVector()) { - // We can promote the value, the truncstore will still take care of it. - Tmp3 = PromoteOp(ST->getValue()); - break; - } - // Vector case falls through to expand - case Expand: - // Just store the low part. This may become a non-trunc store, so make - // sure to use getTruncStore, not UpdateNodeOperands below. - ExpandOp(ST->getValue(), Tmp3, Tmp4); - return DAG.getTruncStore(Tmp1, dl, Tmp3, Tmp2, ST->getSrcValue(), - SVOffset, MVT::i8, isVolatile, Alignment); - } + Tmp3 = LegalizeOp(ST->getValue()); MVT StVT = ST->getMemoryVT(); unsigned StWidth = StVT.getSizeInBits(); @@ -2943,22 +2422,7 @@ return Result; case ISD::SELECT: - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Expand: assert(0 && "It's impossible to expand bools"); - case Legal: - Tmp1 = LegalizeOp(Node->getOperand(0)); // Legalize the condition. - break; - case Promote: { - assert(!Node->getOperand(0).getValueType().isVector() && "not possible"); - Tmp1 = PromoteOp(Node->getOperand(0)); // Promote the condition. - // Make sure the condition is either zero or one. - unsigned BitWidth = Tmp1.getValueSizeInBits(); - if (!DAG.MaskedValueIsZero(Tmp1, - APInt::getHighBitsSet(BitWidth, BitWidth-1))) - Tmp1 = DAG.getZeroExtendInReg(Tmp1, dl, MVT::i1); - break; - } - } + Tmp1 = LegalizeOp(Node->getOperand(0)); // Legalize the condition. Tmp2 = LegalizeOp(Node->getOperand(1)); // TrueVal Tmp3 = LegalizeOp(Node->getOperand(2)); // FalseVal @@ -3115,39 +2579,9 @@ SDValue CC = Node->getOperand(2); Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2, CC); - - // Everything is legal, see if we should expand this op or something. - switch (TLI.getOperationAction(ISD::VSETCC, Tmp1.getValueType())) { - default: assert(0 && "This action is not supported yet!"); - case TargetLowering::Legal: break; - case TargetLowering::Custom: - Tmp1 = TLI.LowerOperation(Result, DAG); - if (Tmp1.getNode()) Result = Tmp1; - break; - case TargetLowering::Expand: { - // Unroll into a nasty set of scalar code for now. - MVT VT = Node->getValueType(0); - unsigned NumElems = VT.getVectorNumElements(); - MVT EltVT = VT.getVectorElementType(); - MVT TmpEltVT = Tmp1.getValueType().getVectorElementType(); - SmallVector Ops(NumElems); - for (unsigned i = 0; i < NumElems; ++i) { - SDValue In1 = DAG.getNode(ISD::EXTRACT_VECTOR_ELT, dl, TmpEltVT, - Tmp1, DAG.getIntPtrConstant(i)); - Ops[i] = DAG.getNode(ISD::SETCC, dl, TLI.getSetCCResultType(TmpEltVT), - In1, DAG.getNode(ISD::EXTRACT_VECTOR_ELT, dl, - TmpEltVT, Tmp2, - DAG.getIntPtrConstant(i)), - CC); - Ops[i] = DAG.getNode(ISD::SELECT, dl, EltVT, Ops[i], - DAG.getConstant(APInt::getAllOnesValue - (EltVT.getSizeInBits()), EltVT), - DAG.getConstant(0, EltVT)); - } - Result = DAG.getNode(ISD::BUILD_VECTOR, dl, VT, &Ops[0], NumElems); - break; - } - } + + assert(TLI.isOperationLegal(ISD::VSETCC, Tmp1.getValueType()) && + "Illegal vector ops should be unrolled earlier!"); break; } @@ -3221,15 +2655,7 @@ !Node->getValueType(0).isVector()) Tmp2 = DAG.getShiftAmountOperand(Tmp2); - switch (getTypeAction(Tmp2.getValueType())) { - case Expand: assert(0 && "Not possible"); - case Legal: - Tmp2 = LegalizeOp(Tmp2); // Legalize the RHS. - break; - case Promote: - Tmp2 = PromoteOp(Tmp2); // Promote the RHS. - break; - } + Tmp2 = LegalizeOp(Tmp2); // Legalize the RHS. Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2); @@ -3348,10 +2774,7 @@ break; } - assert(Node->getValueType(0).isVector() && - "Cannot expand this binary operator!"); - // Expand the operation into a bunch of nasty scalar code. - Result = LegalizeOp(UnrollVectorOp(Op)); + assert(0 && "Cannot expand this binary operator!"); break; } case TargetLowering::Promote: { @@ -3392,15 +2815,7 @@ case ISD::FCOPYSIGN: // FCOPYSIGN does not require LHS/RHS to match type! Tmp1 = LegalizeOp(Node->getOperand(0)); // LHS - switch (getTypeAction(Node->getOperand(1).getValueType())) { - case Expand: assert(0 && "Not possible"); - case Legal: - Tmp2 = LegalizeOp(Node->getOperand(1)); // Legalize the RHS. - break; - case Promote: - Tmp2 = PromoteOp(Node->getOperand(1)); // Promote the RHS. - break; - } + Tmp2 = LegalizeOp(Node->getOperand(1)); // Legalize the RHS. Result = DAG.UpdateNodeOperands(Result, Tmp1, Tmp2); @@ -3503,7 +2918,6 @@ case ISD::BUILD_PAIR: { MVT PairTy = Node->getValueType(0); - // TODO: handle the case where the Lo and Hi operands are not of legal type Tmp1 = LegalizeOp(Node->getOperand(0)); // Lo Tmp2 = LegalizeOp(Node->getOperand(1)); // Hi switch (TLI.getOperationAction(ISD::BUILD_PAIR, PairTy)) { @@ -3601,10 +3015,7 @@ break; } - assert(VT.isVector() && - "Cannot expand this binary operator!"); - // Expand the operation into a bunch of nasty scalar code. - Result = LegalizeOp(UnrollVectorOp(Op)); + assert(0 && "Cannot expand this binary operator!"); break; } } @@ -3885,11 +3296,7 @@ case ISD::FNEARBYINT: { MVT VT = Node->getValueType(0); - // Expand unsupported unary vector operators by unrolling them. - if (VT.isVector()) { - Result = LegalizeOp(UnrollVectorOp(Op)); - break; - } + assert(!VT.isVector() && "Vector should be already expanded!"); RTLIB::Libcall LC = RTLIB::UNKNOWN_LIBCALL; switch(Node->getOpcode()) { @@ -3959,11 +3366,7 @@ case ISD::FPOWI: { MVT VT = Node->getValueType(0); - // Expand unsupported unary vector operators by unrolling them. - if (VT.isVector()) { - Result = LegalizeOp(UnrollVectorOp(Op)); - break; - } + assert(!VT.isVector() && "Vector should be already expanded!"); // We always lower FPOWI into a libcall. No target support for it yet. RTLIB::Libcall LC = GetFPLibCall(VT, RTLIB::POWI_F32, RTLIB::POWI_F64, @@ -3973,47 +3376,17 @@ break; } case ISD::BIT_CONVERT: - if (!isTypeLegal(Node->getOperand(0).getValueType())) { + switch (TLI.getOperationAction(ISD::BIT_CONVERT, + Node->getOperand(0).getValueType())) { + default: assert(0 && "Unknown operation action!"); + case TargetLowering::Expand: Result = EmitStackConvert(Node->getOperand(0), Node->getValueType(0), Node->getValueType(0), dl); - } else if (Op.getOperand(0).getValueType().isVector()) { - // The input has to be a vector type, we have to either scalarize it, pack - // it, or convert it based on whether the input vector type is legal. - SDNode *InVal = Node->getOperand(0).getNode(); - int InIx = Node->getOperand(0).getResNo(); - unsigned NumElems = InVal->getValueType(InIx).getVectorNumElements(); - MVT EVT = InVal->getValueType(InIx).getVectorElementType(); - - // Figure out if there is a simple type corresponding to this Vector - // type. If so, convert to the vector type. - MVT TVT = MVT::getVectorVT(EVT, NumElems); - if (TLI.isTypeLegal(TVT)) { - // Turn this into a bit convert of the vector input. - Tmp1 = LegalizeOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::BIT_CONVERT, dl, Node->getValueType(0), Tmp1); - break; - } else if (NumElems == 1) { - // Turn this into a bit convert of the scalar input. - Result = DAG.getNode(ISD::BIT_CONVERT, dl, Node->getValueType(0), - ScalarizeVectorOp(Node->getOperand(0))); - break; - } else { - // FIXME: UNIMP! Store then reload - assert(0 && "Cast from unsupported vector type not implemented yet!"); - } - } else { - switch (TLI.getOperationAction(ISD::BIT_CONVERT, - Node->getOperand(0).getValueType())) { - default: assert(0 && "Unknown operation action!"); - case TargetLowering::Expand: - Result = EmitStackConvert(Node->getOperand(0), Node->getValueType(0), - Node->getValueType(0), dl); - break; - case TargetLowering::Legal: - Tmp1 = LegalizeOp(Node->getOperand(0)); - Result = DAG.UpdateNodeOperands(Result, Tmp1); - break; - } + break; + case TargetLowering::Legal: + Tmp1 = LegalizeOp(Node->getOperand(0)); + Result = DAG.UpdateNodeOperands(Result, Tmp1); + break; } break; case ISD::CONVERT_RNDSAT: { @@ -4034,25 +3407,14 @@ SDValue STyOp = Node->getOperand(2); SDValue RndOp = Node->getOperand(3); SDValue SatOp = Node->getOperand(4); - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Expand: assert(0 && "Shouldn't need to expand other operators here!"); - case Legal: - Tmp1 = LegalizeOp(Node->getOperand(0)); - Result = DAG.UpdateNodeOperands(Result, Tmp1, DTyOp, STyOp, - RndOp, SatOp); - if (TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0)) == - TargetLowering::Custom) { - Tmp1 = TLI.LowerOperation(Result, DAG); - if (Tmp1.getNode()) Result = Tmp1; - } - break; - case Promote: - Result = PromoteOp(Node->getOperand(0)); - // For FP, make Op1 a i32 - - Result = DAG.getConvertRndSat(Op.getValueType(), dl, Result, - DTyOp, STyOp, RndOp, SatOp, CvtCode); - break; + + Tmp1 = LegalizeOp(Node->getOperand(0)); + Result = DAG.UpdateNodeOperands(Result, Tmp1, DTyOp, STyOp, + RndOp, SatOp); + if (TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0)) == + TargetLowering::Custom) { + Tmp1 = TLI.LowerOperation(Result, DAG); + if (Tmp1.getNode()) Result = Tmp1; } break; } @@ -4068,45 +3430,25 @@ break; } case ISD::TRUNCATE: - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Legal: - Tmp1 = LegalizeOp(Node->getOperand(0)); - switch (TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0))) { - default: assert(0 && "Unknown TRUNCATE legalization operation action!"); - case TargetLowering::Custom: - isCustom = true; - // FALLTHROUGH - case TargetLowering::Legal: - Result = DAG.UpdateNodeOperands(Result, Tmp1); - if (isCustom) { - Tmp1 = TLI.LowerOperation(Result, DAG); - if (Tmp1.getNode()) Result = Tmp1; - } - break; - case TargetLowering::Expand: - assert(Result.getValueType().isVector() && "must be vector type"); - // Unroll the truncate. We should do better. - Result = LegalizeOp(UnrollVectorOp(Result)); + Tmp1 = LegalizeOp(Node->getOperand(0)); + switch (TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0))) { + default: assert(0 && "Unknown TRUNCATE legalization operation action!"); + case TargetLowering::Custom: + isCustom = true; + // FALLTHROUGH + case TargetLowering::Legal: + Result = DAG.UpdateNodeOperands(Result, Tmp1); + if (isCustom) { + Tmp1 = TLI.LowerOperation(Result, DAG); + if (Tmp1.getNode()) Result = Tmp1; } break; - case Expand: - ExpandOp(Node->getOperand(0), Tmp1, Tmp2); - - // Since the result is legal, we should just be able to truncate the low - // part of the source. - Result = DAG.getNode(ISD::TRUNCATE, dl, Node->getValueType(0), Tmp1); - break; - case Promote: - Result = PromoteOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::TRUNCATE, dl, Op.getValueType(), Result); - break; } break; case ISD::FP_TO_SINT: case ISD::FP_TO_UINT: - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Legal: + { Tmp1 = LegalizeOp(Node->getOperand(0)); switch (TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0))){ @@ -4152,51 +3494,7 @@ } break; } - break; - case Expand: { - MVT VT = Op.getValueType(); - MVT OVT = Node->getOperand(0).getValueType(); - // Convert ppcf128 to i32 - if (OVT == MVT::ppcf128 && VT == MVT::i32) { - if (Node->getOpcode() == ISD::FP_TO_SINT) { - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, MVT::ppcf128, - Node->getOperand(0), DAG.getValueType(MVT::f64)); - Result = DAG.getNode(ISD::FP_ROUND, dl, MVT::f64, Result, - DAG.getIntPtrConstant(1)); - Result = DAG.getNode(ISD::FP_TO_SINT, dl, VT, Result); - } else { - const uint64_t TwoE31[] = {0x41e0000000000000LL, 0}; - APFloat apf = APFloat(APInt(128, 2, TwoE31)); - Tmp2 = DAG.getConstantFP(apf, OVT); - // X>=2^31 ? (int)(X-2^31)+0x80000000 : (int)X - // FIXME: generated code sucks. - Result = DAG.getNode(ISD::SELECT_CC, dl, VT, Node->getOperand(0), - Tmp2, - DAG.getNode(ISD::ADD, dl, MVT::i32, - DAG.getNode(ISD::FP_TO_SINT, dl, VT, - DAG.getNode(ISD::FSUB, dl, OVT, - Node->getOperand(0), Tmp2)), - DAG.getConstant(0x80000000, MVT::i32)), - DAG.getNode(ISD::FP_TO_SINT, dl, VT, - Node->getOperand(0)), - DAG.getCondCode(ISD::SETGE)); - } - break; - } - // Convert f32 / f64 to i32 / i64 / i128. - RTLIB::Libcall LC = (Node->getOpcode() == ISD::FP_TO_SINT) ? - RTLIB::getFPTOSINT(OVT, VT) : RTLIB::getFPTOUINT(OVT, VT); - assert(LC != RTLIB::UNKNOWN_LIBCALL && "Unexpectd fp-to-int conversion!"); - SDValue Dummy; - Result = ExpandLibCall(LC, Node, false/*sign irrelevant*/, Dummy); - break; } - case Promote: - Tmp1 = PromoteOp(Node->getOperand(0)); - Result = DAG.UpdateNodeOperands(Result, LegalizeOp(Tmp1)); - Result = LegalizeOp(Result); - break; - } break; case ISD::FP_EXTEND: { @@ -4208,17 +3506,8 @@ Result = EmitStackConvert(Node->getOperand(0), SrcVT, DstVT, dl); break; } - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Expand: assert(0 && "Shouldn't need to expand other operators here!"); - case Legal: - Tmp1 = LegalizeOp(Node->getOperand(0)); - Result = DAG.UpdateNodeOperands(Result, Tmp1); - break; - case Promote: - Tmp1 = PromoteOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::FP_EXTEND, dl, Op.getValueType(), Tmp1); - break; - } + Tmp1 = LegalizeOp(Node->getOperand(0)); + Result = DAG.UpdateNodeOperands(Result, Tmp1); break; } case ISD::FP_ROUND: { @@ -4226,67 +3515,27 @@ MVT SrcVT = Op.getOperand(0).getValueType(); if (TLI.getConvertAction(SrcVT, DstVT) == TargetLowering::Expand) { if (SrcVT == MVT::ppcf128) { - SDValue Lo; - ExpandOp(Node->getOperand(0), Lo, Result); - // Round it the rest of the way (e.g. to f32) if needed. - if (DstVT!=MVT::f64) - Result = DAG.getNode(ISD::FP_ROUND, dl, - DstVT, Result, Op.getOperand(1)); - break; + // FIXME: Figure out how to extract the double without + // help from type legalization } // The only other way we can lower this is to turn it into a STORE, // LOAD pair, targetting a temporary location (a stack slot). Result = EmitStackConvert(Node->getOperand(0), DstVT, DstVT, dl); break; } - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Expand: assert(0 && "Shouldn't need to expand other operators here!"); - case Legal: - Tmp1 = LegalizeOp(Node->getOperand(0)); - Result = DAG.UpdateNodeOperands(Result, Tmp1, Node->getOperand(1)); - break; - case Promote: - Tmp1 = PromoteOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::FP_ROUND, dl, Op.getValueType(), Tmp1, - Node->getOperand(1)); - break; - } + Tmp1 = LegalizeOp(Node->getOperand(0)); + Result = DAG.UpdateNodeOperands(Result, Tmp1, Node->getOperand(1)); break; } case ISD::ANY_EXTEND: case ISD::ZERO_EXTEND: case ISD::SIGN_EXTEND: - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Expand: assert(0 && "Shouldn't need to expand other operators here!"); - case Legal: - Tmp1 = LegalizeOp(Node->getOperand(0)); - Result = DAG.UpdateNodeOperands(Result, Tmp1); - if (TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0)) == - TargetLowering::Custom) { - Tmp1 = TLI.LowerOperation(Result, DAG); - if (Tmp1.getNode()) Result = Tmp1; - } - break; - case Promote: - switch (Node->getOpcode()) { - case ISD::ANY_EXTEND: - Tmp1 = PromoteOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::ANY_EXTEND, dl, Op.getValueType(), Tmp1); - break; - case ISD::ZERO_EXTEND: - Result = PromoteOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::ANY_EXTEND, dl, Op.getValueType(), Result); - Result = DAG.getZeroExtendInReg(Result, dl, - Node->getOperand(0).getValueType()); - break; - case ISD::SIGN_EXTEND: - Result = PromoteOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::ANY_EXTEND, dl, Op.getValueType(), Result); - Result = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, Result.getValueType(), - Result, - DAG.getValueType(Node->getOperand(0).getValueType())); - break; - } + Tmp1 = LegalizeOp(Node->getOperand(0)); + Result = DAG.UpdateNodeOperands(Result, Tmp1); + if (TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0)) == + TargetLowering::Custom) { + Tmp1 = TLI.LowerOperation(Result, DAG); + if (Tmp1.getNode()) Result = Tmp1; } break; case ISD::FP_ROUND_INREG: @@ -4511,496 +3760,6 @@ return Result; } -/// PromoteOp - Given an operation that produces a value in an invalid type, -/// promote it to compute the value into a larger type. The produced value will -/// have the correct bits for the low portion of the register, but no guarantee -/// is made about the top bits: it may be zero, sign-extended, or garbage. -SDValue SelectionDAGLegalize::PromoteOp(SDValue Op) { - MVT VT = Op.getValueType(); - MVT NVT = TLI.getTypeToTransformTo(VT); - assert(getTypeAction(VT) == Promote && - "Caller should expand or legalize operands that are not promotable!"); - assert(NVT.bitsGT(VT) && NVT.isInteger() == VT.isInteger() && - "Cannot promote to smaller type!"); - - SDValue Tmp1, Tmp2, Tmp3; - SDValue Result; - SDNode *Node = Op.getNode(); - DebugLoc dl = Node->getDebugLoc(); - - DenseMap::iterator I = PromotedNodes.find(Op); - if (I != PromotedNodes.end()) return I->second; - - switch (Node->getOpcode()) { - case ISD::CopyFromReg: - assert(0 && "CopyFromReg must be legal!"); - default: -#ifndef NDEBUG - cerr << "NODE: "; Node->dump(&DAG); cerr << "\n"; -#endif - assert(0 && "Do not know how to promote this operator!"); - abort(); - case ISD::UNDEF: - Result = DAG.getUNDEF(NVT); - break; - case ISD::Constant: - if (VT != MVT::i1) - Result = DAG.getNode(ISD::SIGN_EXTEND, dl, NVT, Op); - else - Result = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Op); - assert(isa(Result) && "Didn't constant fold zext?"); - break; - case ISD::ConstantFP: - Result = DAG.getNode(ISD::FP_EXTEND, dl, NVT, Op); - assert(isa(Result) && "Didn't constant fold fp_extend?"); - break; - - case ISD::SETCC: { - MVT VT0 = Node->getOperand(0).getValueType(); - assert(isTypeLegal(TLI.getSetCCResultType(VT0)) - && "SetCC type is not legal??"); - Result = DAG.getNode(ISD::SETCC, dl, TLI.getSetCCResultType(VT0), - Node->getOperand(0), Node->getOperand(1), - Node->getOperand(2)); - break; - } - case ISD::TRUNCATE: - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Legal: - Result = LegalizeOp(Node->getOperand(0)); - assert(Result.getValueType().bitsGE(NVT) && - "This truncation doesn't make sense!"); - if (Result.getValueType().bitsGT(NVT)) // Truncate to NVT instead of VT - Result = DAG.getNode(ISD::TRUNCATE, dl, NVT, Result); - break; - case Promote: - // The truncation is not required, because we don't guarantee anything - // about high bits anyway. - Result = PromoteOp(Node->getOperand(0)); - break; - case Expand: - ExpandOp(Node->getOperand(0), Tmp1, Tmp2); - // Truncate the low part of the expanded value to the result type - Result = DAG.getNode(ISD::TRUNCATE, dl, NVT, Tmp1); - } - break; - case ISD::SIGN_EXTEND: - case ISD::ZERO_EXTEND: - case ISD::ANY_EXTEND: - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Expand: assert(0 && "BUG: Smaller reg should have been promoted!"); - case Legal: - // Input is legal? Just do extend all the way to the larger type. - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Node->getOperand(0)); - break; - case Promote: - // Promote the reg if it's smaller. - Result = PromoteOp(Node->getOperand(0)); - // The high bits are not guaranteed to be anything. Insert an extend. - if (Node->getOpcode() == ISD::SIGN_EXTEND) - Result = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, NVT, Result, - DAG.getValueType(Node->getOperand(0).getValueType())); - else if (Node->getOpcode() == ISD::ZERO_EXTEND) - Result = DAG.getZeroExtendInReg(Result, dl, - Node->getOperand(0).getValueType()); - break; - } - break; - case ISD::CONVERT_RNDSAT: { - ISD::CvtCode CvtCode = cast(Node)->getCvtCode(); - assert ((CvtCode == ISD::CVT_SS || CvtCode == ISD::CVT_SU || - CvtCode == ISD::CVT_US || CvtCode == ISD::CVT_UU || - CvtCode == ISD::CVT_SF || CvtCode == ISD::CVT_UF) && - "can only promote integers"); - Result = DAG.getConvertRndSat(NVT, dl, Node->getOperand(0), - Node->getOperand(1), Node->getOperand(2), - Node->getOperand(3), Node->getOperand(4), - CvtCode); - break; - - } - case ISD::BIT_CONVERT: - Result = EmitStackConvert(Node->getOperand(0), Node->getValueType(0), - Node->getValueType(0), dl); - Result = PromoteOp(Result); - break; - - case ISD::FP_EXTEND: - assert(0 && "Case not implemented. Dynamically dead with 2 FP types!"); - case ISD::FP_ROUND: - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Expand: assert(0 && "BUG: Cannot expand FP regs!"); - case Promote: assert(0 && "Unreachable with 2 FP types!"); - case Legal: - if (Node->getConstantOperandVal(1) == 0) { - // Input is legal? Do an FP_ROUND_INREG. - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, NVT, Node->getOperand(0), - DAG.getValueType(VT)); - } else { - // Just remove the truncate, it isn't affecting the value. - Result = DAG.getNode(ISD::FP_ROUND, dl, NVT, Node->getOperand(0), - Node->getOperand(1)); - } - break; - } - break; - case ISD::SINT_TO_FP: - case ISD::UINT_TO_FP: - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Legal: - // No extra round required here. - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Node->getOperand(0)); - break; - - case Promote: - Result = PromoteOp(Node->getOperand(0)); - if (Node->getOpcode() == ISD::SINT_TO_FP) - Result = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, Result.getValueType(), - Result, - DAG.getValueType(Node->getOperand(0).getValueType())); - else - Result = DAG.getZeroExtendInReg(Result, dl, - Node->getOperand(0).getValueType()); - // No extra round required here. - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Result); - break; - case Expand: - Result = ExpandIntToFP(Node->getOpcode() == ISD::SINT_TO_FP, NVT, - Node->getOperand(0), dl); - // Round if we cannot tolerate excess precision. - if (NoExcessFPPrecision) - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, NVT, Result, - DAG.getValueType(VT)); - break; - } - break; - - case ISD::SIGN_EXTEND_INREG: - Result = PromoteOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, NVT, Result, - Node->getOperand(1)); - break; - case ISD::FP_TO_SINT: - case ISD::FP_TO_UINT: - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Legal: - case Expand: - Tmp1 = Node->getOperand(0); - break; - case Promote: - // The input result is prerounded, so we don't have to do anything - // special. - Tmp1 = PromoteOp(Node->getOperand(0)); - break; - } - // If we're promoting a UINT to a larger size, check to see if the new node - // will be legal. If it isn't, check to see if FP_TO_SINT is legal, since - // we can use that instead. This allows us to generate better code for - // FP_TO_UINT for small destination sizes on targets where FP_TO_UINT is not - // legal, such as PowerPC. - if (Node->getOpcode() == ISD::FP_TO_UINT && - !TLI.isOperationLegalOrCustom(ISD::FP_TO_UINT, NVT) && - (TLI.isOperationLegalOrCustom(ISD::FP_TO_SINT, NVT) || - TLI.getOperationAction(ISD::FP_TO_SINT, NVT)==TargetLowering::Custom)){ - Result = DAG.getNode(ISD::FP_TO_SINT, dl, NVT, Tmp1); - } else { - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1); - } - break; - - case ISD::FABS: - case ISD::FNEG: - Tmp1 = PromoteOp(Node->getOperand(0)); - assert(Tmp1.getValueType() == NVT); - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1); - // NOTE: we do not have to do any extra rounding here for - // NoExcessFPPrecision, because we know the input will have the appropriate - // precision, and these operations don't modify precision at all. - break; - - case ISD::FLOG: - case ISD::FLOG2: - case ISD::FLOG10: - case ISD::FEXP: - case ISD::FEXP2: - case ISD::FSQRT: - case ISD::FSIN: - case ISD::FCOS: - case ISD::FTRUNC: - case ISD::FFLOOR: - case ISD::FCEIL: - case ISD::FRINT: - case ISD::FNEARBYINT: - Tmp1 = PromoteOp(Node->getOperand(0)); - assert(Tmp1.getValueType() == NVT); - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1); - if (NoExcessFPPrecision) - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, NVT, Result, - DAG.getValueType(VT)); - break; - - case ISD::FPOW: - case ISD::FPOWI: { - // Promote f32 pow(i) to f64 pow(i). Note that this could insert a libcall - // directly as well, which may be better. - Tmp1 = PromoteOp(Node->getOperand(0)); - Tmp2 = Node->getOperand(1); - if (Node->getOpcode() == ISD::FPOW) - Tmp2 = PromoteOp(Tmp2); - assert(Tmp1.getValueType() == NVT); - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1, Tmp2); - if (NoExcessFPPrecision) - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, NVT, Result, - DAG.getValueType(VT)); - break; - } - - case ISD::ATOMIC_CMP_SWAP: { - AtomicSDNode* AtomNode = cast(Node); - Tmp2 = PromoteOp(Node->getOperand(2)); - Tmp3 = PromoteOp(Node->getOperand(3)); - Result = DAG.getAtomic(Node->getOpcode(), dl, AtomNode->getMemoryVT(), - AtomNode->getChain(), - AtomNode->getBasePtr(), Tmp2, Tmp3, - AtomNode->getSrcValue(), - AtomNode->getAlignment()); - // Remember that we legalized the chain. - AddLegalizedOperand(Op.getValue(1), LegalizeOp(Result.getValue(1))); - break; - } - case ISD::ATOMIC_LOAD_ADD: - case ISD::ATOMIC_LOAD_SUB: - case ISD::ATOMIC_LOAD_AND: - case ISD::ATOMIC_LOAD_OR: - case ISD::ATOMIC_LOAD_XOR: - case ISD::ATOMIC_LOAD_NAND: - case ISD::ATOMIC_LOAD_MIN: - case ISD::ATOMIC_LOAD_MAX: - case ISD::ATOMIC_LOAD_UMIN: - case ISD::ATOMIC_LOAD_UMAX: - case ISD::ATOMIC_SWAP: { - AtomicSDNode* AtomNode = cast(Node); - Tmp2 = PromoteOp(Node->getOperand(2)); - Result = DAG.getAtomic(Node->getOpcode(), dl, AtomNode->getMemoryVT(), - AtomNode->getChain(), - AtomNode->getBasePtr(), Tmp2, - AtomNode->getSrcValue(), - AtomNode->getAlignment()); - // Remember that we legalized the chain. - AddLegalizedOperand(Op.getValue(1), LegalizeOp(Result.getValue(1))); - break; - } - - case ISD::AND: - case ISD::OR: - case ISD::XOR: - case ISD::ADD: - case ISD::SUB: - case ISD::MUL: - // The input may have strange things in the top bits of the registers, but - // these operations don't care. They may have weird bits going out, but - // that too is okay if they are integer operations. - Tmp1 = PromoteOp(Node->getOperand(0)); - Tmp2 = PromoteOp(Node->getOperand(1)); - assert(Tmp1.getValueType() == NVT && Tmp2.getValueType() == NVT); - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1, Tmp2); - break; - case ISD::FADD: - case ISD::FSUB: - case ISD::FMUL: - Tmp1 = PromoteOp(Node->getOperand(0)); - Tmp2 = PromoteOp(Node->getOperand(1)); - assert(Tmp1.getValueType() == NVT && Tmp2.getValueType() == NVT); - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1, Tmp2); - - // Floating point operations will give excess precision that we may not be - // able to tolerate. If we DO allow excess precision, just leave it, - // otherwise excise it. - // FIXME: Why would we need to round FP ops more than integer ones? - // Is Round(Add(Add(A,B),C)) != Round(Add(Round(Add(A,B)), C)) - if (NoExcessFPPrecision) - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, NVT, Result, - DAG.getValueType(VT)); - break; - - case ISD::SDIV: - case ISD::SREM: - // These operators require that their input be sign extended. - Tmp1 = PromoteOp(Node->getOperand(0)); - Tmp2 = PromoteOp(Node->getOperand(1)); - if (NVT.isInteger()) { - Tmp1 = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, NVT, Tmp1, - DAG.getValueType(VT)); - Tmp2 = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, NVT, Tmp2, - DAG.getValueType(VT)); - } - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1, Tmp2); - - // Perform FP_ROUND: this is probably overly pessimistic. - if (NVT.isFloatingPoint() && NoExcessFPPrecision) - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, NVT, Result, - DAG.getValueType(VT)); - break; - case ISD::FDIV: - case ISD::FREM: - case ISD::FCOPYSIGN: - // These operators require that their input be fp extended. - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Expand: assert(0 && "not implemented"); - case Legal: Tmp1 = LegalizeOp(Node->getOperand(0)); break; - case Promote: Tmp1 = PromoteOp(Node->getOperand(0)); break; - } - switch (getTypeAction(Node->getOperand(1).getValueType())) { - case Expand: assert(0 && "not implemented"); - case Legal: Tmp2 = LegalizeOp(Node->getOperand(1)); break; - case Promote: Tmp2 = PromoteOp(Node->getOperand(1)); break; - } - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1, Tmp2); - - // Perform FP_ROUND: this is probably overly pessimistic. - if (NoExcessFPPrecision && Node->getOpcode() != ISD::FCOPYSIGN) - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, NVT, Result, - DAG.getValueType(VT)); - break; - - case ISD::UDIV: - case ISD::UREM: - // These operators require that their input be zero extended. - Tmp1 = PromoteOp(Node->getOperand(0)); - Tmp2 = PromoteOp(Node->getOperand(1)); - assert(NVT.isInteger() && "Operators don't apply to FP!"); - Tmp1 = DAG.getZeroExtendInReg(Tmp1, dl, VT); - Tmp2 = DAG.getZeroExtendInReg(Tmp2, dl, VT); - Result = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1, Tmp2); - break; - - case ISD::SHL: - Tmp1 = PromoteOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::SHL, dl, NVT, Tmp1, Node->getOperand(1)); - break; - case ISD::SRA: - // The input value must be properly sign extended. - Tmp1 = PromoteOp(Node->getOperand(0)); - Tmp1 = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, NVT, Tmp1, - DAG.getValueType(VT)); - Result = DAG.getNode(ISD::SRA, dl, NVT, Tmp1, Node->getOperand(1)); - break; - case ISD::SRL: - // The input value must be properly zero extended. - Tmp1 = PromoteOp(Node->getOperand(0)); - Tmp1 = DAG.getZeroExtendInReg(Tmp1, dl, VT); - Result = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, Node->getOperand(1)); - break; - - case ISD::VAARG: - Tmp1 = Node->getOperand(0); // Get the chain. - Tmp2 = Node->getOperand(1); // Get the pointer. - if (TLI.getOperationAction(ISD::VAARG, VT) == TargetLowering::Custom) { - Tmp3 = DAG.getVAArg(VT, dl, Tmp1, Tmp2, Node->getOperand(2)); - Result = TLI.LowerOperation(Tmp3, DAG); - } else { - const Value *V = cast(Node->getOperand(2))->getValue(); - SDValue VAList = DAG.getLoad(TLI.getPointerTy(), dl, Tmp1, Tmp2, V, 0); - // Increment the pointer, VAList, to the next vaarg - Tmp3 = DAG.getNode(ISD::ADD, dl, TLI.getPointerTy(), VAList, - DAG.getConstant(VT.getSizeInBits()/8, - TLI.getPointerTy())); - // Store the incremented VAList to the legalized pointer - Tmp3 = DAG.getStore(VAList.getValue(1), dl, Tmp3, Tmp2, V, 0); - // Load the actual argument out of the pointer VAList - Result = DAG.getExtLoad(ISD::EXTLOAD, dl, NVT, Tmp3, VAList, NULL, 0, VT); - } - // Remember that we legalized the chain. - AddLegalizedOperand(Op.getValue(1), LegalizeOp(Result.getValue(1))); - break; - - case ISD::LOAD: { - LoadSDNode *LD = cast(Node); - ISD::LoadExtType ExtType = ISD::isNON_EXTLoad(Node) - ? ISD::EXTLOAD : LD->getExtensionType(); - Result = DAG.getExtLoad(ExtType, dl, NVT, - LD->getChain(), LD->getBasePtr(), - LD->getSrcValue(), LD->getSrcValueOffset(), - LD->getMemoryVT(), - LD->isVolatile(), - LD->getAlignment()); - // Remember that we legalized the chain. - AddLegalizedOperand(Op.getValue(1), LegalizeOp(Result.getValue(1))); - break; - } - case ISD::SELECT: { - Tmp2 = PromoteOp(Node->getOperand(1)); // Legalize the op0 - Tmp3 = PromoteOp(Node->getOperand(2)); // Legalize the op1 - - MVT VT2 = Tmp2.getValueType(); - assert(VT2 == Tmp3.getValueType() - && "PromoteOp SELECT: Operands 2 and 3 ValueTypes don't match"); - // Ensure that the resulting node is at least the same size as the operands' - // value types, because we cannot assume that TLI.getSetCCValueType() is - // constant. - Result = DAG.getNode(ISD::SELECT, dl, VT2, Node->getOperand(0), Tmp2, Tmp3); - break; - } - case ISD::SELECT_CC: - Tmp2 = PromoteOp(Node->getOperand(2)); // True - Tmp3 = PromoteOp(Node->getOperand(3)); // False - Result = DAG.getNode(ISD::SELECT_CC, dl, NVT, Node->getOperand(0), - Node->getOperand(1), Tmp2, Tmp3, Node->getOperand(4)); - break; - case ISD::BSWAP: - Tmp1 = Node->getOperand(0); - Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); - Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); - Result = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, - DAG.getConstant(NVT.getSizeInBits() - - VT.getSizeInBits(), - TLI.getShiftAmountTy())); - break; - case ISD::CTPOP: - case ISD::CTTZ: - case ISD::CTLZ: - // Zero extend the argument - Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Node->getOperand(0)); - // Perform the larger operation, then subtract if needed. - Tmp1 = DAG.getNode(Node->getOpcode(), dl, NVT, Tmp1); - switch(Node->getOpcode()) { - case ISD::CTPOP: - Result = Tmp1; - break; - case ISD::CTTZ: - // if Tmp1 == sizeinbits(NVT) then Tmp1 = sizeinbits(Old VT) - Tmp2 = DAG.getSetCC(dl, TLI.getSetCCResultType(Tmp1.getValueType()), Tmp1, - DAG.getConstant(NVT.getSizeInBits(), NVT), - ISD::SETEQ); - Result = DAG.getNode(ISD::SELECT, dl, NVT, Tmp2, - DAG.getConstant(VT.getSizeInBits(), NVT), Tmp1); - break; - case ISD::CTLZ: - //Tmp1 = Tmp1 - (sizeinbits(NVT) - sizeinbits(Old VT)) - Result = DAG.getNode(ISD::SUB, dl, NVT, Tmp1, - DAG.getConstant(NVT.getSizeInBits() - - VT.getSizeInBits(), NVT)); - break; - } - break; - case ISD::EXTRACT_SUBVECTOR: - Result = PromoteOp(ExpandEXTRACT_SUBVECTOR(Op)); - break; - case ISD::EXTRACT_VECTOR_ELT: - Result = PromoteOp(ExpandEXTRACT_VECTOR_ELT(Op)); - break; - } - - assert(Result.getNode() && "Didn't set a result!"); - - // Make sure the result is itself legal. - Result = LegalizeOp(Result); - - // Remember that we promoted this! - AddPromotedOperand(Op, Result); - return Result; -} - /// ExpandEXTRACT_VECTOR_ELT - Expand an EXTRACT_VECTOR_ELT operation into /// a legal EXTRACT_VECTOR_ELT operation, scalar code, or memory traffic, /// based on the vector type. The return type of this matches the element type @@ -5027,12 +3786,9 @@ break; } case TargetLowering::Legal: - if (isTypeLegal(TVT)) { - Vec = LegalizeOp(Vec); - Op = DAG.UpdateNodeOperands(Op, Vec, Idx); - return Op; - } - break; + Vec = LegalizeOp(Vec); + Op = DAG.UpdateNodeOperands(Op, Vec, Idx); + return Op; case TargetLowering::Promote: assert(TVT.isVector() && "not vector type"); // fall thru to expand since vectors are by default are promote @@ -5042,23 +3798,7 @@ if (NumElems == 1) { // This must be an access of the only element. Return it. - Op = ScalarizeVectorOp(Vec); - } else if (!TLI.isTypeLegal(TVT) && isa(Idx)) { - unsigned NumLoElts = 1 << Log2_32(NumElems-1); - ConstantSDNode *CIdx = cast(Idx); - SDValue Lo, Hi; - SplitVectorOp(Vec, Lo, Hi); - if (CIdx->getZExtValue() < NumLoElts) { - Vec = Lo; - } else { - Vec = Hi; - Idx = DAG.getConstant(CIdx->getZExtValue() - NumLoElts, - Idx.getValueType()); - } - - // It's now an extract from the appropriate high or low part. Recurse. - Op = DAG.UpdateNodeOperands(Op, Vec, Idx); - Op = ExpandEXTRACT_VECTOR_ELT(Op); + Op = DAG.getNode(ISD::BIT_CONVERT, dl, Op.getValueType(), Vec); } else { // Store the value to a temporary stack slot, then LOAD the scalar // element back out. @@ -5082,305 +3822,8 @@ return Op; } -/// ExpandEXTRACT_SUBVECTOR - Expand a EXTRACT_SUBVECTOR operation. For now -/// we assume the operation can be split if it is not already legal. -SDValue SelectionDAGLegalize::ExpandEXTRACT_SUBVECTOR(SDValue Op) { - // We know that operand #0 is the Vec vector. For now we assume the index - // is a constant and that the extracted result is a supported hardware type. - SDValue Vec = Op.getOperand(0); - SDValue Idx = LegalizeOp(Op.getOperand(1)); - - unsigned NumElems = Vec.getValueType().getVectorNumElements(); - - if (NumElems == Op.getValueType().getVectorNumElements()) { - // This must be an access of the desired vector length. Return it. - return Vec; - } - - ConstantSDNode *CIdx = cast(Idx); - SDValue Lo, Hi; - SplitVectorOp(Vec, Lo, Hi); - if (CIdx->getZExtValue() < NumElems/2) { - Vec = Lo; - } else { - Vec = Hi; - Idx = DAG.getConstant(CIdx->getZExtValue() - NumElems/2, - Idx.getValueType()); - } - - // It's now an extract from the appropriate high or low part. Recurse. - Op = DAG.UpdateNodeOperands(Op, Vec, Idx); - return ExpandEXTRACT_SUBVECTOR(Op); -} - -/// LegalizeSetCCOperands - Attempts to create a legal LHS and RHS for a SETCC -/// with condition CC on the current target. This usually involves legalizing -/// or promoting the arguments. In the case where LHS and RHS must be expanded, -/// there may be no choice but to create a new SetCC node to represent the -/// legalized value of setcc lhs, rhs. In this case, the value is returned in -/// LHS, and the SDValue returned in RHS has a nil SDNode value. -void SelectionDAGLegalize::LegalizeSetCCOperands(SDValue &LHS, - SDValue &RHS, - SDValue &CC, - DebugLoc dl) { - SDValue Tmp1, Tmp2, Tmp3, Result; - - switch (getTypeAction(LHS.getValueType())) { - case Legal: - Tmp1 = LegalizeOp(LHS); // LHS - Tmp2 = LegalizeOp(RHS); // RHS - break; - case Promote: - Tmp1 = PromoteOp(LHS); // LHS - Tmp2 = PromoteOp(RHS); // RHS - - // If this is an FP compare, the operands have already been extended. - if (LHS.getValueType().isInteger()) { - MVT VT = LHS.getValueType(); - MVT NVT = TLI.getTypeToTransformTo(VT); - - // Otherwise, we have to insert explicit sign or zero extends. Note - // that we could insert sign extends for ALL conditions, but zero extend - // is cheaper on many machines (an AND instead of two shifts), so prefer - // it. - switch (cast(CC)->get()) { - default: assert(0 && "Unknown integer comparison!"); - case ISD::SETEQ: - case ISD::SETNE: - case ISD::SETUGE: - case ISD::SETUGT: - case ISD::SETULE: - case ISD::SETULT: - // ALL of these operations will work if we either sign or zero extend - // the operands (including the unsigned comparisons!). Zero extend is - // usually a simpler/cheaper operation, so prefer it. - Tmp1 = DAG.getZeroExtendInReg(Tmp1, dl, VT); - Tmp2 = DAG.getZeroExtendInReg(Tmp2, dl, VT); - break; - case ISD::SETGE: - case ISD::SETGT: - case ISD::SETLT: - case ISD::SETLE: - Tmp1 = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, NVT, Tmp1, - DAG.getValueType(VT)); - Tmp2 = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, NVT, Tmp2, - DAG.getValueType(VT)); - Tmp1 = LegalizeOp(Tmp1); // Relegalize new nodes. - Tmp2 = LegalizeOp(Tmp2); // Relegalize new nodes. - break; - } - } - break; - case Expand: { - MVT VT = LHS.getValueType(); - if (VT == MVT::f32 || VT == MVT::f64) { - // Expand into one or more soft-fp libcall(s). - RTLIB::Libcall LC1 = RTLIB::UNKNOWN_LIBCALL, LC2 = RTLIB::UNKNOWN_LIBCALL; - switch (cast(CC)->get()) { - case ISD::SETEQ: - case ISD::SETOEQ: - LC1 = (VT == MVT::f32) ? RTLIB::OEQ_F32 : RTLIB::OEQ_F64; - break; - case ISD::SETNE: - case ISD::SETUNE: - LC1 = (VT == MVT::f32) ? RTLIB::UNE_F32 : RTLIB::UNE_F64; - break; - case ISD::SETGE: - case ISD::SETOGE: - LC1 = (VT == MVT::f32) ? RTLIB::OGE_F32 : RTLIB::OGE_F64; - break; - case ISD::SETLT: - case ISD::SETOLT: - LC1 = (VT == MVT::f32) ? RTLIB::OLT_F32 : RTLIB::OLT_F64; - break; - case ISD::SETLE: - case ISD::SETOLE: - LC1 = (VT == MVT::f32) ? RTLIB::OLE_F32 : RTLIB::OLE_F64; - break; - case ISD::SETGT: - case ISD::SETOGT: - LC1 = (VT == MVT::f32) ? RTLIB::OGT_F32 : RTLIB::OGT_F64; - break; - case ISD::SETUO: - LC1 = (VT == MVT::f32) ? RTLIB::UO_F32 : RTLIB::UO_F64; - break; - case ISD::SETO: - LC1 = (VT == MVT::f32) ? RTLIB::O_F32 : RTLIB::O_F64; - break; - default: - LC1 = (VT == MVT::f32) ? RTLIB::UO_F32 : RTLIB::UO_F64; - switch (cast(CC)->get()) { - case ISD::SETONE: - // SETONE = SETOLT | SETOGT - LC1 = (VT == MVT::f32) ? RTLIB::OLT_F32 : RTLIB::OLT_F64; - // Fallthrough - case ISD::SETUGT: - LC2 = (VT == MVT::f32) ? RTLIB::OGT_F32 : RTLIB::OGT_F64; - break; - case ISD::SETUGE: - LC2 = (VT == MVT::f32) ? RTLIB::OGE_F32 : RTLIB::OGE_F64; - break; - case ISD::SETULT: - LC2 = (VT == MVT::f32) ? RTLIB::OLT_F32 : RTLIB::OLT_F64; - break; - case ISD::SETULE: - LC2 = (VT == MVT::f32) ? RTLIB::OLE_F32 : RTLIB::OLE_F64; - break; - case ISD::SETUEQ: - LC2 = (VT == MVT::f32) ? RTLIB::OEQ_F32 : RTLIB::OEQ_F64; - break; - default: assert(0 && "Unsupported FP setcc!"); - } - } - - SDValue Dummy; - SDValue Ops[2] = { LHS, RHS }; - Tmp1 = ExpandLibCall(LC1, DAG.getMergeValues(Ops, 2, dl).getNode(), - false /*sign irrelevant*/, Dummy); - Tmp2 = DAG.getConstant(0, MVT::i32); - CC = DAG.getCondCode(TLI.getCmpLibcallCC(LC1)); - if (LC2 != RTLIB::UNKNOWN_LIBCALL) { - Tmp1 = DAG.getNode(ISD::SETCC, dl, - TLI.getSetCCResultType(Tmp1.getValueType()), - Tmp1, Tmp2, CC); - LHS = ExpandLibCall(LC2, DAG.getMergeValues(Ops, 2, dl).getNode(), - false /*sign irrelevant*/, Dummy); - Tmp2 = DAG.getNode(ISD::SETCC, dl, - TLI.getSetCCResultType(LHS.getValueType()), LHS, - Tmp2, DAG.getCondCode(TLI.getCmpLibcallCC(LC2))); - Tmp1 = DAG.getNode(ISD::OR, dl, Tmp1.getValueType(), Tmp1, Tmp2); - Tmp2 = SDValue(); - } - LHS = LegalizeOp(Tmp1); - RHS = Tmp2; - return; - } - - SDValue LHSLo, LHSHi, RHSLo, RHSHi; - ExpandOp(LHS, LHSLo, LHSHi); - ExpandOp(RHS, RHSLo, RHSHi); - ISD::CondCode CCCode = cast(CC)->get(); - - if (VT==MVT::ppcf128) { - // FIXME: This generated code sucks. We want to generate - // FCMPU crN, hi1, hi2 - // BNE crN, L: - // FCMPU crN, lo1, lo2 - // The following can be improved, but not that much. - Tmp1 = DAG.getSetCC(dl, TLI.getSetCCResultType(LHSHi.getValueType()), - LHSHi, RHSHi, ISD::SETOEQ); - Tmp2 = DAG.getSetCC(dl, TLI.getSetCCResultType(LHSLo.getValueType()), - LHSLo, RHSLo, CCCode); - Tmp3 = DAG.getNode(ISD::AND, dl, Tmp1.getValueType(), Tmp1, Tmp2); - Tmp1 = DAG.getSetCC(dl, TLI.getSetCCResultType(LHSHi.getValueType()), - LHSHi, RHSHi, ISD::SETUNE); - Tmp2 = DAG.getSetCC(dl, TLI.getSetCCResultType(LHSHi.getValueType()), - LHSHi, RHSHi, CCCode); - Tmp1 = DAG.getNode(ISD::AND, dl, Tmp1.getValueType(), Tmp1, Tmp2); - Tmp1 = DAG.getNode(ISD::OR, dl, Tmp1.getValueType(), Tmp1, Tmp3); - Tmp2 = SDValue(); - break; - } - - switch (CCCode) { - case ISD::SETEQ: - case ISD::SETNE: - if (RHSLo == RHSHi) - if (ConstantSDNode *RHSCST = dyn_cast(RHSLo)) - if (RHSCST->isAllOnesValue()) { - // Comparison to -1. - Tmp1 = DAG.getNode(ISD::AND, dl,LHSLo.getValueType(), LHSLo, LHSHi); - Tmp2 = RHSLo; - break; - } - - Tmp1 = DAG.getNode(ISD::XOR, dl, LHSLo.getValueType(), LHSLo, RHSLo); - Tmp2 = DAG.getNode(ISD::XOR, dl, LHSLo.getValueType(), LHSHi, RHSHi); - Tmp1 = DAG.getNode(ISD::OR, dl, Tmp1.getValueType(), Tmp1, Tmp2); - Tmp2 = DAG.getConstant(0, Tmp1.getValueType()); - break; - default: - // If this is a comparison of the sign bit, just look at the top part. - // X > -1, x < 0 - if (ConstantSDNode *CST = dyn_cast(RHS)) - if ((cast(CC)->get() == ISD::SETLT && - CST->isNullValue()) || // X < 0 - (cast(CC)->get() == ISD::SETGT && - CST->isAllOnesValue())) { // X > -1 - Tmp1 = LHSHi; - Tmp2 = RHSHi; - break; - } - - // FIXME: This generated code sucks. - ISD::CondCode LowCC; - switch (CCCode) { - default: assert(0 && "Unknown integer setcc!"); - case ISD::SETLT: - case ISD::SETULT: LowCC = ISD::SETULT; break; - case ISD::SETGT: - case ISD::SETUGT: LowCC = ISD::SETUGT; break; - case ISD::SETLE: - case ISD::SETULE: LowCC = ISD::SETULE; break; - case ISD::SETGE: - case ISD::SETUGE: LowCC = ISD::SETUGE; break; - } - - // Tmp1 = lo(op1) < lo(op2) // Always unsigned comparison - // Tmp2 = hi(op1) < hi(op2) // Signedness depends on operands - // dest = hi(op1) == hi(op2) ? Tmp1 : Tmp2; - - // NOTE: on targets without efficient SELECT of bools, we can always use - // this identity: (B1 ? B2 : B3) --> (B1 & B2)|(!B1&B3) - TargetLowering::DAGCombinerInfo DagCombineInfo(DAG, false, true, NULL); - Tmp1 = TLI.SimplifySetCC(TLI.getSetCCResultType(LHSLo.getValueType()), - LHSLo, RHSLo, LowCC, false, DagCombineInfo, dl); - if (!Tmp1.getNode()) - Tmp1 = DAG.getSetCC(dl, TLI.getSetCCResultType(LHSLo.getValueType()), - LHSLo, RHSLo, LowCC); - Tmp2 = TLI.SimplifySetCC(TLI.getSetCCResultType(LHSHi.getValueType()), - LHSHi, RHSHi, CCCode, false, DagCombineInfo, dl); - if (!Tmp2.getNode()) - Tmp2 = DAG.getNode(ISD::SETCC, dl, - TLI.getSetCCResultType(LHSHi.getValueType()), - LHSHi, RHSHi, CC); - - ConstantSDNode *Tmp1C = dyn_cast(Tmp1.getNode()); - ConstantSDNode *Tmp2C = dyn_cast(Tmp2.getNode()); - if ((Tmp1C && Tmp1C->isNullValue()) || - (Tmp2C && Tmp2C->isNullValue() && - (CCCode == ISD::SETLE || CCCode == ISD::SETGE || - CCCode == ISD::SETUGE || CCCode == ISD::SETULE)) || - (Tmp2C && Tmp2C->getAPIntValue() == 1 && - (CCCode == ISD::SETLT || CCCode == ISD::SETGT || - CCCode == ISD::SETUGT || CCCode == ISD::SETULT))) { - // low part is known false, returns high part. - // For LE / GE, if high part is known false, ignore the low part. - // For LT / GT, if high part is known true, ignore the low part. - Tmp1 = Tmp2; - Tmp2 = SDValue(); - } else { - Result = TLI.SimplifySetCC(TLI.getSetCCResultType(LHSHi.getValueType()), - LHSHi, RHSHi, ISD::SETEQ, false, - DagCombineInfo, dl); - if (!Result.getNode()) - Result=DAG.getSetCC(dl, TLI.getSetCCResultType(LHSHi.getValueType()), - LHSHi, RHSHi, ISD::SETEQ); - Result = LegalizeOp(DAG.getNode(ISD::SELECT, dl, Tmp1.getValueType(), - Result, Tmp1, Tmp2)); - Tmp1 = Result; - Tmp2 = SDValue(); - } - } - } - } - LHS = Tmp1; - RHS = Tmp2; -} - /// LegalizeSetCCCondCode - Legalize a SETCC with given LHS and RHS and -/// condition code CC on the current target. This routine assumes LHS and rHS -/// have already been legalized by LegalizeSetCCOperands. It expands SETCC with +/// condition code CC on the current target. TIt expands SETCC with /// illegal condition code into AND / OR of multiple SETCC values. void SelectionDAGLegalize::LegalizeSetCCCondCode(MVT VT, SDValue &LHS, SDValue &RHS, @@ -5650,177 +4093,7 @@ return DAG.getLoad(VT, dl, StoreChain, FIPtr, SV, 0); } -void SelectionDAGLegalize::ExpandShiftParts(unsigned NodeOp, - SDValue Op, SDValue Amt, - SDValue &Lo, SDValue &Hi, - DebugLoc dl) { - // Expand the subcomponents. - SDValue LHSL, LHSH; - ExpandOp(Op, LHSL, LHSH); - SDValue Ops[] = { LHSL, LHSH, Amt }; - MVT VT = LHSL.getValueType(); - Lo = DAG.getNode(NodeOp, dl, DAG.getVTList(VT, VT), Ops, 3); - Hi = Lo.getValue(1); -} - - -/// ExpandShift - Try to find a clever way to expand this shift operation out to -/// smaller elements. If we can't find a way that is more efficient than a -/// libcall on this target, return false. Otherwise, return true with the -/// low-parts expanded into Lo and Hi. -bool SelectionDAGLegalize::ExpandShift(unsigned Opc, SDValue Op, SDValue Amt, - SDValue &Lo, SDValue &Hi, - DebugLoc dl) { - assert((Opc == ISD::SHL || Opc == ISD::SRA || Opc == ISD::SRL) && - "This is not a shift!"); - - MVT NVT = TLI.getTypeToTransformTo(Op.getValueType()); - SDValue ShAmt = LegalizeOp(Amt); - MVT ShTy = ShAmt.getValueType(); - unsigned ShBits = ShTy.getSizeInBits(); - unsigned VTBits = Op.getValueType().getSizeInBits(); - unsigned NVTBits = NVT.getSizeInBits(); - - // Handle the case when Amt is an immediate. - if (ConstantSDNode *CN = dyn_cast(Amt.getNode())) { - unsigned Cst = CN->getZExtValue(); - // Expand the incoming operand to be shifted, so that we have its parts - SDValue InL, InH; - ExpandOp(Op, InL, InH); - switch(Opc) { - case ISD::SHL: - if (Cst > VTBits) { - Lo = DAG.getConstant(0, NVT); - Hi = DAG.getConstant(0, NVT); - } else if (Cst > NVTBits) { - Lo = DAG.getConstant(0, NVT); - Hi = DAG.getNode(ISD::SHL, dl, - NVT, InL, DAG.getConstant(Cst-NVTBits, ShTy)); - } else if (Cst == NVTBits) { - Lo = DAG.getConstant(0, NVT); - Hi = InL; - } else { - Lo = DAG.getNode(ISD::SHL, dl, NVT, InL, DAG.getConstant(Cst, ShTy)); - Hi = DAG.getNode(ISD::OR, dl, NVT, - DAG.getNode(ISD::SHL, dl, NVT, InH, DAG.getConstant(Cst, ShTy)), - DAG.getNode(ISD::SRL, dl, NVT, InL, - DAG.getConstant(NVTBits-Cst, ShTy))); - } - return true; - case ISD::SRL: - if (Cst > VTBits) { - Lo = DAG.getConstant(0, NVT); - Hi = DAG.getConstant(0, NVT); - } else if (Cst > NVTBits) { - Lo = DAG.getNode(ISD::SRL, dl, NVT, - InH, DAG.getConstant(Cst-NVTBits, ShTy)); - Hi = DAG.getConstant(0, NVT); - } else if (Cst == NVTBits) { - Lo = InH; - Hi = DAG.getConstant(0, NVT); - } else { - Lo = DAG.getNode(ISD::OR, dl, NVT, - DAG.getNode(ISD::SRL, dl, NVT, InL, DAG.getConstant(Cst, ShTy)), - DAG.getNode(ISD::SHL, dl, NVT, InH, - DAG.getConstant(NVTBits-Cst, ShTy))); - Hi = DAG.getNode(ISD::SRL, dl, NVT, InH, DAG.getConstant(Cst, ShTy)); - } - return true; - case ISD::SRA: - if (Cst > VTBits) { - Hi = Lo = DAG.getNode(ISD::SRA, dl, NVT, InH, - DAG.getConstant(NVTBits-1, ShTy)); - } else if (Cst > NVTBits) { - Lo = DAG.getNode(ISD::SRA, dl, NVT, InH, - DAG.getConstant(Cst-NVTBits, ShTy)); - Hi = DAG.getNode(ISD::SRA, dl, NVT, InH, - DAG.getConstant(NVTBits-1, ShTy)); - } else if (Cst == NVTBits) { - Lo = InH; - Hi = DAG.getNode(ISD::SRA, dl, NVT, InH, - DAG.getConstant(NVTBits-1, ShTy)); - } else { - Lo = DAG.getNode(ISD::OR, dl, NVT, - DAG.getNode(ISD::SRL, dl, NVT, InL, DAG.getConstant(Cst, ShTy)), - DAG.getNode(ISD::SHL, dl, - NVT, InH, DAG.getConstant(NVTBits-Cst, ShTy))); - Hi = DAG.getNode(ISD::SRA, dl, NVT, InH, DAG.getConstant(Cst, ShTy)); - } - return true; - } - } - - // Okay, the shift amount isn't constant. However, if we can tell that it is - // >= 32 or < 32, we can still simplify it, without knowing the actual value. - APInt Mask = APInt::getHighBitsSet(ShBits, ShBits - Log2_32(NVTBits)); - APInt KnownZero, KnownOne; - DAG.ComputeMaskedBits(Amt, Mask, KnownZero, KnownOne); - - // If we know that if any of the high bits of the shift amount are one, then - // we can do this as a couple of simple shifts. - if (KnownOne.intersects(Mask)) { - // Mask out the high bit, which we know is set. - Amt = DAG.getNode(ISD::AND, dl, Amt.getValueType(), Amt, - DAG.getConstant(~Mask, Amt.getValueType())); - - // Expand the incoming operand to be shifted, so that we have its parts - SDValue InL, InH; - ExpandOp(Op, InL, InH); - switch(Opc) { - case ISD::SHL: - Lo = DAG.getConstant(0, NVT); // Low part is zero. - Hi = DAG.getNode(ISD::SHL, dl, NVT, InL, Amt); // High part from Lo part. - return true; - case ISD::SRL: - Hi = DAG.getConstant(0, NVT); // Hi part is zero. - Lo = DAG.getNode(ISD::SRL, dl, NVT, InH, Amt); // Lo part from Hi part. - return true; - case ISD::SRA: - Hi = DAG.getNode(ISD::SRA, dl, NVT, InH, // Sign extend high part. - DAG.getConstant(NVTBits-1, Amt.getValueType())); - Lo = DAG.getNode(ISD::SRA, dl, NVT, InH, Amt); // Lo part from Hi part. - return true; - } - } - - // If we know that the high bits of the shift amount are all zero, then we can - // do this as a couple of simple shifts. - if ((KnownZero & Mask) == Mask) { - // Compute 32-amt. - SDValue Amt2 = DAG.getNode(ISD::SUB, dl, Amt.getValueType(), - DAG.getConstant(NVTBits, Amt.getValueType()), - Amt); - - // Expand the incoming operand to be shifted, so that we have its parts - SDValue InL, InH; - ExpandOp(Op, InL, InH); - switch(Opc) { - case ISD::SHL: - Lo = DAG.getNode(ISD::SHL, dl, NVT, InL, Amt); - Hi = DAG.getNode(ISD::OR, dl, NVT, - DAG.getNode(ISD::SHL, dl, NVT, InH, Amt), - DAG.getNode(ISD::SRL, dl, NVT, InL, Amt2)); - return true; - case ISD::SRL: - Hi = DAG.getNode(ISD::SRL, dl, NVT, InH, Amt); - Lo = DAG.getNode(ISD::OR, dl, NVT, - DAG.getNode(ISD::SRL, dl, NVT, InL, Amt), - DAG.getNode(ISD::SHL, dl, NVT, InH, Amt2)); - return true; - case ISD::SRA: - Hi = DAG.getNode(ISD::SRA, dl, NVT, InH, Amt); - Lo = DAG.getNode(ISD::OR, dl, NVT, - DAG.getNode(ISD::SRL, dl, NVT, InL, Amt), - DAG.getNode(ISD::SHL, dl, NVT, InH, Amt2)); - return true; - } - } - - return false; -} - - // ExpandLibCall - Expand a node into a call to a libcall. If the result value // does not fit into a register, return the lo part and set the hi part to the // by-reg argument. If it does fit into a single register, return the result @@ -5857,17 +4130,7 @@ // the LastCALLSEQ_END to the legalized version of the CALLSEQ_END node that // was added by LowerCallTo (guaranteeing proper serialization of calls). LegalizeOp(CallInfo.second); - SDValue Result; - switch (getTypeAction(CallInfo.first.getValueType())) { - default: assert(0 && "Unknown thing"); - case Legal: - Result = CallInfo.first; - break; - case Expand: - ExpandOp(CallInfo.first, Result, Hi); - break; - } - return Result; + return CallInfo.first; } /// LegalizeINT_TO_FP - Legalize a [US]INT_TO_FP operation. @@ -5877,8 +4140,7 @@ DebugLoc dl) { bool isCustom = false; SDValue Tmp1; - switch (getTypeAction(Op.getValueType())) { - case Legal: + { switch (TLI.getOperationAction(isSigned ? ISD::SINT_TO_FP : ISD::UINT_TO_FP, Op.getValueType())) { default: assert(0 && "Unknown operation action!"); @@ -5904,173 +4166,10 @@ Result = PromoteLegalINT_TO_FP(LegalizeOp(Op), DestTy, isSigned, dl); break; } - break; - case Expand: - Result = ExpandIntToFP(isSigned, DestTy, Op, dl) ; - break; - case Promote: - Tmp1 = PromoteOp(Op); - if (isSigned) { - Tmp1 = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, Tmp1.getValueType(), - Tmp1, DAG.getValueType(Op.getValueType())); - } else { - Tmp1 = DAG.getZeroExtendInReg(Tmp1, dl, Op.getValueType()); - } - if (Result.getNode()) - Result = DAG.UpdateNodeOperands(Result, Tmp1); - else - Result = DAG.getNode(isSigned ? ISD::SINT_TO_FP : ISD::UINT_TO_FP, dl, - DestTy, Tmp1); - Result = LegalizeOp(Result); // The 'op' is not necessarily legal! - break; } return Result; } -/// ExpandIntToFP - Expand a [US]INT_TO_FP operation. -/// -SDValue SelectionDAGLegalize:: -ExpandIntToFP(bool isSigned, MVT DestTy, SDValue Source, DebugLoc dl) { - MVT SourceVT = Source.getValueType(); - bool ExpandSource = getTypeAction(SourceVT) == Expand; - - // Expand unsupported int-to-fp vector casts by unrolling them. - if (DestTy.isVector()) { - if (!ExpandSource) - return LegalizeOp(UnrollVectorOp(Source)); - MVT DestEltTy = DestTy.getVectorElementType(); - if (DestTy.getVectorNumElements() == 1) { - SDValue Scalar = ScalarizeVectorOp(Source); - SDValue Result = LegalizeINT_TO_FP(SDValue(), isSigned, - DestEltTy, Scalar, dl); - return DAG.getNode(ISD::BUILD_VECTOR, dl, DestTy, Result); - } - SDValue Lo, Hi; - SplitVectorOp(Source, Lo, Hi); - MVT SplitDestTy = MVT::getVectorVT(DestEltTy, - DestTy.getVectorNumElements() / 2); - SDValue LoResult = LegalizeINT_TO_FP(SDValue(), isSigned, SplitDestTy, - Lo, dl); - SDValue HiResult = LegalizeINT_TO_FP(SDValue(), isSigned, SplitDestTy, - Hi, dl); - return LegalizeOp(DAG.getNode(ISD::CONCAT_VECTORS, dl, DestTy, LoResult, - HiResult)); - } - - // Special case for i32 source to take advantage of UINTTOFP_I32_F32, etc. - if (!isSigned && SourceVT != MVT::i32) { - // The integer value loaded will be incorrectly if the