IRGen/objc_simd.sil

[modocache]

******************** TEST 'Swift :: IRGen/objc_simd.sil' FAILED ********************
Script:
--
/home/modocache/GitHub/apple/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift -frontend -target armv7-none-linux-androideabi -sdk /home/modocache/android-ndk-r10e/platforms/android-16/arch-arm   -enable-source-import -sdk '/home/modocache/GitHub/apple/swift/test'/Inputs/clang-importer-sdk -I '/home/modocache/GitHub/apple/swift/test'/Inputs/clang-importer-sdk/swift-modules   -emit-ir /home/modocache/GitHub/apple/swift/test/IRGen/objc_simd.sil | FileCheck /home/modocache/GitHub/apple/swift/test/IRGen/objc_simd.sil --check-prefix=armv7
--
Exit Code: 1

Command Output (stderr):
--
/home/modocache/GitHub/apple/swift/test/IRGen/objc_simd.sil:34:17: error: expected string not found in input
// armv7-LABEL: define <3 x float> @simd_c_args_float3(<4 x i32>)
                ^
<stdin>:12:46: note: scanning from here
define <4 x float> @simd_c_args(<4 x float>) #0 {
                                             ^
<stdin>:54:1: note: possible intended match here
define <3 x float> @simd_c_args_float3(<3 x float>) #0 {
^

The problem is that android-armv7 has @simd_c_args_float3 take an argument of <3 x float>, like the x86_64 check expects. But the check for armv7 expects <4 x i32> for some reason.

Running the tests for iphoneos-armv7 works (once you remove this pesky warning from the lit config):

diff --git a/test/lit.cfg b/test/lit.cfg
index cbc3277..4c84e2e 100644
--- a/test/lit.cfg
+++ b/test/lit.cfg
@@ -503,8 +503,7 @@ if run_vendor == 'apple':
         (config.variant_triple, stdlib_resource_dir_opt, mcp_opt))
     target_options_for_mock_sdk_after = sdk_overlay_dir_opt

-    if 'arm' in run_cpu and swift_test_mode != 'non_executable':
-        raise RuntimeError('Device tests are not currently supported.')

     if 'arm' in run_cpu:
        # iOS/tvOS/watchOS device

swift $ ../llvm/utils/lit/lit.py -v ../build/Ninja-ReleaseAssert/swift-macosx-x86_64/test-iphoneos-armv7/IRGen/objc_simd.sil
lit.py: lit.cfg:249: note: using swift: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swift
lit.py: lit.cfg:249: note: using swiftc: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc
lit.py: lit.cfg:249: note: using sil-opt: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/sil-opt
lit.py: lit.cfg:249: note: using sil-extract: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/sil-extract
lit.py: lit.cfg:249: note: using lldb-moduleimport-test: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/lldb-moduleimport-test
lit.py: lit.cfg:249: note: using swift-ide-test: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swift-ide-test
lit.py: lit.cfg:249: note: using swift-reflection-test: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swift-reflection-test
lit.py: lit.cfg:249: note: using clang: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/bin/clang
lit.py: lit.cfg:249: note: using llvm-link: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/bin/llvm-link
lit.py: lit.cfg:249: note: using swift-llvm-opt: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swift-llvm-opt
lit.py: lit.cfg:290: note: Using resource dir: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/lib/swift
lit.py: lit.cfg:316: note: Using Clang module cache: /var/folders/ry/2ryfdsb56b30092626qprw6d3rb3ss/T/swift-testsuite-clang-module-cachevjTIdD
lit.py: lit.cfg:320: note: Using code completion cache: /var/folders/ry/2ryfdsb56b30092626qprw6d3rb3ss/T/swift-testsuite-completion-cacheuAPXjd
lit.py: lit.cfg:511: note: Testing iOS armv7-apple-ios7.0
lit.py: lit.cfg:622: note: Running tests on iPhone OS version 9.2 (13C75)
lit.py: lit.cfg:801: note: Using platform module dir: /Users/bgesiak/GitHub/apple/build/Ninja-ReleaseAssert/swift-macosx-x86_64/lib/swift/%target-sdk-name/armv7
-- Testing: 1 tests, 1 threads --
PASS: Swift :: IRGen/objc_simd.sil (1 of 1)
Testing Time: 0.05s
  Expected Passes    : 1

In other words, it looks like the armv7 check works for most platforms. @hpux735 never mentions it in his lists of failing tests, so I'm assuming this works for linux-armv7 as well.

So why does simd behave differently on android-armv7?

[hpux735]

That's right, I've never noticed that this test fails. I can't promise that it runs, however.

My first thought goes back to the recent discussion about softfloat on android. I don't know much about android, but if it's using floating point emulation, I could see that it would implement this as a vector of floats to better match other environments. Whereas on linux-armv7, SIMD is supported (I believe), but is likely limited by the actual hardware implementation. The NEON unit is a 128-bit SMID system, so the 4x32 vectors make sense, but what doesn't make sense to me in the linux-armv7 case is the use of i32 types.

Disclaimer: I could be completely full of it, this is just a guess.

[modocache]

Thanks, @hpux735! I'm still investigating.

One theory I'm bouncing around after reading this article: I know that different CPU vendors have different implementations of SIMD, such as MMX, AltiVec, 3DNow, SSE, and NEON. ARM uses NEON, whereas Intel processors use MMX. Is it possible these explain the discrepancies in this test?

But again, I'm stumped, since Linux ARM, which I suppose uses NEON, should have the same discrepancy.

That's right, I've never noticed that this test fails. I can't promise that it runs, however.

@hpux735, would it be possible for you to check whether this test is an XFAIL or UNSUPPORTED on Linux ARM? You should be able to do so using:

swift $ ../llvm/utils/lit/lit.py -v ../build/Ninja-ReleaseAssert/swift-linux-armv7/test-linux-armv7/IRGen/objc_simd.sil 

[hpux735]

@modocache Very interesting, loved the link.

I certainly do think it's possible that the discrepancies could be related to those differences. Also, I agree that it should be the same.

I tried that test, and it is run and passes on linux-armv7.

Have you looked at its includes (does it include simd.h)? I wonder if there is a test in there that isn't matching correctly in armv7-android and is choosing a different set of intrinsics (or software fall-back).

[modocache]

This failure still occurs on apple/swift master. I'm working on migrating this GitHub issue into a Swift JIRA task.

[ephemer]

@modocache @hpux735 do either of you have experience using explicit SIMD instructions in Swift on non-Apple platforms?

I was just working on our bandpass filterbank today and got it performing even faster than the Accelerate framework when float4s are available. Would like to open-source this but its scope is pretty limited until it's available cross-platform.

I saw somewhere (maybe this thread) that LLVM'a builtin SIMD intrinsics are available in the stdlib but they don't seem to be exposed beyond that. Any ideas?