From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 0F6F43858D20 for ; Tue, 5 Mar 2024 15:09:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F6F43858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0F6F43858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709651369; cv=none; b=nqHyEypIqIyS7WJK68JmHii1iyj/bAUXziOK8JdnMLeDR4Uj4rlsQ+Lp2i/khIHIa+oe2cNaFunCwynwYwfJ5Zh1b3Ht2jVrYodnzTB61KUpi1LdOl+BTLJ4UDLtvx2hPWtcXp1qmO9DN5LKfpxvXXx8k/FsguU7zhr+B3//oDE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709651369; c=relaxed/simple; bh=S1d8GSD2dMG7FeUwYfSz+stVGl7y0W4FQ9sLwHJyCVA=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=rxF6YQQ5oY+FmPhOvZJxP09p3d5qgcOqcXozi9CkQxvPQ9VCGXYzXbyfhLyZmfDrAb+yzREqfNXPCu2EdLl0etSNF7yMwClgXOdawHWYWKIB85V8Bx+qUagr50ZMzq1+xyTOznPF1tLJKl/eWuyoGIZnfE4RpXQIn0AQdOg/+HU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709651367; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zWAavtvMEbvRx6x6V7qNEkSaQIXtlxxsXqSWgkk6aWk=; b=hUlGBFbQX2udNDt4w8LecPJqYHJ2cBe/LymoYtZz5XzN9S3tBpK5pwP5PjIHrAliI0ECE1 aQ0L+jYzquBd2V86O7LPM6AXgvJtJeYAc0v7yV4mX8p3yyY7y11hGic2ndN6aiNxaH3dOd dNxFMxzLvkLyd4WaV5lhjhIZ5yBaiqE= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-324-oQMS-feyMgqaFhGJfrMI5g-1; Tue, 05 Mar 2024 10:09:26 -0500 X-MC-Unique: oQMS-feyMgqaFhGJfrMI5g-1 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-787d2fab065so633213885a.3 for ; Tue, 05 Mar 2024 07:09:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709651365; x=1710256165; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zWAavtvMEbvRx6x6V7qNEkSaQIXtlxxsXqSWgkk6aWk=; b=u7FFxdsBzWOEtPk5iGoQgvwlaI5f86R7XFoCquVh2MWVPfpJ1pBwlILemoNkFZUsCl y2avaWF/7+o8GNdytmUz7jGXHK6jzwAg4xwx1bFkCwEBW2HUmsB7iasTiuVwaG+uCm3T keBr3DpI7Kk1fIloSvnzqTGeO8qQ58hB+k5C/2j5YhO6SGG9xKS/qzeKMt10v+52dI7P OHHmrx/2O+MXv5aia71IzIs+IPCqEsqlcIqddFRkZay5w06imBWEneAbx+3apeuGbOeT jcbjGvN0e6wTW+FxAXpquDzX96sdxxm9iTz7i+H12dagJrAczDclfEMQ5/DUyJxlDap9 Go5Q== X-Forwarded-Encrypted: i=1; AJvYcCU0EN6aHT4v9EPKe/t5fK80l3OsEUGbmyY0foQZ65Z/3TrySDWC/h9n3vPmshkq0QSbHghqye1id695XwfM6yY= X-Gm-Message-State: AOJu0YwMOeQ/ote3kj5BjzDCdeGQU/O82mOmetHliorWrby+iGSymdBW Gpa93IFNOOO7+YWt7aL3xP7KKzbAT69RFRAiL4IMdZgAXnB9quK5aFXwv1cUkE0n06XRCPbG7Nh s9rXRq4sytZlaj+KjTr/T875AZIIqNz2EeE048yViKtSg X-Received: by 2002:a05:620a:5e46:b0:787:da0e:36da with SMTP id ya6-20020a05620a5e4600b00787da0e36damr2237389qkn.33.1709651365712; Tue, 05 Mar 2024 07:09:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IHs/a6FIaWk7gTBpseqtUIOdeZs/3ykhoPDPCZUn4mfP4bnjwjUpoHFoEAJ+2jpvx8CPKLN/A== X-Received: by 2002:a05:620a:5e46:b0:787:da0e:36da with SMTP id ya6-20020a05620a5e4600b00787da0e36damr2237355qkn.33.1709651365397; Tue, 05 Mar 2024 07:09:25 -0800 (PST) Received: from t14s.localdomain (c-76-28-97-5.hsd1.ma.comcast.net. [76.28.97.5]) by smtp.gmail.com with ESMTPSA id vz20-20020a05620a495400b007881557e9a5sm3747665qkn.23.2024.03.05.07.09.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 07:09:24 -0800 (PST) Message-ID: <997ddb068ca13f755accd03f38141e56c87b84a7.camel@redhat.com> Subject: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features) From: David Malcolm To: Antoni Boucher , jit@gcc.gnu.org, gcc-patches@gcc.gnu.org Cc: Iain Buclaw , Arthur Cohen Date: Tue, 05 Mar 2024 10:09:23 -0500 In-Reply-To: <6050c91ae34a2cdaeebd79ada9e2b9ffaf881e21.camel@zoho.com> References: <8b0199d9835f568b7bcde41bf9432c21f604e489.camel@zoho.com> <755705e37731c4fbc3ab7eb1a96d8df0147bb002.camel@redhat.com> <6050c91ae34a2cdaeebd79ada9e2b9ffaf881e21.camel@zoho.com> User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote: > Hi. > See answers below. >=20 > On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote: > > On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote: > > > Hi. > > > This patch adds support for getting the CPU features in libgccjit > > > (bug > > > 112466) > > >=20 > > > There's a TODO in the test: > > > I'm not sure how to test that gcc_jit_target_info_arch returns > > > the > > > correct value since it is dependant on the CPU. > > > Any idea on how to improve this? > > >=20 > > > Also, I created a CStringHash to be able to have a > > > std::unordered_set. Is there any built-in way of > > > doing > > > this? > >=20 > > Thanks for the patch. > >=20 > > Some high-level questions: > >=20 > > Is this specifically about detecting capabilities of the host that > > libgccjit is currently running on? or how the target was configured > > when libgccjit was built? >=20 > I'm less sure about this part. I'll need to do more tests. >=20 > >=20 > > One of the benefits of libgccjit is that, in theory, we support all > > of > > the targets that GCC already supports.=C2=A0 Does this patch change > > that, > > or > > is this more about giving client code the ability to determine > > capabilities of the specific host being compiled for? >=20 > This should not change that. If it does, this is a bug. >=20 > >=20 > > I'm nervous about having per-target jit code.=C2=A0 Presumably there's = a > > reason that we can't reuse existing target logic here - can you > > please > > describe what the problem is.=C2=A0 I see that the ChangeLog has: > >=20 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* config/i386/i386-ji= t.cc: New file. > >=20 > > where i386-jit.cc has almost 200 lines of nontrivial code.=C2=A0 Where > > did > > this come from?=C2=A0 Did you base it on existing code in our source > > tree, > > making modifications to fit the new internal API, or did you write > > it > > from scratch?=C2=A0 In either case, how onerous would this be for other > > targets? >=20 > This was mostly copied from the same code done for the Rust and D > frontends. > See this commit and the following: > https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3Db1c06fd9723453dd2b2ec= 306684cb806dc2b4fbb > The equivalent to i386-jit.cc is there: > https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D22e3557e2d52f129f2bbf= dc98688b945dba28dc9 [CCing Iain and Arthur re those patches; for reference, the patch being discussed is attached to : https://gcc.gnu.org/pipermail/jit/2024q1/001792.html ] One of my concerns about this patch is that we seem to be gaining code that's per-(frontend x config) which seems to be copied and pasted with a search and replace, which could lead to an M*N explosion. Is there any real difference between the per-config code for the different frontends, or should there be a general "enumerate all features of the target" hook that's independent of the frontend? (but perhaps calls into it). Am I right in thinking that (rustc with default LLVM backend) has some set of feature strings that both (rustc with rustc_codegen_gcc) and gccrs are trying to emulate? If so, is it presumably a goal that libgccjit gives identical results to gccrs? If so, would it be crazy for libgccjit to consume e.g. config/i386/i386-rust.cc ? Dave >=20 > >=20 > > I'm not at expert at target hooks (or at the i386 backend), so if > > we > > do > > go with this approach I'd want someone else to review those parts > > of > > the patch. > >=20 > > Have you verified that GCC builds with this patch with jit *not* > > enabled in the enabled languages? >=20 > I will do. >=20 > >=20 > > [...snip...] > >=20 > > A nitpick: > >=20 > > > +.. function:: const char * \ > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 gcc_jit_target_info_arch (gcc_jit_target_info > > > *info) > > > + > > > +=C2=A0=C2=A0 Get the architecture of the currently running CPU. > >=20 > > What does this string look like? > > How long does the pointer remain valid? >=20 > It's the march string, like "znver2", for instance. > It remains valid until we free the gcc_jit_target_info object. >=20 > >=20 > > Thanks again; hope the above makes sense > > Dave > >=20 >=20