search for: uninlining

A simple reproducer is: ---------------------------------------------------------------------- #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <string.h> const char * copyn (const char *str, size_t n) { return strndup (str, n); } const char * copy (const char *str) { return copyn (str, SIZE_MAX); }

Previously with GCC 10.2 this code produced: In function ‘nbdkit_strndup_intern’, inlined from ‘nbdkit_strdup_intern’ at public.c:839:10: public.c:827:10: error: ‘strndup’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] 827 | copy = strndup (str, n); | ^~~~~~~~~~~~~~~~ --- server/public.c | 16

On 9/3/20 4:41 AM, Richard W.M. Jones wrote: > Previously with GCC 10.2 this code produced: > > In function ‘nbdkit_strndup_intern’, > inlined from ‘nbdkit_strdup_intern’ at public.c:839:10: > public.c:827:10: error: ‘strndup’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] > 827 | copy = strndup (str,

Filed upstream as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96916 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

On Thu, Sep 03, 2020 at 10:47:13AM +0100, Richard W.M. Jones wrote: > > A simple reproducer is: > > ---------------------------------------------------------------------- > #include <stdio.h> > #include <stdlib.h> > #include <stdint.h> > #include <string.h> > > const char * > copyn (const char *str, size_t n) > { > return strndup

I'm not sure if this is a GCC bug or a bug in our code, but the attached workaround fixes it for me. Rich.

Xen is compiled with no -O gcc option, meaning no optimization, and the compiler does the safest thing imaginable. This means that if a function, say vmx_world_save(), calls the same inline a bazillion times, the stack will have one block of local variables for each invocation of that function! Xen really should not be doing this. We could either uninline some of these functions, or try gcc -O2

...was previously inlined. I'm not following. Why do you want to uninline stuff? If we had a 'never inline these functions' list, 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? > (2) It requires writing a driver loop nest to go over all call sites and > decide what to do. If all you want is to influence the existing heuristics, > that seems like too much work. You're talking about something...

...such a list, at least not so far. We do have 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 require...

On Mar 15, 2006, at 10:04 AM, Chris Lattner wrote: > On Wed, 15 Mar 2006, Vikram S. Adve wrote: >> [I've changed the subject to make this a new thread.] >> >> While all of this makes sense to me, note that Markus and John >> were asking about different situations. Markus was asking about >> user-written source code. John was asking about a compiler pass

...r. We do have 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 inl...

Here I will introduce my idea of a inliner that can handle splitting cold edge as well: My idea is to use the inlined function, but inline from the uninlined function. 1. Do normal optimizations without inlining 2. Split the cold edges into other functions 3. Copy each function @xyz to @xyz.i (or other name that does not clash) and mark @xyz with 'inlines @xyz.i' ==> this needs an

On Thu, Jan 31, 2019 at 05:33:58PM +0100, Joerg Roedel wrote: > Hi, > > here is the next version of this patch-set. Previous > versions can be found here: > > V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ > > V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ > > V3:

On Thu, Jan 31, 2019 at 05:33:58PM +0100, Joerg Roedel wrote: > Hi, > > here is the next version of this patch-set. Previous > versions can be found here: > > V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ > > V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ > > V3:

And how about this one so as not to include a C specific header in llvm-backend (!!!) and not to have llvm-backend use a C specific flag (flag_no_builtin)? Index: gcc-4.2.llvm/gcc/c-opts.c =================================================================== --- gcc-4.2.llvm.orig/gcc/c-opts.c 2008-07-30 21:25:28.000000000 +0200 +++ gcc-4.2.llvm/gcc/c-opts.c 2008-07-30 21:26:17.000000000 +0200 @@

...uot; 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 >> influencin...

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

> On Nov 17, 2014, at 5:50 PM, Reid Kleckner <rnk at google.com> wrote: > > On Mon, Nov 17, 2014 at 5:22 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: > I don’t know much about SEH and haven’t had time to really dig into this, but the idea of outlining functions that need to know about the frame layout sounds a bit scary. Is it

TLDR - The proposal below is intended to allow inlining of larger callees when such inlining is expected to reduce the dynamic instructions count. Proposal ------------- LLVM inlines a function if the size growth (in the given context) is less than a threshold. The threshold is increased based on certain characteristics of the called function (inline keyword and the fraction of vector

On Jul 30, 2008, at 11:39 AM, Duncan Sands wrote: > On Wednesday 30 July 2008 18:13:27 Duncan Sands wrote: >> On x86-64 linux, in stage 2, I get: >> >> c++ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict- >> prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno- >> variadic-macros -Wno-overlength-strings -Wold-style-definition - >>