similar to: [RFC] Compiled regression tests.

Am Mi., 24. Juni 2020 um 00:37 Uhr schrieb David Blaikie <dblaikie at gmail.com>: > I'm pretty change averse - and am in this case (but doesn't mean other folks won't be in favor and doesn't mean it isn't worth trying, etc - but if it were up to me, at the moment, I'd decline) That's understandable. New features also come with a cost that they need to recoup

Am Mi., 24. Juni 2020 um 11:19 Uhr schrieb Mehdi AMINI <joker.eph at gmail.com>: > > Hi, > > On Tue, Jun 23, 2020 at 6:34 PM Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello LLVM community, >> >> For testing IR passes, LLVM currently has two kinds of tests: >> 1. regression tests (in llvm/test); .ll files invoking

When writing MachineFunction unit tests, I find it quite tedious to verify correctness in C++. I would like to use FileCheck in UnitTests because FileCheck is extremely convenient/robust to verify correctness. In order to do so, I moved most of FileCheck’s implementation into a header (Support/FileCheck.h) and updated FileCheck.cpp to use this. I ran into this while writing some target agnostic

> On 2 Jul 2018, at 15:13, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I had similar gripes with unit testing machine function stuff. I personally would have preferred to create more tests based on a tool like llc rather than pushing more on the unit test side. Anyway I tried to push https://reviews.llvm.org/D48850 <https://reviews.llvm.org/D48850> in

Am Di., 30. Juni 2020 um 15:58 Uhr schrieb Chris Lattner <clattner at nondot.org>: > One of the major and important pieces of the LLVM design is how its testing infrastructure works. The choice to use a small number of tools (llc, opt, etc) is important for multiple reasons: > > 1) Link time of executables is a significant problem, particularly in large scale builds. You can use

On Thu, Nov 14, 2013 at 1:04 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > I think the cost of carrying it around is essentially zero. I'm happy to > do > > any of the maintenance. People who don't know how to use it or want to > learn > > how to use it don't need to use it. If it isn't making their job of > writing > >

Philip Reames wrote: > T.M.K., there's no direct way to test it. There is. See the 'unittests/' directory which contains the C++ unit tests. See unittests/IR/UserTest.cpp for an example that builds up IR from a .ll-in-a-C-string then queries C++ API operations on it. Nick You have to construct a > transformation which happens with the information you added and not >

On Nov 14, 2013, at 2:44 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Nov 14, 2013 at 1:04 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > I think the cost of carrying it around is essentially zero. I'm happy to do > > any of the maintenance. People who don't know how to use it or want to learn > > how to use it don't

I'm adding the dev list to this discussion, as it's a bit meta, and not specific to these patches. On Thu, Aug 16, 2012 at 12:55 PM, Will Schmidt <will_schmidt at vnet.ibm.com>wrote: > On Thu, 2012-08-16 at 15:06 -0400, Rafael Espíndola wrote: > > On 16 August 2012 14:33, Chandler Carruth <chandlerc at google.com> wrote: > > > Test cases? > > > >

The test as written is fragile because it requires a certain ordering. If the output order is not important, use CHECK-DAG rather than CHECK. This would be a failure to understand the testing tool. My experience, over a 40-year career, is that good software developers are generally not very good test-writers. These are different skills and good testing is frequently not taught. It’s easy to

On Thu, Nov 14, 2013 at 10:58 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 14, 2013, at 3:16 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > However, when we are adding interfaces or generic utilities to LLVM > (admittedly, not the common case) I don't think we do ourselves any favors > by using only half of the available tools to write

Writing a more thought-out reply.... On Tue, Nov 12, 2013 at 9:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 12, 2013, at 7:04 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > I have some concrete use cases in testing the pass manager where it will > allow the tests of this API to be more thorough, less verbose, and easier > to

A long time ago I suggested that we might want to add gmock to compliment the facilities provided by gtest in LLVM's unittests. It didn't go over well: 1) There was concern over the benefit vs. the cost 2) Also concern about what the facilities would look like in practice and whether they would actually help 3) At the time, I didn't have good, large examples of what these things might

----- Original Message ----- > From: "İsmail Dönmez" <ismail at donmez.ws> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, May 12, 2014 7:18:48 AM > Subject: Re: Lots of regtest failures on PPC64/Linux > > > Hi Hal, > > > > > > On

On 7/2/20 12:44 AM, Michael Kruse wrote: > Am Mi., 1. Juli 2020 um 14:36 Uhr schrieb Hal Finkel <hfinkel at anl.gov>: >> When I teach my compilers class, I tell my students to liberally add the >> ability to serialize to interpretable text all of their internal data >> structures. It will seem like extra work at first, but when they're >> trying to debug things

On Nov 12, 2013, at 7:04 PM, Chandler Carruth <chandlerc at google.com> wrote: > I have some concrete use cases in testing the pass manager where it will allow the tests of this API to be more thorough, less verbose, and easier to maintain. I'm not claiming to be the biggest fan of some features in GoogleMock, but on the whole, I think it's better than the alternative and will

On 7/1/20 12:40 AM, Michael Kruse via llvm-dev wrote: > To illustrate some difficulties with FileCheck, lets make a > non-semantic change in LLVM: > >     --- a/llvm/lib/Analysis/VectorUtils.cpp >     +++ b/llvm/lib/Analysis/VectorUtils.cpp >     @@ -642,8 +642,8 @@ MDNode *llvm::uniteAccessGroups(MDNode > *AccGroups1, MDNode *AccGroups2) { >          return AccGroups1;

Am Mi., 24. Juni 2020 um 10:12 Uhr schrieb David Blaikie <dblaikie at gmail.com>: > > As mentioned in the Differential, generating the tests automatically > > will lose information about what actually is intended to be tested, > > Agreed - and I didn't mean to suggest tests should be automatically > generated. I work pretty hard in code reviews to encourage tests to

On Thu, Nov 14, 2013 at 3:00 PM, Pete Cooper <peter_cooper at apple.com> wrote: > This is probably most like #1, but i would either improve (or add a > verbose option to) -debug-pass=Structure. Then just write a test which > calls opt with some passes and uses FileCheck to verify the debug output. > Yes, but see the problems with it that I brought up. Note that the new pass

Hi, This started as an off hand comment in [1] but this appears to be a real issue so I'm moving the discussion to the mailing list. In r270942 the time taken to run LibFuzzer's test became noticeably longer. I am building on * Arch Linux (4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux) * I am building libFuzzer and running its tests like so ```