similar to: [LLVMdev] lit: LLVM style valgrind

Hi, Me and my supervisor are interested in improving llvm's lit a little bit. Currently, there are few things, that seem to be not very convenient about the tool: * Having several RUN commands in a failing test, it's impossible to figure out, which of them actually caused the test to fail. We can output the number of the failing RUN line. * It would be nice to

Hi, > Cool, I hope this succeeds. I tried implementing per-test timeouts before, and couldn't get it to work in all cases. The review eventually fizzled out, and I abandoned it. > > Here's that old review: http://reviews.llvm.org/D6584 Perhaps you can cannibalize testcases from it. Thanks for that. I'll take a look. > >> >> I'm e-mailing llvm-dev rather

When some lit tests fail, I find it time-consuming to locate the source line of the failing RUN command. Running lit with -vv (or just -v in the case of the internal shell) makes it easier because it prints an expanded version of each RUN command as it executes, but it can still be challenging because lit doesn't provide the RUN command's source line number. While I haven't

Out of curiosity, how would you envision fast-math flags interacting with constant expressions? Off the top of my head, I can’t think of any flags that would be relevant if the expression can just be constant-folded away at full precision anyways. > On Nov 28, 2014, at 4:56 AM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com> wrote: > > Doesn't look like a bug, more like a

Hello Sergey, thanks for the suggestion. The name of the pass is not what triggers the assertion. The test case I attached to the email is a stripped-down version of a much more complicated pass (with a proper name) that originally caused the problem. Also, to be sure, I just tried to change the name of the pass to something more significant. It did not work. Cheers, Alberto On Sun, Aug 10,

Seems useful, but the current output is quite verbose. Wouldn’t just RUN:1; ls be sufficient in place of 'RUN: at line 1’; ls ? I’m also curious about the implementation, I recall there was a discussion about forcing all tests to use internal shell? In that case a trick with a no-op “:” command would not be necessary. George > On Apr 2, 2018, at 1:25 PM, Joel E. Denny via llvm-dev

Hi all, As you may or may not have noticed, I have gradually been replacing the testing infrastructure in LLVM. Most of this work is moving LLVM and Clang to share a single testing tool, 'lit'. See: http://llvm.org/cmds/lit.html for documentation on the tool itself. If you haven't already tried it, please consider switch to 'make check-lit' as an alternative to 'make

Hi, I'd like to make code emitted by LLVM that includes floating point operations which raise FP exceptions behave closer to what is defined by IEEE754 standard. I'm not going to "fix everything", just incorrect behaviour I faced so far. Most of troubles regarding FP exceptions are caused by optimizations, so there should be a flag to disable/block them if one wants to get

Hi Renato, > > I'm trying to add pseudo 64-bit load and store instructions for AArch64, which > > should have latencies set to "1" while being otherwise exactly the same as > > normal load and store instructions. > > Can I ask why would you need that? This is the only way I found to stop Machine Instruction Scheduler from reordering load and store

On Mon, Oct 19, 2009 at 2:03 PM, Eric Christopher <echristo at apple.com> wrote: > On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote: >> If you haven't already tried it, please consider switch to 'make >> check-lit' as an alternative to 'make check'. If it doesn't work for >> you, or you find it doesn't do something DejaGNU did and you like,

Hi, I'm wondering why lib/AsmParser/LLParser handles fast-math flags in the following IR: ... %val = fmul nnan double 1.0, 1.0 ... but doesn't allow any flags if "fmul" is inside "phi": ... %val = phi double [ fmul (double 1.0, double 1.0), %cond.true ], [ fmul (double 1.0, double 1.0), %cond.false ] ...

Dear all, Recently I've considering using LIT for my benchmark testing framework, and the only reference for LLVM-LIT is the man page and some READMEs. I don't find any documentations on config, which seems to be quite important to the tool. If I use lit outside LLVM source tree and use on my own test files, LIT marks them as 'unresolved'. So are there any documentations I can

On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote: > If you haven't already tried it, please consider switch to 'make > check-lit' as an alternative to 'make check'. If it doesn't work for > you, or you find it doesn't do something DejaGNU did and you like, > please let me know. My eventual plan is to move to lit entirely and > drop DejaGNU support, so

On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote: > Hi all, > > As you may or may not have noticed, I have gradually been replacing > the testing infrastructure in LLVM. Most of this work is moving LLVM > and Clang to share a single testing tool, 'lit'. See: > http://llvm.org/cmds/lit.html > for documentation on the tool itself. > > If you haven't already

Ok, that makes sense. I don't see this as a good enough argument to remove backslash support though. For problems like the clang_cc1 substitution mistakes, it would be much better to just improve the substitution support so that those cause immediate test failures. I would definitely support a move to make lit's substitution machinery more strict. For problems like your first search, I

Hi, There are several places in compiler-rt which refer to __aeabi_idiv0. For example, in lib/builtins/arm/udivsi3.S: #ifdef __ARM_EABI__ b __aeabi_idiv0 #else JMP(lr) #endif At the same time there is no definition of it. It looks as if it was done intentionally so that third-party could provide custom handler for division by zero. IMHO It's not very consistent and looks odd as

On Sun, Oct 18, 2009 at 7:49 PM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi all, > > As you may or may not have noticed, I have gradually been replacing > the testing infrastructure in LLVM. Most of this work is moving LLVM > and Clang to share a single testing tool, 'lit'. See: >  http://llvm.org/cmds/lit.html > for documentation on the tool itself. >

Hello, I'm trying to add pseudo 64-bit load and store instructions for AArch64, which should have latencies set to "1" while being otherwise exactly the same as normal load and store instructions. Various assertions fire (even different ones for the same binary, maybe something is uninitialized) and I can't understand what's wrong. Related pieces added by me: to

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

Hi all, I am trying to create an out-of-tree LLVM project. I have written a Test project following the guide in [1] that triggers the problem. Pass body is in [2]. The CMakeLists.txt file for the "root" directory is in [3] The CMakeLists.txt file for the "pass" directory is in [4] When I run opt --load=libTest.so I trigger the following assertion: opt: CommandLine.cpp:134: