similar to: RFC: Are auto-generated assertions a good practice?

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

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

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

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

On Fri, May 4, 2018 at 11:30 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > 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

Hi, try adding some alias analysis to the pipeline: see examples in llvm/test/Analysis/MemorySSA/*.ll for example assume.ll has ; RUN: opt -aa-pipeline=basic-aa -passes='print<memoryssa>,verify<memoryssa>' without basic-aa the memory ssa will safely assume that the stores to %a and %d alias which may be proven disjoint by one of the alias analyses. On Thu, Aug 9, 2018 at 8:37

Hello, There is a particular code sequence I would like to optimize at the IR level. I'd like to turn an Arm/AArch64 table lookup intrinsic that takes a constant vector mask into a shufflevector instruction: vtbl1(V,mask) ~> shufflevector(V,undef,mask) The reason is that if the mask is {7,6,5,4,3,2,1,0}, then the backend will generate rev64 instructions instead. If the mask comes

Hi, I have a question about how llvm MemorySSA works, as seems I misunderstand something. Consider following code snippet and corresponding IR with MemorySSA annotations (got with opt -print-memoryssa) void foo(int* b) { int a = 0; int d = 12; if (b) { a = 42; d = 32; } int c = a; int e = d; } ; Function Attrs: noinline nounwind optnone uwtable

I've run update_llc_test_checks on a set of tests and am seeing some weird behavior. The CHECK lines appear directly after the function's first line, even if there are multiple arguments. E.g.: define <vscale x 4 x i32> @sel_nxv4i32(<vscale x 4 x i1> %p, ; CHECK-LABEL: sel_nxv4i32: ; CHECK: // %bb.0: ; CHECK-NEXT: mov z0.s, p0/m, z1.s ; CHECK-NEXT: ret

Shot in the dark here...haven't tried it myself so no promises. There's probably a much better way to do this but sometimes a little "brute force" helps. Theoretical steps: 1. Stop all mail processes - both SMTP and IMAP. 2. Use "doveadm sync" to backup the user mailbox, e.g., doveadm backup -u user mdbox:/tmp/usermail 3. Verify /tmp/usermail looks reasonable

Yes I have done it, it is the third command I have run, without any change. a. On 02/04/2015 09:53 ??, Urban Loesch wrote: > Did you "purged" the deleted mails for this user? > On mdbox you must run "doveadm purge -u $USER" to whipe out any as deleted marked mails etc. > > Details: http://wiki2.dovecot.org/Tools/Doveadm/Purge > > I use a nightly cronjob wor

There are multiple problems/questions here: 1. Make sure you've updated trunk to the latest rev before running update_llc_test_checks.py on lea-3.ll. Ie, I would only expect the output you're seeing if you're running the script on a version of that test file before r313631. After that commit, each RUN has its own check prefix, so there should be no conflict opportunity. 2. I

For the tests that are changing, you should see if those changes are improvements, regressions, or neutral. This is unfortunately not always obvious for x86 asm, so feel free to just post those diffs in an updated version of the patch at D37896. If the test files have auto-generated assertions (look for this string on the first line of the test file: "NOTE: Assertions have been autogenerated

LLVM Weekly - #227, May 7th 2018 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/227>. Welcome to the two hundred and twenty-seventh issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

Hi, I am currently working on a more or less intrusive patch (D37896), which pulls optimizations on multiplications from some back-ends, e.g., (mul x, 2^N + 1) => (add (shl x, N), x) in AArch64, into the DAGCombiner to have this optimization generic on all targets. However, running the LLVM Tests leads to 67 unexpected results. Am 19.09.2017 um 15:58 schrieb Sanjay Patel: > For the

Do you want to get in... ...and got what it takes? I''m working as it-responsible (diplomatic service) for the Republic of Cyprus. Now I want to move on, I know that I have the next big thing in the dot com biz. It all begun from a dream that became a businessplan and also later on was nominated by UN World Summit Awards and won the title as best initiative in category ICT. In a few

Hi Sanjay, thanks for this information. I did get a little bit further with the patch. However, Hexagon gives me headaches. I tried to limit the scope of the patch to the BeforeLegalizeTypes phase and Hexagon still reaches the unreachable. Hexagon tries to split or widen a vector type for a node with custom lowering where the unreachable arises from inside TargetLowering::ReplaceNodeResults

Hello everybody! I´d like to know where "xm top" gets its information from. I want to get those informations (cpu-load, mem etc. from the domUs) and display them with php in a browser. So are the informations stored and updated in a textfile or something like that? Can anybody help me with this? Regards Alexandros _______________________________________________ Xen-users mailing

Is VT a legal type on Hexagon? It looks like Hexagon may be setting SHL as Custom for every defined vector type. Try adding TLI.isTypeLegal(VT) too. ~Craig On Thu, Sep 21, 2017 at 10:06 PM, Haidl, Michael < michael.haidl at uni-muenster.de> wrote: > Hi Sanjay, > > thanks for this information. I did get a little bit further with the > patch. However, Hexagon gives me headaches.

Hello everybody, i have a problem setting up a DomU with Windows XP. I get the following error: xen:/etc/xen# xm create windows.hvm Using config file "./windows.hvm". VNC= 1 Unexpected error: exceptions.OSError Please report to xen-devel@lists.xensource.com Traceback (most recent call last): File "/usr/lib/xen-3.1-1/bin/xm", line 7, in ? main.main(sys.argv) File