similar to: [LLVMdev] Missing passes

On 2008-05-07, at 08:42, Matthijs Kooijman wrote: > I was evaluating all transformation passes and noticed a few things. > In particular, I found three passes in the documentation that I > can't seem to find any code for. Where these removed? > Lower GC intrinsics, for GCless code generators (-lowergc) Yes; this pass at least has been removed. > Correlated Expression

Hi all, I've attached two patches. The first, pass-comments.diff adds or improves the file comments for a number of passes. This patch is slightly interesting. The second, pass-doc.diff is mostly a yank-put job and updates Passes.html as follows. I've removed the following passes from the documentation: Lower GC intrinsics, for GCless code generators (-lowergc) Correlated Expression

Hi, Until recently I've been building LLVM with SHARED_LIBRARY=1. However, sith current svn, build now fails with unresolved symbols building opt. I've done a clean checkout, configure and make so it's not down to any local changes I've made. I'm building with: ./configure --enable-assertions \ --enable-expensive-checks=no \ --enable-pic \ --enable-targets=host-only \

On 7/26/05, Reid Spencer <reid at x10sys.com> wrote: > On Tue, 2005-07-26 at 17:25 -0700, Michael McCracken wrote: > > > Since I'm modifying llc, I have a couple small questions about that code: > > > > opt and analyze (and a couple of other places) add a verifier pass, > > but llc doesn't. > > This would seem to make sense for llc as well -

Dear LLVM guys, I am getting an error with my pass implementation, and I cannot figure it out. Basically, I've implemented part of a register allocation algorithm, but I am having problems to set the passes correctly. For instance, for this program below, the following error message is produced: .c ----------------------| .bc ---------------------------------

On Tue, 26 Jul 2005, Michael McCracken wrote: >> I can't see any harm in that. However, please make sure that it really >> isn't being run. The verifier can be hidden by various levels of >> abstraction. > > Assuming that I get everything with -debug-pass=Structure, then it isn't: -debug-pass=Structure does list everything. If you add it, please add it in an

I suspect my change adding --enable-shared broke you, since that configure option didn't exist before last week (r97119). SHARED_LIBRARY is not one of the variables you're supposed to be able to set on make's command line (http://llvm.org/docs/MakefileGuide.html#variables). What are you using it for? What happens if you remove it? On Tue, Mar 2, 2010 at 1:35 PM, James Williams

On Tue, 2005-07-26 at 17:25 -0700, Michael McCracken wrote: > Since I'm modifying llc, I have a couple small questions about that code: > > opt and analyze (and a couple of other places) add a verifier pass, > but llc doesn't. > This would seem to make sense for llc as well - should I add it, with > the corresponding > hidden -no-verify option? I can't see any

Attached is my patch that adds a (debug build only) verifier pass and support for creating passes specified on the command line to llc. Let me know if it needs changes to be acceptable. One thing I noticed is that (eg.) opt and analyze have their options and globals in an anonymous namespace while llc doesn't. I just used llc's convention - which is preferable? As to testing - It works

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

On Fri, 23 Jun 2006, Fernando Magno Quintao Pereira wrote: > I am getting an error with my pass implementation, and I cannot figure > it out. Basically, I've implemented part of a register allocation > algorithm, but I am having problems to set the passes correctly. For > instance, for this program below, the following error message is > produced: It's hard to say

On 7/25/05, Reid Spencer <reid at x10sys.com> wrote: > On Mon, 2005-07-25 at 21:48 -0700, Michael McCracken wrote: > > On 7/25/05, Reid Spencer <reid at x10sys.com> wrote: > > > Why not just create your pass as a shared object and: > > > > > > opt -load mypass.so -mypass | llc > > > > My pass is an implementation of an analysis group that

Dear LLVM guys, I've solved my problem with the passes, and compiled my first code using the new register allocator! Debugging was quite easy, using gdb. The problem was that I was forgetting to initialize the array that records the physical registers ever used (MachineFunction::UsedPhysRegs). This is a very minor thing, but I would suggest asserting that the vector has been initialized

On May 7, 2008, at 7:04 AM, Gordon Henriksen wrote: > On 2008-05-07, at 08:42, Matthijs Kooijman wrote: > >> I was evaluating all transformation passes and noticed a few things. >> In particular, I found three passes in the documentation that I >> can't seem to find any code for. Where these removed? >> Lower GC intrinsics, for GCless code generators (-lowergc)

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

Михаил wrote: > How correctly remove function from module? > For example: > > int f1(int x) { > ... > a = f2(smth); > ... > } > int f2 (int y) { > ... > b = f1(smth); > ... > } > > I need delete from module both f1 and f2. They haven't uses in other > part of module, but I can't delete them with eraseFromParent, because > they are use each

How correctly remove function from module? For example: int f1(int x) { ... a = f2(smth); ... } int f2 (int y) { ... b = f1(smth); ... } I need delete from module both f1 and f2. They haven't uses in other part of module, but I can't delete them with eraseFromParent, because they are use each other. Yours sincerely, Kadysev Mikhail -------------- next part

Hi, A number of transforms are actually independent, so here's a partial fix. I updated the dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect, LowerAllocations, UnifyFunctionExitNodes. The patch has been tested, but not extensively. PassManager doesn't complain, and the result of a test pass that requires all these (except for LowerAllocations) together works