similar to: Testing End-To-End Functionality of Specific Optimization

Typically the "end-to-end" test cases reside in `projects/test-suite`. All the test cases there build executable binaries from source, run those and compare the output (as well as the return code) to what's expected. You should probably put your test cases in there. Please note also that there are subcategories there - there are single source file and multiple source file programs.

Ah, thank you, that makes sense. Is there any chance you can point me toward some documentation for how to add tests to the test-suite? I've found a fair bit on how to run the tests, but nothing on how to add new ones. Is it just as simple as adding testcase.c and testscase.reference_output in the appropriate directory? Thanks! On 01/02/2018 02:50 PM, Nemanja Ivanovic wrote: >

I am far from an expert on this since I've only ever added one or two of these IIRC. But as far as I remember, for most purposes, that's all you need. Add a source file, add an expected file and add the source file to the CMakeLists.txt (along with any additional CFLAGS/CXXFLAGS/LDFLAGS)... Of course, if you need anything custom, there are likely examples in the test suite that you can use

Typically this would be tested alongside the runtime component in compiler-rt. For example, PGO instrumentation has its "end-to-end" tests in https://github.com/llvm-mirror/compiler-rt/tree/master/test/profile -- Sean Silva On Tue, Jan 2, 2018 at 11:16 AM, Eli Davis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello! > > I am writing an instrumentation pass using

Ah, that makes a lot of sense. Thank you! Do you have any tips (or points to documentation) for how to run compiler-rt tests? Just invoking llvm-lit doesn't seem to work On 01/03/2018 11:17 PM, Sean Silva wrote: > Typically this would be tested alongside the runtime component in > compiler-rt. > For example, PGO instrumentation has its "end-to-end" tests in >

On Thu, Jan 4, 2018 at 8:14 AM, Eli Davis <eli at aarno-labs.com> wrote: > Ah, that makes a lot of sense. Thank you! Do you have any tips (or points > to documentation) for how to run compiler-rt tests? Just invoking llvm-lit > doesn't seem to work > They should run as part of check-all when you have compiler-rt checked out in llvm/projects/ (or the equivalent with the

Hello: I am new to llvm. I am looking for an example somewhere, or a walkthrough/guide on how to do runtime optimization using llvm. Ideally, I would like to: 1. Compile the program from C to LLVM or native with LLVM information embedded in the binary. 2. Run the binary under LLVM's interpreter, and profile the data. I hope LLVM has support for all this, and I don't have to insert my own

The team I am working with is using asm statements containing label definitions as a way of instrumentation so that when an application is loaded into their debug and test framework, the labels will cause breakpoints to be set at strategic points where they can query the state of the processor that the application is running on. ~ Todd From: Eli Friedman [mailto:efriedma at quicinc.com] Sent:

On Sat, Sep 20, 2008 at 12:12 PM, madiyaan <ahmadsharif at hotmail.com> wrote: > Hello: > > I am new to llvm. I am looking for an example somewhere, or a > walkthrough/guide on how to do runtime optimization using llvm. Ideally, I > would like to: > > 1. Compile the program from C to LLVM or native with LLVM information > embedded in the binary. > 2. Run the binary

I'm wondering why the lit tests didn't catch this as part of testing rc1 on ARM. On Thu, Jan 26, 2017 at 11:25 AM, Serge Rogatch <serge.rogatch at gmail.com> wrote: > XRay is tested automatically on build-bots with tests in LLVM and > compiler-rt . Or are you asking for manual testing instructions? > Of these 2 patches, the compiler-rt patch depends on LLVM patch because

With llc, the size of the names section can vary widely depending on the value of -DLLVM_TARGETS_TO_BUILD. Enabling coverage shouldn't increase the name section size much. I only see one place where this happens, and it's relatively cold: http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at

On Thu, May 17, 2018 at 3:09 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 5/17/2018 10:10 AM, Kenneth Adam Miller via llvm-dev wrote: > >> Hello, >> >> >> I've looked around in the documentation, and I can't see anywhere where >> there is a backend plugin capability for LLVM. I'd like to be able to get >> the output of the

Hello, I am wondering whether I can get the variable name of loop trip count in LLVM? For example, int NUM; NUM=atoi(argv[i]); for (int i=0; i<NUM; i++) { ... } How can I get the corresponding variable name for "NUM"? Then, I can instrument something in the source code to record the loop trip count for a given input data set. BasicBlock* b = L->getHeader(); returns the

On Mon, Apr 5, 2010 at 1:19 PM, Zheng Wang <jason.wangz at gmail.com> wrote: > Hello, > > I am wondering whether I can get the variable name of loop trip count in LLVM? > > For example, > > int NUM; > > NUM=atoi(argv[i]); > > for (int i=0; i<NUM; i++) > { >    ... > } > > How can I get the corresponding variable name for "NUM"?

> This is a public interface. But ASan runtime (and test-suite) strongly depends on > the instrumentation pass in Clang. How do you feel about adding a runtime init check of a version number defined by asan_interface.h? -Greg On Tue, Apr 22, 2014 at 11:16 AM, Alexey Samsonov <samsonov at google.com> wrote: > > On Tue, Apr 22, 2014 at 10:43 AM, Greg Fitzgerald <garious at

On Wed, Oct 9, 2019 at 8:12 AM David Greene <dag at cray.com> wrote: > Mehdi AMINI via cfe-dev <cfe-dev at lists.llvm.org> writes: > > >> I have a bit of concern about this sort of thing - worrying it'll lead > to > >> people being less cautious about writing the more isolated tests. > >> > > > > I have the same concern. I really

On Jan 17, 2013, at 10:30 AM, Eli Bendersky <eliben at google.com> wrote: > On Thu, Jan 17, 2013 at 10:20 AM, Jim Grosbach <grosbach at apple.com> wrote: >> >> On Jan 17, 2013, at 9:57 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> >>> On Thu, Jan 17, 2013 at 7:51 PM, Sean Silva <silvas at purdue.edu> wrote: >>>> On Thu,

Hi Paul, Regarding the "No Touchie!" constraint idea for asm statements: would this be a new qualifier (like volatile) that could be applied to the asm statement? Since the constraint is not necessarily associated with an input or output operand, it seems that introducing the constraint via the qualifier field might work. All, The volatile qualifier on an asm statement already

I had an old build of llc with FE instrumentation, the name section size is about 5MB. Using coverage is likely to cause the name section to be larger as there are more references to dead/unused function names. What do you see when readelf --string-dump=__llvm_prf_names llc David On Tue, Jun 27, 2017 at 2:23 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Tue,

On Thu, Jan 17, 2013 at 10:59 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Thu, Jan 17, 2013 at 10:51 AM, Daniel Dunbar <daniel at zuster.org> wrote: > > Note that as far as places to put temporary files, the right place to put > > them is alongside the other test outputs in the test output "sandbox" > > directory. > > > > Somewhat