similar to: [LLVMdev] -loop-deletion commandline option inconsistent?

Hi, > the newly added LoopDeletion pass uses loop-deletion as it's name (and thus > commandline option for opt). Looking at the other loop passes (loop-rotate, > loop-unroll, loop-reduce), perhaps loop-delete would be a better name? No opinions on this? If this is ever going to be changed, it's probably a good idea to do it before the 2.3 release, not after... Gr. Matthijs

>> the newly added LoopDeletion pass uses loop-deletion as it's name (and thus >> commandline option for opt). Looking at the other loop passes (loop-rotate, >> loop-unroll, loop-reduce), perhaps loop-delete would be a better name? > No opinions on this? If this is ever going to be changed, it's probably a good > idea to do it before the 2.3 release, not after...

On May 8, 2008, at 05:50, Matthijs Kooijman wrote: > 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. Thanks, applied!

Hi, 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) Correlated Expression Elimination (-cee) Lower select instructions to branches (-lowerselect) Additionally, I found the following passes for

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

Hello Matthijs, Separating mechanism from policy is a good thing for the LoopUnroll pass. Instead of moving the policy to a subclass though, I think it'd be better to move the mechanism, the unrollLoop function, out to be a standalone utility function, with the LoopInfo object passed in explicitly. FoldBlockIntoPredecessor would also be good to make into a standalone utility function, since

Hello Matthijs, On May 9, 2008, at 3:47 AM, Matthijs Kooijman wrote: > Hi All, > > the attached patch performs the splitting in the proposed manner. > before applying the patch, please execute > svn cp lib/Transforms/Scalar/LoopUnroll.cpp lib/Transforms/Utils/ > UnrollLoop.cpp > to make the patch apply and preserve proper history. > > Transforms/Utils/UnrollLoop.cpp

Hi Dan, > This should still make it easy to write new unrolling passes with > custom heuristics, but it would also be more flexible for passes to > do unrolling in combination with other transformations. Agreed. To shed some light on my specific requirements, I am working with an architecture that has only limited support for loops and control flow. This means that loop unrolling is not

Hi all, I was looking at the Internalize patch, and decided to clean it up a bit. The attached patch makes two functional changes to the pass: 1. If both -internalize-public-api-file and -internalize-public-api-list options are given on the commandline, only -file was used. Now, all options are respected and the contents of the file merged with the items given with the -list option(s). I

Hi, I think I have quite an identical patch lying around somewhere here, but I thought that the AutoRegen.sh was something someone wrote here in-house, so I never bothered to send it somewhere. I do remember someone saying (on this list) one should really not use another version of autoconf, but in my experience 2.6 works just as fine for building an addon project (but perhaps not for rebuilding

Hi, the attached patch splits the loop unroll pass into a LoopUnroll superclass that implements the unrolling mechanism, and a SimpleLoopUnroll subclass implementing the current policy. This split is modeled after the split between Inliner and SimpleInliner. The superclass currently still finds out the TripCount and TripMultiple, and passes those, together with the Loop in question, to a policy

Hi Tanya, > 2.3 has already branched and loop delete is not on by default. This can be > changed after. Doesn't that just mean that it's not part of std-compile-opts, and thus the only way to use it is the (inconsistent) -loop-deletion commandline option? I'm just saying that it might be better not to change a commandline option between releases if it's not needed.

Andrew Clinton wrote: > Most of my programs contain loops that the LoopDeletion pass is unable > to remove. It appears that the following code in LoopDeletion.cpp:152 > is the culprit: > > ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); > const SCEV *S = SE.getMaxBackedgeTakenCount(L); > if (isa<SCEVCouldNotCompute>(S)) > return

Hi, please find an updated patch attached that incorporates the (trivial) changes introduced by r50696 and which makes this patch apply cleanly again. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: split-unroll.diff Type: text/x-diff Size: 14660 bytes Desc: not available URL:

Most of my programs contain loops that the LoopDeletion pass is unable to remove. It appears that the following code in LoopDeletion.cpp:152 is the culprit: ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); const SCEV *S = SE.getMaxBackedgeTakenCount(L); if (isa<SCEVCouldNotCompute>(S)) return Changed; So, LoopDeletion thinks my loops might be infinite so it

Hello All, I filed a bug https://bugs.llvm.org/show_bug.cgi?id=35884 which I want to fix but I'm in trouble with detecting who is wrong :) The story is as follows: LoopDeletion tries to delete an invariant loop which has a def with use in some unreachable block. The IR is well-formed due to any use in unreachable block is dominated as Verifier states. LoopDeletion detected the loop as

Hi Dan, please find an updated patch attached (don't forget to run the svn cp command I posted earlier, before applying this patch). I've incorporated all the changes we've discussed. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:

On 11/25/2010 12:59 PM, Andrew Clinton wrote: > On 11/24/2010 06:55 PM, Owen Anderson wrote: >> On Nov 23, 2010, at 9:22 AM, Andrew Clinton wrote: >> >> >>> Most of my programs contain loops that the LoopDeletion pass is unable >>> to remove. It appears that the following code in LoopDeletion.cpp:152 >>> is the culprit: >>> >>>

On 11/24/2010 06:55 PM, Owen Anderson wrote: > On Nov 23, 2010, at 9:22 AM, Andrew Clinton wrote: > > >> Most of my programs contain loops that the LoopDeletion pass is unable >> to remove. It appears that the following code in LoopDeletion.cpp:152 >> is the culprit: >> >> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >>

Hi, > Aggregates as First Class Values: it seems to me that having this would make the byval parameter attribute partly obsolete? Will there be semantic differences between passing a struct directly and a pointer to a struct byval? I can see that byval can be used on pointers to other things, but is that really useful? I can't see any use for compiling C code, are there other languages