search for: uninline

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.

...timization, 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 or gcc -Os. Ian, Keir, which of these approaches do you prefer? Currently the top stack users are: $ objdump -dS xen-syms | ./checkstack.pl x86_64 0xffff8300001c7c47 find_unisys_acpi_oem_table: 1296 0xffff83000011182e do_xen_version:...

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

...at 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 inlined. > > I'm not following. Why do you want to uninline stuff? If we had a > 'never inline these functions' list, We don't have 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...

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

...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 inlined. >> >> >> I'm not following. Why do you want to uninline stuff? If we had a >> 'never inline these functions' list, > > > We don't have 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 i...

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

...e SWIOTLB implementation, > which does not support allocations larger than 256kb. When the > virtio-blk driver tries to read/write a block larger than that, the > allocation of the dma-handle fails and an IO error is reported. > > Changes to v5 are: > > - Changed patch 3 to uninline dma_max_mapping_size() And this lead to problems reported by kbuild :( BTW when you repost, can I ask you to pls include the version in all patches? Both --subject-prefix and -v flags to git format-patch will do this for you. > Please review. > > Thanks, > > Joerg > > J...

...e SWIOTLB implementation, > which does not support allocations larger than 256kb. When the > virtio-blk driver tries to read/write a block larger than that, the > allocation of the dma-handle fails and an IO error is reported. > > Changes to v5 are: > > - Changed patch 3 to uninline dma_max_mapping_size() And this lead to problems reported by kbuild :( BTW when you repost, can I ask you to pls include the version in all patches? Both --subject-prefix and -v flags to git format-patch will do this for you. > Please review. > > Thanks, > > Joerg > > J...

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

.... it uses varargs). >>> >>> >>>> In some cases, that would be fine. But in other cases: >>>> (1) It cannot "un-inline" any function that was previously inlined. >>> >>> >>> I'm not following. Why do you want to uninline stuff? If we had a >>> 'never inline these functions' list, >> >> >> We don't have such a list, at least not so far. We do have a "used" list >> but that's presumably used for other things. >> >> >>> a transfor...

...(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 inlined. >>> >>> >>> I'm not following. Why do you want to uninline stuff? If we had >>> a 'never inline these functions' list, >> We don't have 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 want...

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

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