similar to: [LLVMdev] Optimization for size

Hi, Looking at bugzilla PR11087, I'd like to conditionalise a transformation in ARMIselLowering.cpp based on whether we're compiling for codesize or performance. -Os doesn't actually exist for llc, and I can't see an obvious place where that condition would be set. Where do we specify if we're optimizing for codesize or performance? Cheers, James --------------

Hi all, It’s been two weeks since I sent the last merge progress email, so here is an update. TL;DR: Almost done! Tim is considering suggesting making the final switchover sometime next week. This would be the final push, where AArch64 gets deleted and ARM64 gets renamed to AArch64, and would signal the end of the merge process. If any of you know of any reason why these two loving

If I understand 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

Since we are only a week away from branching for 3.7.0, this new breakage in the stage2 bootstrap of llvm/clang/compiler-rt/clang-tools-extra should get triaged. At r241513, a three stage bootstrap with comparision of stage2/stage3 files completed fine. However at r241594 we now have the new regression reported in https://llvm.org/bugs/show_bug.cgi?id=24054... Assertion failed: (Val &&

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

I'm getting this build error with -Werror: [off-opt] : [llvm] cc1plus: warnings being treated as errors [off-opt] : [llvm] /ptmp/dag/llvm/official/llvm/lib/Target/ARM/ARMISelLowering.cpp: In member function 'llvm::MachineBasicBlock* llvm::ARMTargetLowering::EmitAtomicBinary64(llvm::MachineInstr*, llvm::MachineBasicBlock*, unsigned int, unsigned int, bool, bool) const': [off-opt]

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

On Wed, Sep 9, 2020 at 9:23 PM Wenlei He via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think calling PGSO size opt is probably a bit misleading though. It’s > more of an adaptive opt strategy, and it can improve performance too due to > better locality. We have something similar internally for selecting opt > level based on profile hotness too under AutoFDO. > >

On 12 November 2010 17:52, Bob Wilson <bob.wilson at apple.com> wrote: > I recommend implementing this as a target-specific DAG combine optimization.  We already have target-specific DAG nodes for the relevant NEON comparison operations (ARMISD::VCEQ, etc. -- see ARMISelLowering.h) as well as the vmov (ARMISD::VMOVIMM).  You just need to teach the DAG combiner how to fold them together.

On Wed, 9 Sep 2020 at 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

Hello A 4.4% geomean codesize improvement is really impressive. That stuff is hard to come by, you usually have to nibble away at it bit at a time. I ran some codesize benchmarks we have and they were in the same ballpark. Some of these are quite small so had less opportunity for outlining, but the average was still over 3% with some as high as 9-10%. All the tests I ran were fine, although we

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

On 08/07/2015 01:53 PM, Caldarale, Charles R wrote: >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] >> On Behalf Of Mikael Holmén via llvm-dev >> Subject: [llvm-dev] load instruction erroneously removed by GVN > >> But between the load and the alloca there is also >> call fastcc void @format_long(i16* %_tmp30, i16 10, i32 10), !dbg !22 >>

Hi, On 25 April 2018 at 14:02, David Green via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello > > A 4.4% geomean codesize improvement is really impressive. That stuff is hard to come by, you usually have to nibble away at it bit at a time. I ran some codesize benchmarks we have and they were in the same ballpark. Some of these are quite small so had less opportunity for

Hello, I was wondering if there is a way to add more, maybe target dependant, function attributes? I think in certain circumstances they are a good way to give the compiler more information about a function. For example GCC supports attributes to mark an interrupt function witch is very useful for some low level targets. As far as I know function attributes are GCC specific or am I wrong? Is

Is this related to Owen's patch r118453? Evan On Nov 12, 2010, at 10:42 AM, Renato Golin wrote: > On 12 November 2010 17:52, Bob Wilson <bob.wilson at apple.com> wrote: >> I recommend implementing this as a target-specific DAG combine optimization. We already have target-specific DAG nodes for the relevant NEON comparison operations (ARMISD::VCEQ, etc. -- see

Most LLVM IR instructions have a result field, according to the Language Reference. I want to know, for all LLVM Instructions, is there an easy and consistent way to know if the current Inst has a result field? And if yes, what is the best way to obtain it? E.g.: <result> = add<ty> <op1>,<op2> /; yields {ty}:result / All ADD instruction will have a

Sent from my iPad On Jan 14, 2013, at 11:07 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > On Mon, Jan 14, 2013 at 10:48 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> >> >> Sent from my iPad >> >> On Jan 14, 2013, at 1:09 AM, Chandler Carruth <chandlerc at gmail.com> wrote: >> >> > This has been an idea floating

On Fri, Nov 20, 2015 at 5:06 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > We'd need to look precisely at what's causing the code size bloat. The > midend commit pointed out by Steve shouldn't cause bloat in and of itself - > it should reduce code size. It removes a load of stores and branches. > Hi James, Sounds like your patch should have

On Nov 12, 2010, at 7:23 AM, Renato Golin wrote: > Hi folks, me again, > > So, I want to implement a simple optimization in a NEON case I've seen > these days, most as a matter of exercise, but it also simplifies (just > a bit) the code generated. > > The case is simple: > > uint32x2_t x, res; > res = vceq_u32(x, vcreate_u32(0)); > > This