similar to: Improved jump-threading in LLVM for finite state automata

+ Evgeny We have a jump threading pass downstream for this that we would love to upstream. I believe Evgeny was working on exactly this, i.e. preparing it for upstreaming. ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> Sent: 23 September 2020 19:16 To: Phipps, Alan <a-phipps

Hi Sjoerd We (at Huawei) also have a pass for this. Originally we implemented this back in 2018 and meant to upstream it, but there were some issues with the implementation that required some changes in the code. We started revising it,a few weeks ago. I thought now that there are multiple options, maybe we can discuss our approaches, and see if there is a preference in the community for one

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

Um texto embutido e sem conjunto de caracteres especificado associado... Nome: n?o dispon?vel Url: https://stat.ethz.ch/pipermail/r-help/attachments/20061101/4218da11/attachment.pl

Hi, Alan Thanks for making it clear. But I was more confused now :( I tested on a simple program and used both gcov and lcov to get branch coverage. The code and build commands as below: *Example simple.cc* #include <string> // If not comment this line, the branch coverage won't reach to 100% // #include <iostream> int main(int argc, const char* argv[]) { std::string str =

Hi, Alan Really very excited to receive your email and sorry to be slow replying, it has been exceptionally busy over the last few days ;( Your explanation made the problem clear to me. So gcov branch coverage should be called condition coverage and clang region coverage is branch coverage in fact(also known as *decision/C1*), right? And llvm/clang will support all the following coverage

+ Vedant Hi Hal, thanks. I apologize if my answers aren't as thorough as you would like; what I'm proposing is simply an extension to the existing infrastructure, so it would be enabled automatically as part of code coverage. Mapping of branch regions would be done in CoverageMappingGen and instrumented using the same profiling instrumentation mechanism under

This is off-topic. I''m hoping someone on this list can point me towards more general information on finite state machines, their definition, how to build them, determining when to apply them, etc. I read Zed''s blog entry from way back when covering Ragel [1] but he hasn''t followed it up and there aren''t many pointers to external information.

Hi, llvm/clang experts I need to get the branch coverage for some testing code. But i found gcov can't give a expected coverage which may count some 'hidden branch' in (See stackoverflow answer <https://stackoverflow.com/questions/42003783/lcov-gcov-branch-coverage-with-c-producing-branches-all-over-the-place>). Instead, I turn to use clang and the 'source-based code

When jump threading duplicates a basic block, it can demote register values defined in that block to the stack. This seems a bit inefficient - is the idea that you should run mem2reg afterwards to clean this up? "llvm-ld -O" runs jump threading but doesn't run any mem2reg pass afterwards, and I've seen several cases where variables end up left on the stack in the output of the

Hal Finkel wrote: > Hello, > > After investigating PR14133, I've discovered that jump threading can output self-referential instructions: > %inc.us = add nsw i32 %inc.us, 1 > > At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when vectorization is enabled, this

If I use the jump threading pass on the attached IR: $ opt before.ll -jump-threading -o - | llvm-dis -o after.ll a big chunk gets removed, a chunk that is actually necessary. ('before.ll' passes the test in webkit, while 'after.ll' fails) Can someone take a look ? -Argiris -------------- next part -------------- A non-text attachment was scrubbed... Name: before.ll Type:

Vedant Kumar asked me to post my design thoughts concerning branch coverage at llvm-dev since there is general interest. My team at Texas Instruments is developing an embedded ARM C/C++ compiler with LLVM. I would like to enhance LLVM's code coverage capability with branch condition coverage (for C/C++), similar to GCC/GCOV support for branch coverage. This is useful for TI, and I think

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

Hi Hal, > After investigating PR14133, I've discovered that jump threading can output self-referential instructions: > %inc.us = add nsw i32 %inc.us, 1 such instructions are valid in unreachable basic blocks. > At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when

Hello, After investigating PR14133, I've discovered that jump threading can output self-referential instructions: %inc.us = add nsw i32 %inc.us, 1 At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when vectorization is enabled, this instruction causes BBVectorize to hang. Should

Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679 I've been thinking about cases like it, such as: https://godbolt.org/z/Fwq8mn I wonder what we can do about this in a general sense. As far as I can tell, the jump threading algorithm is *really* conservative, which is one reason this isn't working as well as I'd hope; however, we don't want to produce

Hi, While comparing the code by LLVM and GCC for some major libraries, I found that LLVM fails to apply jump threading with a method whose return type is std::pair<int, bool> (actually, any pair of 32-bit values like std::pair<bool, int> and std::pair<int, int>). For example, jump threading does not work for the if statement in func. std::pair<int, bool> callee(int v) {

On Wed, 25 Jun 2008, Jay Foad wrote: > When jump threading duplicates a basic block, it can demote register > values defined in that block to the stack. This seems a bit > inefficient - is the idea that you should run mem2reg afterwards to > clean this up? > > "llvm-ld -O" runs jump threading but doesn't run any mem2reg pass > afterwards, and I've seen

On Sep 2, 2010, at 8:05 AMPDT, Argyrios Kyrtzidis wrote: > If I use the jump threading pass on the attached IR: > > $ opt before.ll -jump-threading -o - | llvm-dis -o after.ll > > a big chunk gets removed, a chunk that is actually necessary. > ('before.ll' passes the test in webkit, while 'after.ll' fails) > > Can someone take a look ? This is fixed in