similar to: [PATCH] D50328: [X86][SSE] Combine (some) target shuffles with multiple uses

Simon Pilgrim <llvm-dev at redking.me.uk> writes: > Changing a test's IR to avoid an issue in a patch is very problematic, > but if any test's codegen changes because of a patch then it just > needs to be reviewed, preferably by someone who has touched that test > in the past. But wouldn't it be even better if that output didn't need to be changed at all and

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

I’m not sure if it’s truly deterministic. It always gives the same results (so far) on my machine but I’m not sure that’s enough. My guess is it’s probably going to be deterministic on one machine but might well not be deterministic across environments. Like it might give varying results if cross compiled on different hosts, macOS vs intel Linux vs arm vs s390. (Obviously AVR is always a cross

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

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

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

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.

Hi Craig, protecting the transformation with: if (TLI.isTypeLegal(VT) && TLI.isOperationLegal(ISD::SUB, VT) && TLI.isOperationLegal(ISD::ADD, VT) && TLI.isOperationLegal(ISD::SHL, VT) && TLI.isOperationLegal(ISD::SRA, VT)) { shows the same result. Michael On 22.09.2017 07:19, Craig Topper wrote: > Is VT a legal type on Hexagon?

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

Hi Sanjay, thanks for enlighten me on terms of tests. I assume I have to run the test-suite benchmarks to check for regressions? Is there a guide to get the metrics from the benchmarks? Cheers, Michael BTW the beginner tag for bugs was really a good idea to get started with contributing to llvm. On Tue, Sep 19, 2017 at 3:58 PM +0200, "Sanjay Patel" <spatel at

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

Hi, Is there a rule or guideline about what Python versions must be supported for scripts in the LLVM tree? I am working on some patches to some scripts in LLVM to use features in Python 2.7, so that these scripts can run under Python 2.7 and Python 3.x Is that OK? For example, here is a patch to use print as a function, so that the scripts can work in Python 2.7 and Python 3.x -- Craig

Philip Reames via cfe-dev <cfe-dev at lists.llvm.org> writes: > A challenge we already have - as in, I've broken these tests and had to > fix them - is that an end to end test which checks either IR or assembly > ends up being extraordinarily fragile.  Completely unrelated profitable > transforms create small differences which cause spurious test failures.  > This is

Hi, Please consider the following loop: using v4f32 = float __attribute__((__vector_size__(16))); void fct6(v4f32 *x) { #pragma clang loop vectorize(enable) for (int i = 0; i < 256; ++i) x[i] = 7 * x[i]; } After compiling it with: clang++ -O3 -march=native -mtune=native \ -Rpass=loop-vectorize,slp-vectorize -Rpass-missed=loop-vectorize,slp-vectorize

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

I wonder why AVX is not used automatically if available at the host machine. In contrast to that, SSE41 instructions (like pmulld) are automatically used if the host machine supports SSE41. E.g. $ cat avx.ll define void @_fun1(<8 x float>*, <8 x float>*) { _L1: %x = load <8 x float>* %0 %y = load <8 x float>* %1 %z = fadd <8 x float> %x, %y store

Thanks Sanjay. Interestingly for me, disable-llvm-optmzns did not make a difference in the way the shift was handled. Does the initial IR generated for you show this difference when the option is passed? Best regards Saurabh On 17 February 2017 at 19:03, Sanjay Patel <spatel at rotateright.com> wrote: > I think this is caused by a front-end change (cc'ing clang-dev) because >

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

Correction in the C snippet: typedef signed short v8i16_t __attribute__((ext_vector_type(8))); v8i16_t foo (v8i16_t a, int n) { return a >> n; } Best regards Saurabh On 17 February 2017 at 16:21, Saurabh Verma <saurabh.verma at movidius.com> wrote: > Hello, > > We are investigating a difference in code generation for vector splat > instructions between llvm-3.9