similar to: [RFC] Improving FileCheck

On Mon, Apr 13, 2020 at 1:16 PM Jon Roelofs via llvm-dev < llvm-dev at lists.llvm.org> wrote: > As an update, after lots of fixes from a number of different people > (thanks everyone!), the current list of false-positives on `ninja > check-llvm` for the more stringent Gotcha A diagnostic is: > > LLVM :: Analysis/CostModel/X86/vselect-cost.ll > LLVM ::

Hi, 3.5.1-rc1 has been tagged, so it is time to begin testing. We can always use more testers, so if you would like to volunteer, let me know. For those that are new to testing, please review the documentation for how validate a new release: http://llvm.org/docs/ReleaseProcess.html Remember that when we check for regressions we want to compare the test results of 3.5.1-rc1 with 3.5.0-final.

Hi James, Yes I think you summary proposal is a good one though I disagree with the colon being optional because there is ambiguity with looking for the value of VAR5 in the %x format. If anything, [[# %x, VAR5]] is equivalent to [[#:%x, VAR5]] or ([[#:%x = VAR5]] with your proposal. My other suggestion would be to use == rather than = since = could be confused with assignment. Note that

I can certainly envision a use case for a [BASE + LENGTH + 4] computation to verify the address of a next-thingy. Comes up in DWARF dumps all the time. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Henderson via llvm-dev Sent: Tuesday, July 31, 2018 11:53 AM To: Thomas Preudhomme Cc: llvm-dev Subject: Re: [llvm-dev] Syntax for FileCheck numeric variables

Yep - all about balance. The main risk are tests that overfit (golden files being the worst case - checking that the entire output matches /exactly/ - this is what FileCheck is intended to help avoid) and maintainability. In the case of the autogenerated FileCheck lines I've seen so far - they seem like they still walk a fairly good line of checking exactly what's intended. Though I

Hello llvm-dev, On a recent code review I was asked to auto-generate assertion checks for my unit test. I wasn't aware that this was even possible. I am referring to the python `update` scripts under `utils` directory. My first reaction was wow! I found it very practical and useful. It saves you significant amount of time when writing a regression test. So I gave it a try. The generated

Hi Alex, Thanks for the feedback. My first thought was that introducing the new pseudo var @EXPR is a nice way to generalize that syntax beyond @LINE since it would also evaluate to an arithmetic value. On the other hand there is a small inconsistency because @LINE evaluates to a value which can be part of an expression while @EXPR is an expression, and so the @ syntax as a whole becomes defined

To be clear, I do not intend to add support for hex specifier in the current patch, I just want to make sure the syntax we choose is going to allow it later. My immediate use case is decimal integer and I intend to write the code so that it's easy to extend to more type of numeric variables and expressions later. This way we'll only add specifier that are actually required by actual

Hi Alexander, Please forgive me if I'm missing the obvious but I do not see how the order helps allowing a comma in the expression. It seems to me that what would allow it is to make FMTSPEC mandatory or at least the comma to separate it (ie. [[#,EXPR]] for the default format specifier). In any case comma in a function-call like expression can be distinguished from comma for the format

We have a similar option (-split-input-file) in `mlir-opt`: https://github.com/llvm/llvm-project/blob/master/mlir/test/Dialect/Affine/invalid.mlir With a single `RUN:` lit invocation the tool itself will loop over all the split sections in the file. This is convenient to test error cases where the tool would abort at the first error otherwise. I don't think we can easily achieve this with a

On 4 May 2018 at 10:25, Alexandros Lamprineas via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello llvm-dev, > > > On a recent code review I was asked to auto-generate assertion checks for my > unit test. I wasn't aware that this was even possible. I am referring to the > python `update` scripts under `utils` directory. My first reaction was wow! > I found it

Hi Alex, On Fri, 27 Jul 2018 at 11:53, Alexander Richardson <arichardson.kde at gmail.com> wrote: > > On Thu, 26 Jul 2018 at 10:28 Thomas Preudhomme <thomas.preudhomme at linaro.org> wrote: >> >> Hi Alexander, >> >> Please forgive me if I'm missing the obvious but I do not see how the >> order helps allowing a comma in the expression. It seems

On Fri, May 4, 2018 at 10:16 AM Sanjay Patel <spatel at rotateright.com> wrote: > I understand the overfit argument (but in most cases it just shows that a > unit test isn't minimized)... > Even minimized tests sometimes need a few other things to setup the circumstance (many DWARF tests, for example - produce the full DWARF output, but maybe you only care about one part of it

Hi James, I like that suggestion very much but I think keeping the order of the two sides as initially proposed makes more sense. In printf/scanf the string is first because the primary use of these functions is to do I/O and so you first specify what you are going to output/input and then where to capture variables. The primary objective of FileCheck variables and expressions is to capture/print

Hello, Is there a script to update those test cases? I see mention of a sed script in the commit message but when I try it (see attached) on sed I get the following error: sed: file script line 2: invalid reference \3 on `s' command's RHS Did I lose something in a copy-paste? Is it not really a sed script? How do I run it? On Fri, Jan 19, 2018 at 9:15 AM, Daniel Neilson via

Dear all, I compiled c program with llvm and found something strange with function pointer as following small example . ------------- In C Code -------------- float a (int value) { return value + 1; }; typedef float (*funcptr_t) (int); funcptr_t get_ptr(funcptr_t p) { return p; } float result = get_ptr(a)(4); ------------- In LLVM Code -------------- %4 = call float (i32)* (float

Dear testers, 8.0.0-rc1 was just tagged (from the branch at r351980). It took a little longer than planned, but it's looking good. Please run the test script, share your results, and upload binaries. I'll get the source tarballs and docs published as soon as possible, and binaries as they become available. Thanks, Hans

I understand the overfit argument (but in most cases it just shows that a unit test isn't minimized)...but I don't see how the complete auto-generated assertions could be worse at detecting a miscompile than incomplete manually-generated assertions? The whole point of auto-generating complete checks is to catch miscompiles/regressions sooner. Ie, before they get committed and result in

Thanks, that worked like a charm except for the following: llvm generate: call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* align 1 bitcast ([512 x float] addrspace(3)* @a_scratchpad to i8 addrspace(3)*), i8 addrspace(1)* align 1 %0, i64 2048, i1 false) And we expected: call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8

Yes, all that is correct. My question is more a long term question: why do the .ll printer specify the alignment if it is equivalent to the default one? That is, it seems the sed script expect the printer to not specify it (this would match the load/store behavior), but the ll-printer does specify it, which either means the printer is not ideal on this case and I should fix it, or in this case