search for: heuristics

...any of your questions. Some important things changed between the time I introduced the MI scheduler a year ago, and the release of 3.3. The biggest change was loop vectorization, which reduces register pressure and somewhat preschedules loops. Since 3.3 was released, the generic MI scheduler's heuristics were reevaluated in preparation for making it the default for targets without a custom scheduling strategy--more on that later. The source order scheduler was also fixed so that it actually preserves IR order, which is at least closer to source order. For many benchmarks we've looked at, sourc...

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 size savings from outlining, and is thus on...

...ave a "used" list but that's presumably used for other things. > a transformation could add any function it wants to this list to > prevent the inliner from inlining it in the future. > > Aside from that, I don't see what uninlining has to do with > inlining heuristics, can you explain a bit more? I'm not sure what there is to explain. Inlining heuristics control what to inline. If you're writing a tool, you'd want to run the inliner while influencing what it chooses to inline. >> (2) It requires writing a driver loop nest to go over al...

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

...ugh branch containing the original indirect call. The ICP optimization is found to be the second most profitable (after inlining) profile-based optimization in a recent study [2]. We've implemented an ICP LLVM pass that iterates over all indirect call sites in the module and selectively (under heuristics) performs the promotion. Here is one example of the transformation. --------------------ico.ll-------------------------------------------------- define void @foo(i32 %a) { entry: %a1 = add i32 %a, 1 ret void } define void @bar(i32 %a) { entry: %a2 = add i32 %a, 2 ret void } define void @...

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 "having heuristics solely focused on code size do not seem realistic", but I don't agree with that statement. I think ther...

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 ) );

...I need at the moment. I think Chris indicated in an earlier email that such a command line option is now okay. Chris, please let me know if I understand that correctly. The ability to control inlining from the source code being compiled (i.e. GCC's noinline attribute), adjust the inlining heuristics programmatically from a custom built LLVM tool, etc, are beyond the scope of what I need. Hopefully that clears up what I was asking about. -- John T. > > On Mar 15, 2006, at 11:15 AM, Chris Lattner wrote: > >> On Wed, 15 Mar 2006, Vikram S. Adve wrote: >> >>>&g...

...none-linux-gnueabi/include -isystem /tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I. -I/tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g -O2 -MT mf-heuristics.lo -MD -MP -MF .deps/mf-heuristics.Tpo -c /tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap/mf-heuristics.c -fPIC -DPIC -o .libs/mf-heuristics.o cc1: /tmp/llvm-project.p28262/src/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:134: llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsign...

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 optimizations And he was right! Now, what are the next steps concerning these projects? I know I have to choose one, but that is a difficult decision, so I wanted to know...

...6 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 > 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 "having heuristics solely focused on code size do not seem > realistic", but I don't agree with that sta...

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

...6 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 > 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 "having heuristics solely focused on code size do not seem > realistic", but I don't agree with that sta...

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

...lt;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 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 "having heuristics solely focused on code size do not >> seem realistic", but I don't agr...

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