search for: optsiz

...erstand the attributes correctly, they would be function-level attributes applied to IR functions, correct? I'm curious what the semantics would be for cross-function optimization. For example, consider a function "foo" defined with maxopt and a function "bar" defined with optsize. If foo() calls bar() and the inliner wants to inline bar() into foo(), is that legal? If so, that may cause odd effects as you may perform expensive optimizations later on the inlined version of bar(), even though the original function is marked optsize. Also, a nit-pick: can we make the nami...

...18:15, Min-Yih Hsu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David mentioned in D87337 that LLVM has used similar techniques on code > size (not sure what he was referencing, my guess will be something related > to hot-cold code splitting). > IIUC, it's just using optsize instead of optnone. The idea is that, if the code really doesn't run often/at all, then the performance impact of reducing the size is negligible, but the size impact is considerable. I'd wager that optsize could even be faster than optnone, as it would delete a lot of useless code... but...

Hi, On 08/07/2015 10:30 PM, Nick Lewycky wrote: [...] > Depends. What is the exact declaration of format_long? > > > In the input .ll file it is: > > ; Function Attrs: minsize optsize > define internal i16 @format_long(i16* %res.8.par, i16 %base.9.par, > i32 %x.10.par) #3 { > > which is later changed somewhere in opt to: > > ; Function Attrs: minsize nounwind optsize > define internal fastcc i16 @format_long(i16* %res.8.par, i16 >...

Right now we have a healthy mixture of two ways to respond to -Oz and -Os in LLVM: 1) Pass this info to the PassManagerBuilder and then toggle some flag to the pass to change thresholds. 2) When running over IR, inspect it for the minsize or optsize attribute. Regardless of the particulars of what these mean and/or how they relate to -O2 vs -O3 for example, I'd really like to at least get to *one* way of doing this. The only way that is really compatible with LTO use cases is to use the function attributes, so I'd suggest we activel...

Can you send the IR you are using? Volkan On Thu, Oct 8, 2015 at 6:28 AM Erdem Derebaşoğlu < erdemderebasoglu at hotmail.com> wrote: > Thanks. I enabled my pass. I have one resolved issue though: > MachineMemOperand::getAddrSpace() always returns zero. How can I use it to > distinguish private memory accesses? > > Erdem > > ------------------------------ > From:

...t;https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D67120&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=KfYo542rDdZQGClmgz-RBw&m=tscXcy0bnqeZPQHl9SiPfgvfUizD33tNurQecbRunKg&s=RvBQN7FNwjsvLgJgV9jlOUCrkLubfH6CtcALRdXOYao&e=>. > And yeah using PGSO is selecting optsize while this change is selecting > optnone. > PGSO looks at the block-level profile, too. > > On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" < > llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> > wrote: > >...

FYI David is referring to PGSO (profile-guided size optimization) as it exists directly under that name, see: https://reviews.llvm.org/D67120. And yeah using PGSO is selecting optsize while this change is selecting optnone. On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org> on behalf of llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wro...

...2 10), !dbg !22 >> which will use %_tmp30 to write in the alloca'd buffer. > >> Shoulnd't MemoryDependenceAnalysis::getDependency rather return the call? > > Depends. What is the exact declaration of format_long? In the input .ll file it is: ; Function Attrs: minsize optsize define internal i16 @format_long(i16* %res.8.par, i16 %base.9.par, i32 %x.10.par) #3 { which is later changed somewhere in opt to: ; Function Attrs: minsize nounwind optsize define internal fastcc i16 @format_long(i16* %res.8.par, i16 %base.9.par, i32 %x.10.par) #2 { Thanks, Mikael > >...

...evelopments in LLVM's optimizer... So here goes: 1) The easiest: 'Minimize Size' or '-Oz' - Attribute: minsize (we already have it, nothing to do here) - Goal: minimize the size of the resulting binary, at (nearly) any cost. 2) Optimize for size or '-Os' - Attribute: optsize (we already have it, nothing to do here) - Goal: Optimize the execution of the binary without unreasonably[1] increasing the binary size. This one is a bit fuzzy, but usually people don't have a hard time figuring out where the line is. The primary difference between minsize and optsize is tha...

...es correctly, they would be function-level > attributes applied to IR functions, correct? I'm curious what the > semantics would be for cross-function optimization. For example, consider > a function "foo" defined with maxopt and a function "bar" defined with > optsize. If foo() calls bar() and the inliner wants to inline bar() into > foo(), is that legal? If so, that may cause odd effects as you may perform > expensive optimizations later on the inlined version of bar(), even though > the original function is marked optsize. > > Also, a nit-pic...

...The easiest: 'Minimize Size' or '-Oz' > > - Attribute: minsize (we already have it, nothing to do here) > > - Goal: minimize the size of the resulting binary, at (nearly) any cost. > > > > > > 2) Optimize for size or '-Os' > > - Attribute: optsize (we already have it, nothing to do here) > > - Goal: Optimize the execution of the binary without unreasonably[1] > increasing the binary size. > > This one is a bit fuzzy, but usually people don't have a hard time > figuring out where the line is. The primary difference betw...

...= external constant i8* > @_ZTId = external constant i8* > @.str = private unnamed_addr constant [19 x i8] c"caught integer %d\0A\00", align 1 > @.str1 = private unnamed_addr constant [18 x i8] c"caught double %g\0A\00", align 1 > > define i32 @_Z3foov() uwtable optsize ssp { > entry: > invoke void @_Z3barv() optsize > to label %try.cont unwind label %lpad > > invoke.cont7: > %tmp0 = tail call i8* @__cxa_begin_catch(i8* %exn) nounwind > %tmp1 = bitcast i8* %tmp0 to i32* > %exn.scalar = load i32* %tmp1, align 4 > %call = t...

...ze Size' or '-Oz' >> > - Attribute: minsize (we already have it, nothing to do here) >> > - Goal: minimize the size of the resulting binary, at (nearly) any cost. >> > >> > >> > 2) Optimize for size or '-Os' >> > - Attribute: optsize (we already have it, nothing to do here) >> > - Goal: Optimize the execution of the binary without unreasonably[1] increasing the binary size. >> > This one is a bit fuzzy, but usually people don't have a hard time figuring out where the line is. The primary difference betwee...

...e goes: > > > 1) The easiest: 'Minimize Size' or '-Oz' > - Attribute: minsize (we already have it, nothing to do here) > - Goal: minimize the size of the resulting binary, at (nearly) any cost. > > > 2) Optimize for size or '-Os' > - Attribute: optsize (we already have it, nothing to do here) > - Goal: Optimize the execution of the binary without unreasonably[1] increasing the binary size. > This one is a bit fuzzy, but usually people don't have a hard time figuring out where the line is. The primary difference between minsize and opts...

...ernal constant i8* @_ZTIi = external constant i8* @_ZTId = external constant i8* @.str = private unnamed_addr constant [19 x i8] c"caught integer %d\0A\00", align 1 @.str1 = private unnamed_addr constant [18 x i8] c"caught double %g\0A\00", align 1 define i32 @_Z3foov() uwtable optsize ssp { entry: invoke void @_Z3barv() optsize to label %try.cont unwind label %lpad invoke.cont7: %tmp0 = tail call i8* @__cxa_begin_catch(i8* %exn) nounwind %tmp1 = bitcast i8* %tmp0 to i32* %exn.scalar = load i32* %tmp1, align 4 %call = tail call i32 (i8*, ...)* @printf(i8* ge...

...erenced from > within a function in the same module. > Do you have a testcase? I tried to reproduce this with ----------- a = global i64 42, align 8 ----------- and ---------- @a = external global i32 @b = constant [1 x i32*] [i32* @a], align 8 define i32 @f() nounwind uwtable readonly optsize { entry: %0 = load i32* @a, align 4 ret i32 %0 } ---------- but llvm-link correctly produced @b = constant [1 x i32*] [i32* bitcast (i64* @a to i32*)], align 8 @a = global i64 42, align 8 define i32 @f() nounwind uwtable readonly optsize { entry: %0 = load i32* bitcast (i64* @a to i32*),...

...ecides what the stack frame look like. Here's the -emit-llvm output target datalayout = "e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:32-n32-S64" target triple = "thumbv7em-none--eabi" ; Function Attrs: nounwind optsize define void @out_char(char)(i8 zeroext %ch) #0 { entry: tail call void @llvm.dbg.value(metadata !{i8 %ch}, i64 0, metadata !10), !dbg !11 tail call void @platform_putchar(int, char)(i32 0, i8 zeroext %ch) #3, !dbg !12 ret void, !dbg !13 } ; Function Attrs: optsize declare void @platform_put...

Hi all, I was looking at the ValueMapper code this morning and I notice that it doesn't do type mapping for GlobalValues. Is this correct? I ask because I am seeing a case where I'm failing type assertions from ModuleLinker::linkGlobalInits() when an array initializer references an external global. It looks like the external global is being mapped directly and this causes an element

...re >goes: > > >1) The easiest: 'Minimize Size' or '-Oz' >- Attribute: minsize (we already have it, nothing to do here) >- Goal: minimize the size of the resulting binary, at (nearly) any >cost. > > >2) Optimize for size or '-Os' >- Attribute: optsize (we already have it, nothing to do here) >- Goal: Optimize the execution of the binary without unreasonably[1] >increasing the binary size. >This one is a bit fuzzy, but usually people don't have a hard time >figuring >out where the line is. The primary difference between minsiz...

...mount of cross-module optimizations done by > LTO, but it should not control the codegen optimization level; that > should be based off of the optimization level used during the initial > compilation phase (i.e., bitcode generation). > At least as I recall the discussion around optnone/optsize in the pass was that these were in some way special semantically distinct properties (optnone being "good for debugging" (or good for debugging compilers - what's the baseline behavior before optimizations are applied), optsize being "make this fit into something it wouldn't...