similar to: [RFC] Adding a -memeq-lib-function flag to allow the user to specify a memeq function.

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

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:

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

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

Hi all, I'm working on a new pass to optimize comparison chains. Motivation Clang currently generates inefficient code when dealing with contiguous member-by-member structural equality. Consider: struct A { bool operator==(const A& o) const { return i == o.i && j == o.j; } uint32 i; uint32 j; }; This generates: mov eax, dword ptr [rdi] cmp eax,

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

Hi everyone, Can someone help me with running llvm-exegesis tool on x86_64? I saw that I need libpfm library, but I'm still getting segmentation fault when I try to run the tool. Is there anything else I need to do (build llvm on some specific way) ? This is how I tried to run this tool: llvm-exegesis -mode=latency -opcode-name=ADD64rr Thanks, Luka -------------- next part -------------- An

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

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

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

I propose a new intrinsic "llvm.memcmp" that compares a block of memory for equality (a subset of the libc behavior). Backends are free to use the alignment to optimize using wider than byte operations. Since the result is only equal/not-equal, byte order is not important. For languages that support array compares, this would be very useful. Syntax: declare i1 @llvm.memcmp(i8*

+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

On Fri, Aug 20, 2010 at 1:03 PM, Bagel <bagel99 at gmail.com> wrote: > I propose a new intrinsic "llvm.memcmp" that compares a block of memory > for equality (a subset of the libc behavior).  Backends are free to use the > alignment to optimize using wider than byte operations.  Since the result is > only equal/not-equal, byte order is not important. > > For

Can I make another suggestion: create an intrinsic for memory equality, e.g. llvm.memcmp_eq.p0i8.p0i8.i64(i8*a, i8*b, i64 len). This intrinsic would return zero if the memory regions are equal, and nonzero otherwise. However, it does NOT return any notion of "greater" or "less". Many applications require only determining equality, rather than a total ordering. Given that

With the intrinsic support for ‘memcpy’ and ‘memset’ the operands also have associated alignment operands. I think that ‘memcmp’ should also provide the alignment information for each of the source operands (when statically known). In some cases this will lead to more optimal alignment aware lowering, and for targets for which unaligned access is costly or fatal, it can be lowered safely.

Improving lowering for memcmp is definitely something we should do for all targets. Doing it in a target specific way is decidedly non-ideal. It looks like we already have some code in SelectionDAGBuilder which tries to optimize the lowering for the memcpy library call. I am a bit confused by the problem you are trying to solve. Are you specifically interested in lowering for constant