similar to: [LLVMdev] Optimization passes and debug info

On Jul 8, 2008, at 3:33 AM, Matthijs Kooijman wrote: > Hi all, > > I've been fiddling around with debug info generated by clang, with > the goal of > propagating line number info to our custom backend (which is not an > llvm > backend, but does use llvm IR as its input). Cool. > I've created a small pass which strips all debug info except for > stop

Hi Chris, > > From this observation, I think it might be useful to have some kind of > > global flag that tells transformations whether it is allowed to remove > > debugging code in favour of optimizations. When we start making > > transformation passes debug-info aware, I think the need for something > > like this might increase. > > I think that the right

Hi Chris, > I just meant -O3 as an example. I'd expect all -O levels to have the > same behavior. -O3 may run passes which are more "lossy" than -O1 > does though, and I'd expect us to put the most effort into making > passes run at -O1 update debug info. I'm not really sure that you could divide passes into "lossy" and "not so lossy"

On Jul 23, 2008, at 8:08 AM, Matthijs Kooijman wrote: > Hi Chris, > >> I just meant -O3 as an example. I'd expect all -O levels to have the >> same behavior. -O3 may run passes which are more "lossy" than -O1 >> does though, and I'd expect us to put the most effort into making >> passes run at -O1 update debug info. > I'm not really sure

On Jul 21, 2008, at 8:21 AM, Matthijs Kooijman wrote: >> I think that the right answer for llvm-gcc at "-O3 -g" is >> (eventually) >> for debug info to be updated where possible but discarded when >> necessary as you describe. For llvm-gcc we really really want the >> non- >> debug related output of the compiler to be identical between

Hi all, I'm currently struggling with a few optimization passes that change stuff I don't want to be changed. However, for the most part those passes (InstructionCombining and SimplifyCFG currently) do stuff that I do want, so disabling them alltogether doesn't help me much. The problem arises because the architecture I'm compiling for is quite non-standard. In particular, it has

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, just a quick email. I've been working on a patch to simplifycfg last week and want to test its performance. I've ran the test-suite succesfully, both with the patched and unpatched versions. However, I could find no easy way to compare both results. I see that the web pages of the nightly tester provide nice results (changes compared to the day before, together with percentages and

https://bugzilla.mindrot.org/show_bug.cgi?id=2621 Bug ID: 2621 Summary: ControlMaster started by scp (non-ssh?) doesn't forward agent Product: Portable OpenSSH Version: 7.3p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: Miscellaneous

Hi all, I'm having some trouble building llvm-gcc as of today, with and without bootstrap. The error I get is: /home/kooijman/src/llvm-gcc/obj/./gcc/xgcc -B/home/kooijman/src/llvm-gcc/obj/./gcc/ -B/home/kooijman/src/llvm-gcc/obj/../install/i686-pc-linux-gnu/bin/ -B/home/kooijman/src/llvm-gcc/obj/../install/i686-pc-linux-gnu/lib/ -isystem

Hi all, I've been discussing parameter attributes and their impact on first-class struct parameters. Duncan and I came to the conclusion that the only attribute that could be applied to structs currently, is the inreg attribute. However, since there is no support anywhere for that currently (transformation passes and backends?), it might be better to disallow the inreg attribute for struct

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

Hello, I am trying to replicate the output from opt -O3 foo.bc -o foo.opt.bc by specifying the individual passes instead of the -O3 flag. Looking at the passes from opt -O3 foo.bc -o foo.bc -debug-pass=Executions it seems there are two passes being run. When I run the flags indicated for the two passes specified in the 'Pass Arguments:' as two sequential opt processes or a single opt

On Wed, 21 May 2008, Mike Stump wrote: > On May 21, 2008, at 8:09 AM, Matthijs Kooijman wrote: >> Any thoughts or suggestions on how to do this testing in a >> structured manner? > > I think that if what you're doing is sound, and you get the results > you want, say, on compiling something like gcc with it and others > review the basic idea (hi evan or chris) and

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

Hi all, I've also been developing an interest in using IR annotations for my compiler. Some discussion with Bart turns out that he has implemented some code to parse the llvm.globals.annotations array, but in no way integrated or reusable. We've spent some thought about how this could be done properly, which I will share here. Firstly, however, I was wondering about the format of the

Hi, I've been struggling with constantexprs for a bit. I'm working on a pass that transforms global variables to local variables, and in particular the GetElementPtrConstantExpr is a bit troublesome. For my transformation to properly work, a global value should only be used by Instructions, not by ConstantExprs. I was thinking to add a ConstantExpr::replaceWithInstr() virtual method,

Hi all, about a month ago, I've started working on my master's thesis. Since I want to focus on just that work, I've stopped my LLVM work for now. It is unclear whether I will continue my work after graduation, but it seems unlikely. I'll still keep track of LLVM from a personal interest (mostly watching the IRC channel), but I won't have the time to track any mailing lists.

[Moving discussion to LLVMdev] On 2008-10-31 21:55, Dan Gohman wrote: > Hi Török, > > @llvm.dbg.stoppoint actually does read and write memory, in a > sense. It's a point where a user could stop in a debugger, and > use the debugger to both read and write memory. If the optimizers > are allowed to reorder or delete memory operations, these > intrinsics will become

On Tue, Jul 8, 2008 at 2:28 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Hi all, > > I've been discussing parameter attributes and their impact on first-class > struct parameters. Duncan and I came to the conclusion that the only attribute > that could be applied to structs currently, is the inreg attribute. However, > since there is no support anywhere for