similar to: llvm-exegesis

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

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

Sounds like a very useful tool.  Thank you for contributing. Taking a step back and looking at the big picture, combining this with the recently contributed llvm-mca dramatically improves our scheduling and performance analysis story.  Being able to take a snippet of code on a particular machine, measure latency/throughput/ports for each instruction (this tool), and then analyze the entire

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

Since the option of running -mode=inverse_throughput was added to llvm-exegesis the names of classes like UopsSnippetGenerator and UopsBenchmarkRunner, that this mode shares with uops, started to be less descriptive. Inverse_throughput doesn't use the uops counters, so for example, the instruction layout shared between these two modes is really connected to parallelism, not uops. It's

Hi all, In a recent IISWC paper <http://groups.csail.mit.edu/commit/papers/19/ithemal-measurement.pdf>, we've proposed BHive - a new methodology for benchmarking arbitrary basic blocks that has several advantages over the one currently used in llvm-exegesis. In particular, the new methodology: - automatically handles memory accesses in the basic block, without the need to manually

I am, of course, a huge fan of this effort. :) > >> >> - >> >> [??] Make the tool work for other CPUs. This mainly depends on the >> presence of performance counters. >> >> Having these requirements documented will be great. In particular, it's important to document what kind of functionality we need out of the PMU rather than any

Hello, I've been testing llvm-exegesis on X86. Latency and inverse_throughput modes work fine but when I run uops I get an error: event not found - cannot create event uops_dispatched_port:port_0 LLVM ERROR: invalid perf event 'uops_dispatched_port:port_0' I'm running this on a i7-4790K. Am I missing something on my computer or is this not yet fully implemented? This also

Hello LLVM-dev, I think I've found an issue with the MachineSink optimization on a program that uses setjmp. It looks like MachineSink will happily move a machine instruction into a following machine basic block (not necessarily a successor), even when that later block can be reached through a setjmp. Here is some example debug output from llc that I'm seeing: Sinking along critical

(on the correct mailing list) Hi all, tl;dr: We'd like to propose moving tools/llvm-mca/lib into lib/MCA and create a new MCA library in LLVM. llvm-mca has recently been split <https://bugs.llvm.org/show_bug.cgi?id=37696> into its core part and the tool part. - The core part simulates the execution of a basic block of machine instructions as modeled by the llvm SchedModel.

On Thu, Jan 10, 2019 at 4:47 PM Clement Courbet <courbet at google.com> wrote: > > > On Wed, Jan 9, 2019 at 6:16 PM James Y Knight <jyknight at google.com> wrote: > >> >> >> On Tue, Jan 8, 2019 at 9:24 AM Clement Courbet <courbet at google.com> >> wrote: >> >>> >>> >>> On Mon, Jan 7, 2019 at 10:26 PM James Y

Thanks for the suggestions Hal, So if I understand correctly, you're recommending we add a module flag <https://llvm.org/docs/LangRef.html#module-flags-metadata> to LLVM, something like: !llvm.module.flags = !{..., !123} !123 = !{i32 1, !"memeq_lib_function", !"user_memeq"} I've given it a try in the following patch: https://reviews.llvm.org/D56311 If this

On Tue, Jan 8, 2019 at 9:24 AM Clement Courbet <courbet at google.com> wrote: > > > On Mon, Jan 7, 2019 at 10:26 PM James Y Knight <jyknight at google.com> > wrote: > I'm afraid about the "almost" and "generally": what about users who don't ? > Even so, it should be fine to enable it for those platforms which do include it. I do note,

On Mon, Jan 7, 2019 at 5:50 AM Clement Courbet <courbet at google.com> wrote: > On Fri, Jan 4, 2019 at 12:34 PM James Y Knight via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> This seems a somewhat odd and overcomplicated way to go about this. >>> >>> Given that bcmp was required in POSIX until relatively recently, I will

If we are considering an optimization to convert calls to memcmp into bcmp, then does it make sense to add an intrinsic for bcmp like there is for memcmp? That way IR writers can express their requirements precisely: memcmp if you care about the direction of inequality, and bcmp if you do not. On Fri, Jan 4, 2019 at 12:34 PM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote:

Please can we add a code owner entry for llvm-mca, which should probably be Andrea. I wasn't sure if we need to go through a full nomination process for new tools like this (and llvm-exegesis?) or we can just add the primary contributor to the CODE_OWNERS.TXT list immediately. Thanks, Simon.

Hi all, We'd like to suggest *adding a -memeq-lib-function* flag to allow the user to specify a `*memeq()*` function to improve string equality check performance. Right now, when llvm encounters a *string equality check*, e.g. `if (memcmp(a, b, s) == 0)`, it tries to expand to an equality comparison if `s` is a small compile-time constant, and falls back on calling `memcmp()` else. This is

I am pleased to announce that LLVM 7 is now available. Get it here: https://llvm.org/releases/download.html#7.0.0 The release contains the work on trunk up to SVN revision 338536 plus work on the release branch. It is the result of the community's work over the past six months, including: function multiversioning in Clang with the 'target' attribute for ELF-based x86/x86_64 targets,

I am pleased to announce that LLVM 7 is now available. Get it here: https://llvm.org/releases/download.html#7.0.0 The release contains the work on trunk up to SVN revision 338536 plus work on the release branch. It is the result of the community's work over the past six months, including: function multiversioning in Clang with the 'target' attribute for ELF-based x86/x86_64 targets,