search for: gchatelet

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

...rator, > lifetime considerations) but feel more natural. > > I would really appreciate guidance from the community on which syntax is > preferred, or any other suggestions (`isSet` is not a great name) > > Thank you! > > On Thu, Jun 11, 2020 at 6:04 PM Guillaume Chatelet <gchatelet at google.com> > wrote: > >> 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&white...

...e depend on libpfm <http://perfmon2.sourceforge.net/docs_v4.html>. > How do we handle the dependency ? Are there options that you have in mind? It's an external MIT-licensed dependency. Wouldn't CMake just detect it when it's available?  -Hal > -- > Guillaume Chatelet (gchatelet at google.com > <mailto:gchatelet at google.com>), Clement Courbet (courbet at google.com > <mailto:courbet at google.com>) for the Google Compiler Research Team > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at...

...d 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 explanation Eli an...

...[??] Make the tool work for other CPUs. This mainly depends on the > presence of performance counters. > > > Open Questions > > We depend on libpfm <http://perfmon2.sourceforge.net/docs_v4.html>. > How do we handle the dependency ? > -- > Guillaume Chatelet (gchatelet at google.com > <mailto:gchatelet at google.com>), Clement Courbet (courbet at google.com > <mailto:courbet at google.com>) for the Google Compiler Research Team > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev a...

...ure what the policy is wrt external deps. Right now if the tool is enabled and libpfm is not on the system, we die with an error message. The other options would be to disable the tool in that case (I'm not sure how to do that). Opinions ? > > -Hal > > -- > Guillaume Chatelet (gchatelet at google.com), Clement Courbet ( > courbet at google.com) for the Google Compiler Research Team > > > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -...

...or > message. The other options would be to disable the tool in that case > (I'm not sure how to do that). Opinions ? Sounds good (we can discuss this further, if necessary, in the code review).  -Hal >   > > >  -Hal > >> -- >> Guillaume Chatelet (gchatelet at google.com >> <mailto:gchatelet at google.com>), Clement Courbet >> (courbet at google.com <mailto:courbet at google.com>) for the Google >> Compiler Research Team >> >> >> >> _______________________________________________ &g...

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 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, modifying an obj...

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

Woah this is a good idea. I'd ask that alignment come in different bit sizes and endienesses so that we can add an alignment type to ELF types. I would love to review this and add it to llvm-objcopy. We have special functions to handle all of these 'zero' cases. Several other bits of code I've seen/written have to find maximum alignment and I'd imagine the mistake of not