From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 73DED385772A; Tue,  9 Jan 2024 08:43:24 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 73DED385772A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1704789805;
	bh=eqh9DYRnTp5shKSQfoOhO8tJQoWnQFCQDrIvIur7Zak=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=tqr/u07wA9XQwq8INb0Mm1HlCTrmWHig8pOFCEeXZI1hSWbWbWngtRvXTjcZv0ZSV
	 sHgNVopsrOVL7Q4+g06DUeUNsYETgAVX27iyFP2WN5tIM/NOJGUkS7KfdXWoqrOgGE
	 FA5DrpGHC0ZCIBXrfmaDp2oS48QvpS7x9Gsrzu5c=
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/113288] [i386] Missing #define for -mavx10.1-256 and
 -mavx10.1-512
Date: Tue, 09 Jan 2024 08:43:21 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113288-4-sP7PpW1PjD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113288-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113288-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113288

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The(In reply to Haochen Jiang from comment #3)
> Adding them are quite straightforward.

I guess so. Note: this PR is about the #define in gcc/config/i386, only.

> But I am not quite sure how the whole
> libgomp patch works.

OpenMP has selectors which permits to choose different functions or OpenMap
directives. Several can be evaluated at compile time , some only at runtime.

example (syntax probably not completely right):
 ... match(implementation=3D{arch(x86_64),isa(sse4)})

Here, it can be evaluated at compile time which is done via the function=20

TARGET_OMP_DEVICE_KIND_ARCH_ISA

For some, runtime checks are more useful and I am also not sure whether
something like cpuid would make more sense here (in general and especially =
for
the run-time selector).

But that's a separate issue to this PR.

> Is the patch attempt to check whether it is a perfect match for each ISA
> detected from a hardware? If that is the case, we need them to be added.
> BTW, under this scenario, no need to add an if clause for macro __EVEX512=
__
> and __EVEX256__ in that patch since those two are not true ISAs.

Something like that. It is also more for completeness and consistency.

For OpenMP we just state:
https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Context-Selectors.html

which is rather generic for i386/x86_64. We cpuld do less, but the target h=
ook
made it easy to support all of them... I don't think anyone will use
avx10.1-256 as isa context selector with OpenMP.=