similar to: RFC: Need One True Way to check for -Oz/-Os (minsize, optsize) in passes...

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 around in my head for a while and after > several discussions with others it continues to hold up so I thought I > would mail it out.

This has been an idea floating around in my head for a while and after several discussions with others it continues to hold up so I thought I would mail it out. Sorry for cross posting to both lists, but this is an issue that would significantly impact both LLVM and Clang. Essentially, LLVM provides canned optimization "levels" for frontends to re-use. This is nothing new. However, we

> On Aug 20, 2015, at 9:46 AM, Steve King <steve at metrokings.com> wrote: > > On Wed, Aug 19, 2015 at 10:58 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> Isn’t the problem the fact that the patch makes it harder for a target to >> get the generic code to reach its custom hook? >> Now the "cheap pow2 sdiv” is merged with the generic

I don't know of a way to do it from the command-line, but if you're willing to change the IR, you can add the optsize (for -Os) or minsize (for -Oz) IR attribute to the function you're compiling. On Fri, Sep 2, 2016 at 5:59 AM, Bruce Hoult via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Idle question, if anyone is reading still ... how do you get llc to do -Os > or

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

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

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 around in my head for a while and after several discussions with others it continues to hold up so I thought I would mail it out. Sorry for cross posting to both lists, but this is an issue that would significantly impact both LLVM and Clang. > >

On 4/20/2018 7:06 PM, Jessica Paquette via llvm-dev wrote: > We perform regular testing to ensure the outliner produces correct > AArch64 code at -Oz. Tests include the LLVM test suite and standard > external test suites such as SPEC. All tests compile and > execute. We've also been making sure that the outliner produces > debuggable code. Users are still guaranteed to have

Hi Eli, > I just tried some tests, and I'm seeing a bunch of failures on SPEC at -O3; looks like mostly crashes at runtime. I can try to reduce a testcase if you need it. If you could do that, that would be great. Our testing has been primarily for -Oz and -O2, so I haven’t looked at -O3 at all. > I don't think this is really the right approach. With LTO, you can have a mix of

Hi all, The MachineOutliner has come a long way since the original incarnation presented at the 2016 LLVM Developer's Meeting [1]. In particular, we've been pushing a lot on the AArch64 target for the MachineOutliner. It's mature enough at this point that we'd like to take things a step further and turn it on by default in AArch64 under -Oz. Since the primary goal of -Oz is

I just ran SPEC at -O3 with the outliner enabled for AArch64 and didn’t get any failures on my end. Which flags did you use? I’m curious about what’s going on here... I used -O3 -mllvm -enable-machine-outliner -arch arm64. - Jessica > On Apr 23, 2018, at 1:41 PM, Jessica Paquette <jpaquette at apple.com> wrote: > > Hi Eli, > >> I just tried some tests, and I'm

Sorry, I was using a modified compiler, which by coincidence made the bug much easier to reproduce. In some rare cases, the compiler will use x30 as a general-purpose register; in that case, outlining breaks because the "ret" branches to the wrong address.  Testcase (reproduce with "clang -O3 --target=aarch64-pc-linux-gnu -mllvm -enable-machine-outliner"): extern long g1;

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

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

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

What is the value of undef * 0 in LLVM? According to its definition in the LLVM IR reference; "The string ‘undef‘ can be used anywhere a constant is expected..." Am I correct to say that undef * 0 = 0 following this definition? Best Regards, soham

Hi Joan, On Mon, 13 May 2019 at 18:01, Joan Lluch <joan.lluch at icloud.com> wrote: > After looking at it a bit further, I think this is a Clang thing. Clang issues “align 2” if the struct has at least one int (2 bytes), but also if the entire struct size is multiple of 2. For example a struct with 4 char members. In these cases the LLVM backend correctly creates word sized load/stores

Changing the order of the checks in CodeGenPrepare::optimizeSelectInst() sounds good to me. But you may need to go further for optimum performance. For example, we may be canonicalizing math/logic IR patterns into 'select' such as in the recent: https://reviews.llvm.org/D67799 So if you want those to become ALU ops again rather than branches, then you need to do the transform later in

> On Aug 20, 2015, at 10:22 AM, escha <escha at apple.com> wrote: > >> >> On Aug 20, 2015, at 9:59 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >> >>> >>> On Aug 20, 2015, at 9:46 AM, Steve King <steve at metrokings.com <mailto:steve at metrokings.com>> 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