search for: coremark

...[llvm-dev] Improved jump-threading in LLVM for finite state automata It is my understanding that the implementation for jump-threading in LLVM is not presently able to effectively optimize code containing a state-machine implemented using a loop + switch. This is the case, for example, with the Coremark benchmark function core_state_transition(). Bug 42313 was filed to address this in 2019: https://bugs.llvm.org/show_bug.cgi?id=42313 It appears that GCC improved support for jump threading in 2015 along the same lines: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 Is anyone aware...

On Mon, Aug 31, 2015 at 5:52 PM, Jake VanAdrighem <jvanadrighem at gmail.com> wrote: > Do you have some specific performance measurements? Averaging 4 runs of 10000 iterations each of Coremark on my X86_64 desktop showed: -O2 performance: +2.9% faster with the L.E.V. pass -Os size: 1.5% smaller with the L.E.V. pass In the case of Coremark, the benefit comes mainly from the matrix portion benchmark, which uses nested loops. Similarly, I used a matrix multiplication for the regression t...

It is my understanding that the implementation for jump-threading in LLVM is not presently able to effectively optimize code containing a state-machine implemented using a loop + switch. This is the case, for example, with the Coremark benchmark function core_state_transition(). Bug 42313 was filed to address this in 2019: https://bugs.llvm.org/show_bug.cgi?id=42313 It appears that GCC improved support for jump threading in 2015 along the same lines: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 Is anyone aware of any p...

...e can discuss our approaches, and see if there is a preference in the community for one approach over the other ? What do you think? Thanks Ehsan On Wed, Sep 23, 2020 at 3:14 PM Sjoerd Meijer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > And related while we are at it, i.e. the coremark specials, we have this > sitting in upstream review: https://reviews.llvm.org/D42365 > That should help a bit too. It needs a little bit of work, but I thought > Dave didn't mind if someone commandeers and finishes it. > > > ------------------------------ > *From:* llvm-dev...

Hello LLVM, This is a proposal for a new pass that improves performance and code size in some nested loop situations. The pass is target independent. >From the description in the file header: This optimization finds loop exit values reevaluated after the loop execution and replaces them by the corresponding exit values if they are available. Such sequences can arise after the

...e that big of a deal on SPEC, as it is on other types of code. So far, I haven't found SPEC being too good to judge overall compilers' performance, but specific micro-optimized features. Besides, hardware and software are designed nowadays based on some version of Dhrystone, EEMBC, SPEC or CoreMark, so it's not impossible to see 50% increase in performance with little changes in either. 4. The ILP scheduler has the worst execution times on FP2006 and the second > worst spill counts, although it is the default on x86-64. Is this > surprising? BTW, Dragon Egg sets the scheduler to s...

On Wed, Sep 2, 2015 at 5:36 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > Coremark really isn't a good enough test - have you run the LLVM test suite > with this patch, and what were the performance differences? For the test suite single source benches, the 235 tests improved performance, 2 regressed and 705 were unchanged. That seems very optimistic. Comparing consecuti...

...e after this canonicalisation: foo: .fnstart @ BB#0: @ %entry movs r1, #12 ands r1, r0 ldr r0, .LCPI0_0 ldr r0, [r0, r1] bx lr .p2align 2 This canonicalisation makes shift folding possible. But I wonder if only shift context could benifit from this.When I worked on CoreMark optimization recently, I found a case similar to below: define i32 @test(i32 %v) { entry: %a = and i32 %v, 65534 %b = lshr i32 %a, 1 %c = and i32 %v, 65535 %d = lshr i32 %c, 1 %e = add i32 %b, %d ret i32 %e } It would be profitable as well if we could enable the canonicalisation on it...

Hello! I linked two bitcode files like described below using LTO and find they are linked fine instead of making an error. ---------- 1.bc ---------- ... define i32 @main(i32 %argc, i8** %argv) #0 { entry: ... %call = call i32 @_Z1aj(i64 2) ... } declare i32 @_Z1aj(i64) #1 ... ---------- 2.bc ---------- ... define i32 @_Z1aj(i32 %b) #0 { entry: ... } ... ---------- In the first file function

In ARM.td, I see that the ProcessorModel for cortex-r4, cortex-r4f, and cortex-r5 (as well as r7 and r8) is based on "CortexA8Model", which seems incorrect. When this was added in 2015, there were also comments associated with this configuration, such as "// FIXME: R5 has currently the same ProcessorModel as A8" (later removed). The processor model for Cortex-r52 appears to

Hi all, A bunch of us met at EuroLLVM to discuss the planned merge of the two current AArch64 backends in the tree. The primary question was which backend should form the basis of the merge (since the core .td files aren't directly mergeable), with code being cherry-picked from the other on a case-by-case basis. There were factors to consider both ways, but I think the key points of interest

...ke the new pass for a test drive? > Regards, > -steve > > On Wed, Sep 2, 2015 at 8:27 PM, Steve King <steve at metrokings.com> wrote: > > On Wed, Sep 2, 2015 at 5:36 AM, James Molloy <james at jamesmolloy.co.uk> > wrote: > >> Hi, > >> > >> Coremark really isn't a good enough test - have you run the LLVM test > suite > >> with this patch, and what were the performance differences? > > > > For the test suite single source benches, the 235 tests improved > > performance, 2 regressed and 705 were unchanged. That...

...ificant regressions. It should be > recognized that this is a special situation as there are commercial > releases being made on the two backends, and for adoption of the merge > it is critical that there are no regressions. Examples of tests are: > SPEC2000, SPEC2006, EEMBC, Geekbench, Coremark, MCHammer, Emperor > (NEON) > > - Performance - Difficult to have precise and fixed baseline for > measuring performance regressions on the merged backends because of > variability in hardware, but all significant performance regressions > must be investigated and justified as fi...

On Fri, May 19, 2017 at 4:01 PM Adam Nemet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I will run it on Cyclone/AArch64 next week. > FYI, we're still waiting on these Adam... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/7cb390ca/attachment.html>

...e that big of a deal on SPEC, as it is on other types of code. So far, I haven't found SPEC being too good to judge overall compilers' performance, but specific micro-optimized features. Besides, hardware and software are designed nowadays based on some version of Dhrystone, EEMBC, SPEC or CoreMark, so it's not impossible to see 50% increase in performance with little changes in either. Ghassan: You have made me so curious to try other benchmarks in our future work. Most academic publications on CPU performance though use SPEC. You can even find some recent publications that are still us...

Hello, I'm working on an LLVM backend for an experimental microprocessor. Work is going on nicely, and I've until now found the answer to all my questions directly in the LLVM source code, or in the documentation. However, I'm having problems with the AsmBackend class and the handling of fixups. The processor I'm working with has a single conditional branch instruction, JCC,

Hi Andy, We have done some experimental evaluation of the different schedulers in LLVM 3.3 (source, BURR, ILP, fast, MI). The evaluation was done on x86-64 using SPEC CPU2006. We have measured both the amount of spill code as well as the execution time as detailed below. Here are our main findings: 1. The SD schedulers significantly impact the spill counts and the execution times for many

All, Attached below are the patches that make up the Apple ARM64 compiler backend (in addition to compiler_rt, libc++ and lldb support), and we'd like to start the process of integrating them into mainline LLVM. We and ARM have discussed a general approach to integrating them into mainline and look forward to working through this with the community at large. First a bit of context to help