search for: inductionvari

LLVM, What is the status of the InductionVariable "semi-pass"? I have tested it out on spec benchmarks, and while it does correctly identify some of the variables, it fails to recognize most. Typically the following scenario arises a_loop: ... %tmp.19 = load int* %bsLive %tmp.20 = add int %tmp.19, -8 store int %tmp.20, int* %bsLiv...

Hello LLVM, Can you suggest a good way to use the loops and induction variable passes to map loop exiting BasicBlocks to InductionVariables. That is, can we use these tools to identify the loop condition. What i have tried Function Pass: foreach BB if(terminal is loop exit of containing loop) trace back to instruction producing the cond that the branch branches on - condProducer foreach(inst in loop head...

> Can you suggest a good way to use the loops and induction variable > passes to map loop exiting BasicBlocks to InductionVariables. That is, > can we use these tools to identify the loop condition. I can try. :) It looks like you're running into problems because we don't perform "Linear Function Test Replacement". This optimization would reduce the amount of code which occurs between the inductio...

Hi all, I've started looking at the GlobalMerge pass, enabled by default on ARM and AArch64. I think we should reconsider that, at least for AArch64. As is, the pass just merges all globals together, in groups of 4KB (AArch64, 128B on ARM). At the time it was enabled, the general thinking was "it's almost free, it doesn't affect performance much, we might as well use it".

Hi, I'm working on project which involves writing a backend for a hypothetical architecture. I am currently trying to figure out the best way to translate for loops to use a specialized "loop" instruction the architecture supports. The instruction is similar X86's loop instruction, where a register is automatically decremented and the condition is automatically checked to see if

...18858|2.139128559| 0|16924618893| 0|2.139481883| -0.02|16924618893| 0| |MultiSource/Benchmarks/TSVC/IndirectAddressing-flt/IndirectAddressing-flt.test| 40|1.797690481|16924004255|1.798647228| -0.05|16924004256| 0|1.797408641| 0.02|16924004255| 0| |MultiSource/Benchmarks/TSVC/InductionVariable-dbl/InductionVariable-dbl.test | 40|2.393466475|16204217793|2.382771124| 0.45|16204217795| 0|2.390437006| 0.13|16204217795| 0| |MultiSource/Benchmarks/TSVC/InductionVariable-flt/InductionVariable-flt.test | 40|1.765705552|15096881613|1.758229966| 0.43|15096881614| 0|1.763...

tl;dr in low data situations we don’t look at past information, and that increases the false positive regression rate. We should look at the possibly incorrect recent past runs to fix that. Motivation: LNT’s current regression detection system has false positive rate that is too high to make it useful. With test suites as large as the llvm “test-suite” a single report will show hundreds of

...) nts.MultiSource/Benchmarks/TSVC/ControlFlow-flt/ControlFlow-flt.exec > 24. 47.73% cumulative (0.84% - 48.74s this program) nts.MultiSource/Benchmarks/TSVC/CrossingThresholds-dbl/CrossingThresholds-dbl.exec > 25. 48.57% cumulative (0.84% - 48.43s this program) nts.MultiSource/Benchmarks/TSVC/InductionVariable-dbl/InductionVariable-dbl.exec > 26. 49.40% cumulative (0.83% - 47.92s this program) nts.SingleSource/Benchmarks/Polybench/datamining/correlation/correlation.exec > 27. 50.22% cumulative (0.81% - 46.92s this program) nts.MultiSource/Benchmarks/TSVC/NodeSplitting-flt/NodeSplitting-flt.exec...

...967 -4.7109549664643 Applications/oggenc/oggenc 0.077 0.0735 -4.5454545454545 Benchmarks/BitBench/uuencode/uuencode 0.0119 0.0114 -4.2016806722689 Benchmarks/Prolangs-C/unix-smail/unix-smail 0.0024 0.0023 -4.1666666666666 Benchmarks/TSVC/InductionVariable-dbl/Induc 2.9528 2.8362 -3.9487943646708 Benchmarks/TSVC/NodeSplitting-dbl/NodeSplit 2.7203 2.6209 -3.6540087490350 Applications/d/make_dparser 0.0174 0.0168 -3.4482758620689 Applications/lambda-0.1.3/lambda 2.6777 2.5864 -3...

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