similar to: [RFC][clang/llvm] Allow efficient implementation of libc's memory functions in C/C++

Thx for the feedback David. So we're heading toward a broader > __attribute__((disable_call_synthesis)) David what do you think about the additional version that restrict the effect to a few named functions? > e.g. __attribute__((disable_call_synthesis("memset", "memcpy", "sqrt"))) A warning should be issued if the arguments are not part of

The following IR with the volatile parameter set to true > call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 %0, i8* align 1 %1, i64 7, i1 true) generates the following asm: > movl (%rsi), %eax > movl 3(%rsi), %ecx > movl %ecx, 3(%rdi) > movl %eax, (%rdi) It performs an overlapping read/write which - I believe - is violating the volatile semantic Full example here:

The primary reason I don’t want to provide any guarantees for what instructions are used to implement volatile memcpy is that it would forbid lowering a volatile memcpy to a library call. clang uses a volatile memcpy for struct assignment in C. For example, “void f(volatile struct S*p) { p[0] = p[1]; }”. It’s not really that useful, but it’s been done that way since before clang was written.

Hi Guillaume, Thanks for the RFC. I'm generally +1 on the concept. Making bit field manipulation easier seems like a good overall goal given its prevalence in LLVM. As for the syntax, I tend to prefer that we don't pollute the namespace. Have you considered pushing the methods into the Bitfield class? Maybe something like: ``` uint8_t Storage = 0; using Amount =

Our application is 32-bit big-endian ARM and we use -O3 with LTO. clang optimizes certain initialization of structures to zero with calls to memset, which are not further lowered to move instructions. Investigating perf reports, it looks like it may be beneficial to disable this optimization that introduces a function call to memset in certain hot paths. I tried passing -fno-builtin, but that

[You can find an easier to read and more complete version of this RFC here <https://docs.google.com/document/d/1QidaJMJUyQdRrFKD66vE1_N55whe0coQ3h1GpFzz27M/edit?ts=5aaa84ee#> .] Knowing instruction scheduling properties (latency, uops) is the basis for all scheduling work done by LLVM. Unfortunately, vendors usually release only partial (and sometimes incorrect) information. Updating the

On 27.10.2012, at 18:24, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 27.10.2012, at 18:15, Sean Silva <silvas at purdue.edu> wrote: > >> How does this affect freestanding implementations? > > This transform is disabled with -fno-builtin or -ffreestanding. Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is

On Wed, 5 Jun 2019 at 13:49, Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I don’t see any particular reason to guarantee that a volatile memcpy will access each byte exactly once. How is that useful? I agree it's probably not that useful, but I think the non-duplicating property of volatile is ingrained strongly enough that viewing a memcpy as a single load and

TL;DR: Have support in ADT for typed values packing into opaque scalar types - Code & design choices: https://reviews.llvm.org/D81580 - Usage: https://reviews.llvm.org/differential/changeset/?ref=2005337&whitespace=ignore-most - Example of rewrite: https://reviews.llvm.org/D81662 *CONTEXT* There are places in LLVM where we need to pack typed fields into opaque values. For instance,

On Thu, Mar 15, 2018 at 4:41 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 03/15/2018 10:04 AM, Guillaume Chatelet via llvm-dev wrote: > > [You can find an easier to read and more complete version of this RFC here > <https://docs.google.com/document/d/1QidaJMJUyQdRrFKD66vE1_N55whe0coQ3h1GpFzz27M/edit?ts=5aaa84ee#> > .] > > Knowing

New clang versions need the '-ffreestanding' flag because new changes convert system calls to their unlocked versions, which don't exist in the kernel library. Signed-off-by: Bill Wendling <morbo at google.com> diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc index f500d535..9cf4b2d9 100644 --- a/scripts/Kbuild.klibc +++ b/scripts/Kbuild.klibc @@ -67,7 +67,8 @@ include

On Sat, Jul 25, 2020 at 4:10 PM Ben Hutchings <ben at decadent.org.uk> wrote: > On Sat, 2020-07-25 at 15:16 -0700, Bill Wendling wrote: > > On Sat, Jul 25, 2020 at 2:56 PM Ben Hutchings <ben at decadent.org.uk> wrote: > > > On Sat, 2020-07-25 at 14:36 -0700, Bill Wendling wrote: > > > [...] > > > > I upstreamed a few patches to klibc to fix a few

Even with -ffreestanding LLVM generates memcpy/memset? Does this mean some passes do not honor this flag? If you really wanted to prevent libcalls, you could technically translate those memcpy/memset to loops in lowering. Kevin On Sat, Oct 15, 2016 at 4:10 PM, Wolfgang McSneed via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Mehdi and Joerg, > > Thanks for your fast

On Tue, May 29, 2012 at 11:11 AM, Jeffrey Yasskin <jyasskin at googlers.com>wrote: > On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> > wrote: > >> > >> On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com >

On Sat, 2020-07-25 at 23:13 -0700, Bill Wendling wrote: > On Sat, Jul 25, 2020 at 4:10 PM Ben Hutchings <ben at decadent.org.uk> wrote: > > On Sat, 2020-07-25 at 15:16 -0700, Bill Wendling wrote: > > > On Sat, Jul 25, 2020 at 2:56 PM Ben Hutchings <ben at decadent.org.uk> wrote: > > > > On Sat, 2020-07-25 at 14:36 -0700, Bill Wendling wrote: > > >

Bill Wendling dixit: >New clang versions need the '-ffreestanding' flag because new changes >convert system calls to their unlocked versions, which don't exist in >the kernel library. This is probably wrong, a libc is not, in contrast to a bootloader or kernel, a freestanding environment. For the case of GCC, -ffreestanding is definitely wrong. Please look for another

Wait, you used the same example as I did. I'm confused then; if ScEv is having troubles but it still gets optimized away somewhere, what do you think is doing it? On Mon, Feb 3, 2020 at 2:16 PM Karl Rehm <klrehm123 at gmail.com> wrote: > Ah, I see. I think there's something else going on here too, though. > https://godbolt.org/z/dCqdvv is optimized away but ScEv doesn't

On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> > How do I disable that feature? I've tried -fno-builtin and/or >>>>>> -ffreestanding >>>>>> > with no success. >>>>>> clang (as well as gcc)

On Tue, May 29, 2012 at 9:50 PM, Chandler Carruth <chandlerc at google.com>wrote: > > How do I disable that feature? I've tried -fno-builtin and/or >>>>>>> -ffreestanding >>>>>>> > with no success. >>>>>>> clang (as well as gcc) requires that freestanding environment >>>>>>> provides

On 03/15/2018 10:04 AM, Guillaume Chatelet via llvm-dev wrote: > [You can find an easier to read and more complete version of this RFC > here > <https://docs.google.com/document/d/1QidaJMJUyQdRrFKD66vE1_N55whe0coQ3h1GpFzz27M/edit?ts=5aaa84ee#>.] > > Knowing instruction scheduling properties (latency, uops) is the basis > for all scheduling work done by LLVM. > > >