From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=gc+v=46=gmail.com=nick87720z@sourceware.org>
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230])
	by sourceware.org (Postfix) with ESMTPS id D16883858D1E
	for <gcc@gcc.gnu.org>; Sun,  1 Jan 2023 14:53:16 +0000 (GMT)
Received: by mail-lj1-x230.google.com with SMTP id e13so24301936ljn.0
        for <gcc@gcc.gnu.org>; Sun, 01 Jan 2023 06:53:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=YvMfF45FckvLrjXKE/i99DdPZHPCgHbghxYxhvYIXCs=;
        b=Xbn3tIf2tF1kLgKUPY4G1WSR1WS0dE7Bf8z0zXE5NGpQKkCuGFMq5xwdyNeNPky5hn
         qj5F/+NU2uSGjxipphaR5e4g9940HmaWtV6cpWqkdbUS4gyO7VQeXWpTXzcZfhqv83Ig
         p+RZlcSvbPnZDMuI+AW9r+jI6tr2WXRITKirzmn4LGNASMZYQXcxrfIEDexaudQb6rim
         KRGifwOC+hxuY+picSqrp685ugQW2sYE/K9amWMIY8rizKa9rePuRYsspf5Oy7yuZ/Bu
         XaLOJH4Ix0SyX/76Lseb9+jcl7l0+Ye3dCC9Jf9boOoW/ehwDrex6E0nV79jVIT5ZhU3
         hLVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=YvMfF45FckvLrjXKE/i99DdPZHPCgHbghxYxhvYIXCs=;
        b=idr2IgaIzkyNRqyh6zLsCmeS8MpGcZATKTWRoLveogN3Gbp8yTufnxqoOWkCoPe6VN
         Kfz8I1wKvhA1idHzq3WnmSlrfl7jSxYoniNJK9GKTltKGSCA79HHd5ObpMvxi+kk7a1A
         9LvNQt2lhaSn6VblNvc8iWHXiq8S7VMVnHtwLd/4m0YaM4bd03KGVAeB8MInVgtuEcOa
         yXlzXGuKxjznjKRu72meiutF7tDlYYz9oFfv/eV2I8kmG+0+Q22A8J9OEZj5KeiICMkd
         wAKM8xA7NtCw/uZU616EfUMQShMEb5zo5r71CnbCYYFRrBo0dZ4Km0r+4LEzTYf7EbTn
         02mw==
X-Gm-Message-State: AFqh2krpuIbctENGF3HY+G2nW94FYTsbR08dOxNiXpf4cQcRwsa0Uh0u
	WwrZKmnjsg/YTJr8Mtu169qY6+RhRIqvWioRa209hbLKzVmP5Q==
X-Google-Smtp-Source: AMrXdXtKPcKArmOr3ta52YzJqV+ryOQU0/oGvOF+3w4jMg4mO1MYmtj5Exee5FcaFoY83Q+vZmqDCpciWgNCmYGeuEk=
X-Received: by 2002:a2e:6d11:0:b0:27f:b924:df35 with SMTP id
 i17-20020a2e6d11000000b0027fb924df35mr1032282ljc.498.1672584794740; Sun, 01
 Jan 2023 06:53:14 -0800 (PST)
MIME-Version: 1.0
From: Nikita Zlobin <nick87720z@gmail.com>
Date: Sun, 1 Jan 2023 19:53:03 +0500
Message-ID: <CAGaigJORdgraoEjU_4Va3-SuJups9Zsgf=EmG+Y1BmzerO_yqQ@mail.gmail.com>
Subject: Limits and feature test macroses for vector extension
To: gcc@gcc.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc.gcc.gnu.org>

Vector extension is great, because allowes to use controllable
vectorization without dealing with each SIMD ISA separately. When
properly used, it allowes to get better performance, than with
auto-vectorization. However, there's just one issue.

While for specific SIMD, used as backends for vec-ext, it's possible
to check if they are supported, there's no similar features for vector
extension. The only way yo make it configurable without manually
checking each ISA, is to e.g. add configure parameter
--vector-size=<bytes>, with enough goot commentary for user to
understand, what should be there (to be specified in __attributes__((
bytes )) ).

My first approach was to check for possibility to make autodetected
config, e.g. with autoconf, ins such way (not ideal, just for start):

gcc -march=native -E -v - < /dev/null 2>&1 | awk 'BEGIN{ arr[0]=0;
delete arr[0]; } /cc1/{ for (i=1; i<=NF; i++){ if ($i ~ /-mno-/)
continue; switch ($i){ case /-m(mmx|3dnow|vis)/: arr[8]=1; break; case
/-m(sse|altivec)/: arr[16]=1; break; case /^-mavx[2]?$/: arr[32]=1;
break; case /-mavx-512/: arr[64]=1; break; } }; for (j in arr) print
j; }'

However, I discovered, that I have no idea, how to detect NEON vector
size in this way (even its presence). There was answer, suggesting to
check feature test macros. After trying this command:

gcc -march=native -dM -E - </dev/null | less

I discovered, that other ISA, like MMX, SSE and AVX, have similar
feature test macroses, e.g. __MMX__, __SSE2__, __AVX__. This means,
that simple C header with __GNU_SOURCE, would be enough to check for
each ISA without calling functions from Target Builtins extension.

However, it's not end. Some ISA have limited set of elementary types
to be used in vectors. E.g., MMX and 3DNow! don't support integer.
This may be issue if integer implementation of some code has better
performance than if using floating point format (even with same data
width). This neccesitates for real feature test macroses, representing
data types, supported by supported SIMD ISA.

E.g., for simple vector sizes - it could be done with array (example):

#define __EXT_VECTOR_SIZEV (int[]){64, 128, 256, 512}

with array len determined as sizeof(vec) / sizeof(vec[0])

But for exact check of supported data types - there could be variants:

1. Using per-type feature test macroses: __V8SI16__, __V8UI16__,
__V8F16__, __V4SI32__, __V4UI32__, __V4F32__, __V2SI64__,
__V2F64__....
(I discovered at wikipedia - some ISA restrict underlying int size to
32bit without 64bit support).

2. Extend array for supported lengths to be 2d matrix of supported
vector size + underlying element type combination. This could use
NULL-terminated array to mark end if real values sequence. First
subarray represents vector sizes, while next subarrays each correspond
to value from first. Their elements are int fields, combining bitwidth
value with bit flags, representing if it's float/int and (for int)
signed/unsigned.

Though who knowes if eventually complex numbers could have chance to
appear in this list :D . Well, even without this this could be tricky
way.

3. There could be variation of 2nd way, representing per-type vector
sizes lists rather than per-vector-size data types. This could be more
practical, since algothythms would rather need available vector sizes
for specific data types, used inside.

As for relying for vector size subdivision when it has no
corresponding ISA support - I got only worse performance in this way.
Although I'm not sure, that it's not gcc bug: if there are 2
subvectors existing at the same time, than it could be just too much
SIMD registers used. While if they are processed in sequence, this
probably should not worsen performance (I never tried manual code
intrinsics).