similar to: CFG normalization: avoiding `br i1 false`

> I'm not necessarily sympathetic to the idea of adding another canonicalization pass only for this purpose. The problem is that as you said, SimplifyCfg does all sorts of stuff, and I suspect is not the fastest pass in the world. Also, in the case that annoys me, there is an LCSSA pass in the middle, and I suspect it would be a better idea to only do the LCSSA etc. transform again if no

There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate with other loop passes) and eliminates trivial branches.  Having a simple pass which just strips unreachable blocks and converts conditional branches to unconditional ones while updating appropriate analyzes (LoopInfo, DomTree, LCSSA, etc..) seems very reasonable.  This could also be a utility function called

On Wed, Nov 29, 2017 at 9:48 AM, Philip Reames <listmail at philipreames.com> wrote: > There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate > with other loop passes) and eliminates trivial branches. Having a simple > pass which just strips unreachable blocks and converts conditional branches > to unconditional ones while updating appropriate analyzes

Hi Davide, > On Nov 29, 2017, at 1:08 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Nov 29, 2017 at 9:48 AM, Philip Reames > <listmail at philipreames.com> wrote: >> There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate >> with other loop passes) and eliminates trivial branches. Having a simple

[ + cc llvm-dev]. This came up again internally and I realized I hadn’t cc’ed llvm-dev in my original response. Anna On Dec 4, 2017, at 7:06 PM, Anna Thomas via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Davide, On Nov 29, 2017, at 1:08 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at

> we lower llvm.objectsize later than we should Is there a well-accepted best (or even just better) place to lower objectsize? I ask because I sorta fear that these kinds of problems will become more pronounced as llvm.is.constant, which is also lowered in CGP, gains popularity. (To be clear, I think it totally makes sense to lower is.constant and objectsize in the same place. I'm just

Hi, I have come across a couple of cases where the code generated after CodeGenPrepare pass has "br i1 false .." with both true and false conditions preserved and this propagates further and remains the same in the final assembly code/executable. In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which handles the br i1 false condition) is called only once and if after the

Rust pattern matching code can sometimes generate very redundant LLVM IR, in which several branches contain exactly the same code. LLVM successfully unifies that, but the dispatching mechanism does not simplify accordingly. I created a gist here: https://gist.github.com/ranma42/d2e6d50999e801ffd4ed (based on two examples available in Rust issues:

Hi, This is Ariel from the Rust team again. I am having another pass ordering issue. Looking at the pass manager at https://github.com/llvm-mirror/llvm/blob/7034870f30320d6fbc74effff539d946018cd00a/lib/Transforms/IPO/PassManagerBuilder.cpp (the early SimplifyCfg now doesn't sink stores anymore! I can't wait until I can get to use that in rustc!) I find that the loop optimization group

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

I've been looking at compilation time issues in the LICM pass, and it looks to me like colorEHFunclets() is probably being called a lot more often than it needs to be for functions that have Windows EH personality functions. For one thing, the funclet coloring is happening when computeLoopSafetyInfo() is called from LoopIdiomRecognize and LoopUnswitch but those passes don't use the

Probably the issue is solvable in some Codegen prepare pass. That said I still believe some kind of control on if we would like to implement this or not could be useful. Just a question. Why implementing it in SimplifyCFG and not as a separate pass like JumpThreading or something like that? The transformation itself doesn’t seem to fit much in SimplifyCFG. > On 2 Sep 2016, at 13:35, Michael

I think it would make sense for (1) and (2). I am not sure if (3) is feasible in instcombine. (I am not too familiar with LoopInfo) For the Octasic's Opus platform, I modified shouldMergeGEPs in our fork to: if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() && !Src.hasOneUse()) return false; return Src.hasAllConstantIndices(); // was return false;

I've been added various optimizer passes and I end up with code which looks like this: define i32 @main() uwtable { entry: store i32 ()* @_main_1, i32 ()** @_main, align 8 br label %end end: ; preds = %entry ret i32 0 } Is there another pass to get rid of that "br" instruction and just inline the "end" block? -- edA-qa

Hi, I am planning to use LLVM in my compiler dev project. I would like to know what power LLVM code optimization phase provides to my code ? I had a look at http://llvm.org/docs/Passes.html which describes the optimization passes. >From a newbie standpoint can you please explain the power of LLVM optimization? Thank you, Prakash -------------- next part -------------- An HTML attachment was

Hi Mark, It is not clear to me at all that preventing the merging is the right solution. There are a large number of analysis, including alias analysis, and optimizations that use GetUnderlyingObject, and related routines to search back through GEPs. They only do this up to some small finite depth (six, IIRC). So reducing the GEP depth is likely the right solution for InstCombine (which has the

All, I have some code that looks like the following: { double a, b, c; for (...) { ... a = lots of FP math; b = lots of FP math; c = lots of FP math; if (cond) { a = 0.0; b = 0.1; c = 0.2; } ... } } Could we not convert the hammock into a diamond and move the initial computation of a, b, and c into the else block. Something like this: {

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of edA-qa mort-ora-y > Subject: [LLVMdev] pass to eliminate unneeded "br" statements > define i32 @main() uwtable { > entry: > store i32 ()* @_main_1, i32 ()** @_main, align 8 > br label %end > end: ; preds = %entry >

On 13/04/13 06:13, Caldarale, Charles R wrote: > I would think SimplifyCFG should take care of it. Yes, thank you. I just had to get the order of my passes correct (it was being done too early). -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail.

From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> Rust bindings: Add create / close functions Rust bindings: Add 4 bindings tests Rust bindings: Add generator of structs Rust bindings: Add generator of structs for optional arguments Rust bindings: Add generator of function signatures Rust bindings: Complete actions Rust bindings: Fix memory management Rust bindings: Add