search for: heuristical

On Sep 17, 2013, at 11:04 AM, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > 1. The SD schedulers significantly impact the spill counts and the execution times for many benchmarks, but the machine instruction (MI) scheduler in 3.3 has very limited impact on both spill counts and execution times. Is this because most of you work on MI did not make it into the 3.3 release?

Thanks Chris! That was causing me some confusion. Now it's producing a more meaningful output: poolinit((&l2_GlobalPool), 4u, 4u); poolinit((&l2_GlobalPool1), 4u, 4u); l5_tmp_2E_0_2E_i = poolalloc((&l2_GlobalPool), 4u); l6_tmp_2E_7_2E_i2 = l1_makeList((&l2_GlobalPool1), 0); *(&((struct l_struct_2E_list *)l5_tmp_2E_0_2E_i)->field0) = l6_tmp_2E_7_2E_i2;

Hi Jessica, The comparison to the inliner is an interesting one but we think it's important to note the difference in the use of heuristics. The inliner is juggling many different tasks at the same time, execution speed, code size, etc. which can cause the parameters to be very sensitive depending on the benchmark/platform/etc. The outliners heuristics are focused solely on the potential code

On Mar 15, 2006, at 11:15 AM, Chris Lattner wrote: > On Wed, 15 Mar 2006, Vikram S. Adve wrote: >>> Why can't the compiler pass just call InlineFunction(CallSite) on >>> the callsite it wants inlined? The only way that can fail is if >>> LLVM cannot ever inline the call (e.g. it uses varargs). > >> In some cases, that would be fine. But in other

Hi, I'm trying to turn on a flag (-inline-generic-switch-cost) introduced in r301649 which improved the inline cost heuristic for switch. In my experiment for LLVM test suite and spec2000/2006 in AArch64, +17.82% performance and -8% code size reduce was observed in spec2000/vertex with O3 LTO. No significant code size / performance regression was found in O3/O2/Os. Before we turn this

Hi, we've implemented an indirect call promotion llvm pass. The design notes including examples are shown below. This pass complements the indirect call profile infrastructure http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084271.html Your feedback and comments will be highly appreciated. Thanks, Ivan ============================================================================RFC:

Hi Quentin, I appreciate the feedback. When I reference the cost of Target Hooks it's mainly for maintainability and cost on a target author. We want to keep the intrusion into target information minimized. The heuristics used for the outliner are the same used by any other IR level pass seeking target information, i.e TTI for the most part. I can see where you are coming from with

On Sat, 2 Apr 2005, Ricardo wrote: > After applying the PA to it, the output is something like this: ... > My question is: why is this malloc necessary? > ltmp_2_5 = malloc(4u); > Shouldn't be the result a program with this malloc replaced by poolalloc? > Should I include a special flag to achieve this? Ah, sorry, my memory was wrong. The default is to perform the

Thanks for the answer I am trying to test the PA with a program very similar to the one used as an example in the paper located here: http://llvm.cs.uiuc.edu/pubs/2003-04-29-DataStructureAnalysisTR.html The program is as follows: ========================== struct list { struct list *Next; }; struct list *makeList (int Num) { struct list *New = malloc ( sizeof ( struct list ) );

Vikram S. Adve wrote: Hmmm. It seems the discussion has grown a little bit larger than I had intended. :) Basically what I think would be useful is an option to the inliner that gives it a list of functions to skip when inlining. My argument for this is that we have several transformations now that search for calls to specific functions; if those functions are inlined, the transform pass

2009/6/12 Bob Wilson <bob.wilson at apple.com> > Thanks, this should be useful. What problem did you have with svn > revisions after 70786? /tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/xgcc -B/tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/ -B/tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/bin/

I'm facing a situation where I have generated IR that only needs to be executed once. I've noticed for simple IR it's faster to run the interpreter on it, but for complex IR it's much better to JIT compile and execute it. I'm seeking suggestions for a good heuristic to decide which approach to take for any given IR. I'm leaning in favor of deciding based on the

Hello again! Previously, I introduced myself as a prospective GSoC student interested in LLVM. Per Mr. Doerfert suggestion I took a look at two other projects that he said could interest me due to my ongoing research in autotuning. The projects are: Advanced Heuristics for Ordering Compiler Optimization Passes Machine learning and compiler optimizations: using inter-procedural analysis to select

2017-07-24 16:14 GMT-07:00 Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org>: > Hi River, > > On Jul 24, 2017, at 2:36 PM, River Riddle <riddleriver at gmail.com> wrote: > > Hi Quentin, > I appreciate the feedback. When I reference the cost of Target Hooks it's > mainly for maintainability and cost on a target author. We want to keep the >

On Jun 11, 2009, at 7:18 PM, Misha Brukman wrote: > I've committed my scripts that simplify building Linux/x86 -> Linux/ > ARM crosstool. There are 2 parts to using this: > > * llvm/utils/crosstool/create-snapshots.sh > creates tarballs for LLVM and LLVM-GCC from HEAD SVN or a specific > revision of your choice > * llvm/utils/crosstool/ARM/build-install-linux.sh

Hi Andy, We have done some experimental evaluation of the different schedulers in LLVM 3.3 (source, BURR, ILP, fast, MI). The evaluation was done on x86-64 using SPEC CPU2006. We have measured both the amount of spill code as well as the execution time as detailed below. Here are our main findings: 1. The SD schedulers significantly impact the spill counts and the execution times for many

On Mon, Jul 24, 2017 at 4:14 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi River, > > On Jul 24, 2017, at 2:36 PM, River Riddle <riddleriver at gmail.com> wrote: > > Hi Quentin, > I appreciate the feedback. When I reference the cost of Target Hooks it's > mainly for maintainability and cost on a target author. We want to keep the

I tried to compile the currently checked in version of llvm-poolalloc with the curently checked in version of llvm and got the following errors: llvm[4]: Compiling Heuristic.cpp for Debug build (PIC) Heuristic.cpp: In function 'bool Wants8ByteAlignment(const llvm::Type*, unsigned int, const llvm::TargetData&)': Heuristic.cpp:77: error: 'const class llvm::TargetData' has no

2017-07-26 9:31 GMT-07:00 Quentin Colombet <qcolombet at apple.com>: > > On Jul 25, 2017, at 10:36 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2017-07-24 16:14 GMT-07:00 Quentin Colombet via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Hi River, >> >> On Jul 24, 2017, at 2:36 PM, River Riddle <riddleriver at

Hello, I'm working on an Opus encoder block for GNUradio (a signal processing toolkit). I was wondering if there's some formula/heuristic for estimating the packet size average case / worst case given a certain encoder setting (assuming VBR). I need to provided a reasonable estimate to the GNUradio memory allocator. --Albin