similar to: LLVM 1.1 Release & Status Update

On Jan 6, 2012, at 8:27 PM, Daniel Berlin wrote: > Note: GCC takes exactly the same approach as LLVM here, for exactly > the reason chris specifies. > In fact, until we started local SSA updating (which is now many years > ago, but ...), dominance frontier calculation for ssa updating was in > the top 10 profile functions for GCC compiles of large source files. > I had tried a

On Sat, Jan 7, 2012 at 12:14 AM, Cameron Zwarich <zwarich at apple.com> wrote: > On Jan 6, 2012, at 8:27 PM, Daniel Berlin wrote: > > Note: GCC takes exactly the same approach as LLVM here, for exactly > the reason chris specifies. > In fact, until we started local SSA updating (which is now many years > ago, but ...), dominance frontier calculation for ssa updating was in

Folks, As of the writing of this note, the llvmc tool is enabled for build on the CVS head. I'm encouraging you to try it out, provide some feedback, and help with the issues below. llvmc is now able to correctly link a pure bytecode version of any Stacker program. This includes translation with stkrc, optimization with opt and linking with llvm-link. It is also able to find Stacker's

I found the chapters in Engineering a Compiler (Cooper and Torczon) perfectly match the code generator of LLVM. And this paper: Lengauer and Tarjan, A Fast Algorithm for Finding Dominators in a Flowgraph, ACM TOPLAS, Vol 1 , No.1, July 1979 I also would like to know more papers/books whose algorithms are implemented in LLVM. 在 星期二 19 十二月 2006 22:13，Fredrik Svensson 写道： > Hi, > > As

Reid Spencer wrote: > On Mon, 2006-02-27 at 20:43 -0800, Wink Saville wrote: > >>> Try passing "-L/opt/llvm-1.6/llvm-gcc/lib/ -lcrtend" to llvm-ld. >>> >> This didn't work for me: >> llvm-ld -o t1.app t1.bc t1.a -L/opt/llvm-1.6/llvm-gcc/lib/ -lcrtend.a >> >> I get two warning's about library 'crtend' missing

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

On Fri, 19 Dec 2003, Reid Spencer wrote: > As a side effect of bug 178 (Stacker not handling 64-bit pointers on > Solaris), I got thinking about a union type for LLVM. Is there any > good reason that LLVM shouldn't support unions? This is essentially a > structure that has its members all at the same address rather than at > sequential addresses. I know there are various

Chris, Here's my review notes: 1. In the Known problems section you identify PR656 as a known problem. However, this bug is resolved and in January you reported that you verified it on Solaris. So, one of two things needs to happen. Either remove this item from the release notes, or re-open the bug and tell me what still breaks. 2. It seems that several items from the original DRAFT email

On Fri, 2003-12-19 at 15:32, Chris Lattner wrote: > This is intentionally not part of the LLVM type-system, because it is > redundant. If you compile a C program that uses a union, for example, the > C front-end will turn it into a type (often a structure) that contains > only one of the element types (usually the largest one, perhaps modified > to have the correct alignment).

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the

Reid, Click on any of these logs and you'll see the same asm parsing issues. It's been going on for much of the week. http://llvm.org/nightlytest/machines/2006-12-29_05:40:12-Build-Log.txt http://llvm.org/nightlytest/machines/2006-12-29_05:40:12-Build-Log.txt llvm[4]: Compiling stacker_rt.ll to stacker_rt.bc for Release build (bytecode)

shding at mtu.edu wrote: > Hi, > Where can I find the main function of llvm compiler in the source file? > Thanks! Well, there's a loaded question. :) It depends on "which" compiler you mean. If you're talking about the llvm-gcc and llvm-g++ compilers (C/C++ to LLVM) then they are in the downloadable tarballs available here: http://llvm.cs.uiuc.edu/releases/. You

Next problem detected by nighttest: LLVM build fail with errors: gmake[4]: Entering directory `/usr/home/wanderer/pkg/build/llvm/night/build/llvm/projects/Stacker/lib/runtime' llvm[4]: Compiling stacker_rt.c for Debug build (bytecode) default/bin/llvm-gcc: not found gmake[4]: *** [/usr/home/wanderer/pkg/build/llvm/night/build/llvm/projects/Stacker/lib/runtime/Debug/stacker_rt.bc] Error 1

Jim Laskey wrote: > llvm[4]: Compiling stacker_rt.ll to stacker_rt.bc for Release build > (bytecode) > /Volumes/Muggles/LLVM/nightlytest/build/llvm/Release/bin/gccas: / > Volumes/Muggles/LLVM/nightlytest/build/llvm/projects/Stacker/lib/ > runtime/Release/stacker_rt.ll:21,0: parse error, expecting `LOAD' or > `STORE' >

LLVMers, I've hacked Brian's BitterMelon demo to include Stacker and bytecode analysis information. You can try it out on the mirror at: http://llvm.x10sys.com/demo/index.cgi A new language radio buttons below the text input area permits Stacker input to be compiled and there is an extra option for generating bc data with llvm-bcanalyzer. If you're new to LLVM, try pasting the

Hi folks, For the past month I’ve been working on improving the DominatorTree and PostDominatorTree in LLVM. The RFC that explains the motivations and plans can be found here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114045.html . Here’s a short summary of what changed upstream since posting it: - We switched from the Simple Lengauer-Tarjan algorithm for computing dominators

Thank you. I'm only consider about how the compiler comiles c program to LLVM IR. I know there should be a scanner, parser, and IR generator. But where is the main entrance and how about the flow of the process, especially about the IR generator? > shding at mtu.edu wrote: >> Hi, >> Where can I find the main function of llvm compiler in the source >> file? >>

You all just need remove "stacker_rt.ll". the stacker_rt.ll is a generated file, not source. The Makefile should have a dependency on llvm-gcc for it, but doesn't. Just remove stacker_rt.ll and the problem will go away. Reid. On Sat, 2006-12-30 at 08:37 -0500, Nick Lewycky wrote: > Jim Laskey wrote: > > llvm[4]: Compiling stacker_rt.ll to stacker_rt.bc for Release build

A while ago I reported a bug in the computation of the post-dominance frontier (PDF). I submitted it as http://llvm.org/bugs/show_bug.cgi?id=1069, and it is now marked as a duplicate of http://llvm.org/bugs/show_bug.cgi?id=1098, which is still an open bug. I needed the PDF to compute control dependencies for code on which I'm working. I was not familiar with the algorithm used in LLVM

June Status Update ------------------ Hi everyone, Since the last status update, we've had a lot of progress on various fronts. In particular, we passed the 15,000th commit to the llvm-commits list, we have some great new features and documentation, new people using LLVM, and (strangely enough) the MachineBasicBlock class seems to have received a lot of love. At this point, I'm