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

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

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 >

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

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? > > > >

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

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

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

This seems to be happening to me, too. I think this happens for me on "ninja check-llvm" in a clean build. Let me know if you need more info. On Tue, Dec 10, 2019 at 2:22 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Jay, > > I am not sure why this happens. > Can you give me some information so I can reproduce it: > Is this happens

Johannes, This patch seems to be causing test failures when I just do "ninja check", without running "ninja" or "ninja all" first. $ CC=clang CXX=clang++ cmake -G Ninja ~/git/llvm-project/llvm -DLLVM_USE_LINKER=lld -DLLVM_PARALLEL_LINK_JOBS=4 -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 && ninja check [...] FAIL: LLVM ::

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;

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

Jay, Hiroshi, did [0] resolve the problem you've seen. [0] https://github.com/llvm/llvm-project/commit/d23c61490c282a7a8f29aaa5c021cbfdaf87fb6f On 12/10, Doerfert, Johannes wrote: > I think the problem is that only clang has a dependence on the new > library and when you check LLVM without building clang it does not exist > yet. I will commit a LLVM patch today that will cause LLVM