search for: uninlined

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

On Wed, 15 Mar 2006, Vikram S. Adve wrote: >> Why can't the compiler pass just call InlineFunction(CallSite) on the >> callsite it wants inlined? The only way that can fail is if LLVM cannot >> ever inline the call (e.g. it uses varargs). > In some cases, that would be fine. But in other cases: > (1) It cannot "un-inline" any function that was previously

On Mar 15, 2006, at 11:15 AM, Chris Lattner wrote: > On Wed, 15 Mar 2006, Vikram S. Adve wrote: >>> Why can't the compiler pass just call InlineFunction(CallSite) on >>> the callsite it wants inlined? The only way that can fail is if >>> LLVM cannot ever inline the call (e.g. it uses varargs). > >> In some cases, that would be fine. But in other

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

Vikram S. Adve wrote: Hmmm. It seems the discussion has grown a little bit larger than I had intended. :) Basically what I think would be useful is an option to the inliner that gives it a list of functions to skip when inlining. My argument for this is that we have several transformations now that search for calls to specific functions; if those functions are inlined, the transform pass

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 identifier to mark the shadow function for each function...

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:

...plify_libcalls; + // Global state for the LLVM backend. Module *TheModule = 0; DebugInfo *TheDebugInfo = 0; @@ -381,7 +383,7 @@ PM->add(createFunctionInliningPass()); // Inline small functions if (optimize > 2) PM->add(createArgumentPromotionPass()); // Scalarize uninlined fn args - if (!flag_no_builtin) + if (!flag_no_simplify_libcalls) PM->add(createSimplifyLibCallsPass()); // Library Call Optimizations PM->add(createInstructionCombiningPass()); // Cleanup for scalarrepl. PM->add(createJumpThreadingPass()); // Thread jump...

On Wed, 15 Mar 2006, John Criswell wrote: > Vikram S. Adve wrote: > Basically what I think would be useful is an option to the inliner that gives > it a list of functions to skip when inlining. My argument for this is that > we have several transformations now that search for calls to specific > functions; if those functions are inlined, the transform pass can no longer >

On Mar 15, 2006, at 3:27 PM, John Criswell wrote: > Vikram S. Adve wrote: > > Hmmm. It seems the discussion has grown a little bit larger than I > had intended. > :) > > Basically what I think would be useful is an option to the inliner > that gives it a list of functions to skip when inlining. My > argument for this is that we have several transformations now

> 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

...for example). I propose the use of estimated speedup (estimated reduction in dynamic instruction count to be precise) as another factor that controls threshold. This would allow larger functions whose inlining potentially reduces execution time to be inlined. The dynamic instruction count of (an uninlined) function F is DI(F) = Sum_BB(Freq(BB) * InstructionCount(BB)) * The above summation is over all basic blocks in F. * Freq(BB) = BlockFrequency(BB)/BlockFrequency(Entry(F)) This dynamic instruction count measurement doesn't distinguish between a single-cycle instruction and a long latency ins...

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