search for: heurist

...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, so...

...oc((&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; However, if I am understanding correctly, the first node is being allocated in one pool (that was malloc with the other heuristic) and the rest are being allocated in a differente pool. But why? Why not all the nodes are being allocated in one pool? Also, in your other response you said: >> The AllNodes heuristic is the only one that is substantially tested. I >> would recommend it, none of the others have an...

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...

...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...

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 flag on by default, I want th...

...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 voi...

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 t...

...to achieve this? Ah, sorry, my memory was wrong. The default is to perform the "SelectivePA" optimization. Since pool allocation detected that there is no point in putting a single allocation into a pool, it left it a malloc. If you really want it to be a in a pool, pass -poolalloc-heuristic=AllNodes to opt. Sorry for the confusion! -Chris > I am using this line: > opt -load ~/llvm/install/lib/libpoolalloc.so -poolalloc > and also with -pooloptimize > > Thanks in advance > > > > > --- Chris Lattner <sabre at nondot.org> wrote: > >> On S...

...I am receiving this > error: > > > > ==================== > > > > *** 4 DYNAMIC POOLS INITIALIZED *** > > > > *** 4 DYNAMIC POOLS ALLOCATED FROM *** > > > > MaxHeapSize = 0.062500KB HeapSizeAtExit = 0.062500KB NOTE: only valid if using > > Heuristic=AllPools and no bumpptr/realloc! > > ==================== > > This output is what happens when you link with the debug version of the > runtime library. If you rebuild the FL2Allocator with 'make > ENABLE_OPTIMIZED=1' and link with the result, you shouldn't get t...

...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: >> >>&gt...

...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(uns...

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 presence/absence of loops. -Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140809/f3049acd/attachme...

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 k...

...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...

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

...e (> 10K functions), the total number of spills across such a statistically significant sample is believed to give a very strong indication about each scheduler's performance at reducing register pressure. The differences in the table below are calculated relative to the source scheduler.   Heuristic Total Source       Spills Spills Spill Difference % Spill Difference Source 294471 294471 0 0.00% ILP 298222 294471 3751 1.27% BURR 287932 294471 -6539 -2.22% Fast 312787 294471 18316 6.22% source + MI 294979 294471 508 0.17% ILP + MI 296681 294471 2210 0.75% BURR + MI 289328 294471 -514...

...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...

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 member named 'getTypeAlignment' There seem to be 3 methods in T...

...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...

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