search for: chatelet

...def. Also I'd like to get your take on whether it makes sense to have this attribute apply to functions only or at module level as well. Thx, Guillaume On Mon, Apr 29, 2019 at 10:48 AM David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 26/04/2019 12:47, Guillaume Chatelet via llvm-dev wrote: > > 1.2 A specific attribute to disable synthesis of all libc calls > > __attribute__((disable_libc_call_synthesis)) > > With this one we are losing precision and we may inline too much. There > > is also the question of what is considered a libc fun...

...>(Storage, true); unsigned Value = Bitfield::get<Amount>(Storage); bool Cond = Bitfield::test<Amount>(Storage); ``` ^ Seems good to me because it's clear what the API is doing, even without knowing what `Amount` is. WDYT? -- River On Tue, Jun 23, 2020 at 9:40 AM Guillaume Chatelet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The code is now fairly stable and well tested but the syntax is not yet > final. > I would like to get some feedback from the community on alternative > syntaxes that have been suggested to me. > > First, the designed API...

...to setup measurements for specific instructions. - [??] Make the tool work for other CPUs. This mainly depends on the presence of performance counters. Open QuestionsWe depend on libpfm <http://perfmon2.sourceforge.net/docs_v4.html>. How do we handle the dependency ? -- Guillaume Chatelet (gchatelet at google.com), Clement Courbet ( courbet at google.com) for the Google Compiler Research Team -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180315/cdc319d2/attachment.html>

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

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 instruction scheduling properties (latency, uops) is the...

...code on a particular machine, measure latency/throughput/ports for each instruction (this tool), and then analyze the entire code sequence in an actionable way using the measured information (llvm-mca), leads to a very powerful performance analysis workflow. On 03/15/2018 08: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 basi...

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,

...ix this incrementally? i.e. add an alignment class which has > implicit conversions to the current unsigned convention, and incrementally > replace it throughout the codebase. Once everything is fixed, remove the > implicit conversions. > > > On Jul 12, 2019, at 2:20 AM, Guillaume Chatelet via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Alignment in LLVM is currently represented with an `unsigned`, sometimes > an `uint32_t`, `uint64_t` or `uint16_t`. > FWIU the value has the following possible semantics: > - 0 means alignment is unknown, > - 1 mea...

...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. -Eli From: Guillaume Chatelet <gchatelet at google.com> Sent: Thursday, June 6, 2019 2:40 AM To: Tim Northover <t.p.northover at gmail.com> Cc: Eli Friedman <efriedma at quicinc.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] @llvm.memcpy not honoring volatile? Thx for the expl...

*TL;DR:* Defining memory functions in C / C++ results in a chicken and egg problem. Clang can mutate the code into semantically equivalent calls to libc. None of `-fno-builtin-memcpy`, `-ffreestanding` nor `-nostdlib` provide a satisfactory answer to the problem. *Goal* Create libc's memory functions (aka `memcpy`, `memset`, `memcmp`, ...) in C++ to benefit from compiler's knowledge and

On 03/15/2018 10:49 AM, Clement Courbet wrote: > > > On Thu, Mar 15, 2018 at 4:41 PM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto: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 instruction scheduling prop...

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:

Alignment in LLVM is currently represented with an `unsigned`, sometimes an `uint32_t`, `uint64_t` or `uint16_t`. FWIU the value has the following possible semantics: - 0 means alignment is unknown, - 1 means no alignment requirement, - a power of two means a required alignment in bytes. Using `unsigned` throughout the codebase has several disadvantages: - comparing alignments may compare

> On Jun 11, 2019, at 6:27 AM, Guillaume Chatelet <gchatelet at google.com> wrote: > > I spent some time reading the C standard <https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf>: > > 5.1.2.3 Program execution > 2. Accessing a volatile object, mo...

...mailing lists * Dimitry Andric has [collected data](http://lists.llvm.org/pipermail/llvm-dev/2018-March/121871.html) on the size of Clang executables and the time taken to compile Clang since October 2015. Since then, total executable size grew by 43% and build time increased by 60%. * Guillaume Chatelet and Clement Courbet have posted an [RFC on llvm-exegesis](http://lists.llvm.org/pipermail/llvm-dev/2018-March/121814.html), a tool to automatically determine instruction scheduling properties (such as latency and the number of micro-ops). Feedback has been very positive so far, and Clement [explain...

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

I agree, this is a bug. John On 6/7/19 11:48 AM, JF Bastien via llvm-dev wrote: > > >> On Jun 5, 2019, at 2:28 PM, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 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

...to how those blocks are formed. For example the > current implementation forces regions to be isolated to a single basic > block. However, we anticipate lifting this restriction once branching > is handled. > > -Matt > > > On Mon, Dec 10, 2018 at 04:15:46PM +0100, Guillaume Chatelet wrote: >> +1 to what Clement said. >> I believe the intrinsics are a better design to support many architectures. >> >> IACA users are probably decorating their code with IACA_START / IACA_END >> macros. One possibility is to provide a header that define these macros i...

+1 to what Clement said. I believe the intrinsics are a better design to support many architectures. IACA users are probably decorating their code with IACA_START / IACA_END macros. One possibility is to provide a header that define these macros in terms of the new intrinsics. On Mon, Dec 10, 2018 at 3:59 PM Clement Courbet <courbet at google.com> wrote: > Hi Matt/Andrea, > > I