From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by sourceware.org (Postfix) with ESMTPS id 63E2F3858CD1; Sun, 10 Mar 2024 11:05:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 63E2F3858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=gdcproject.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gdcproject.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 63E2F3858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=80.241.56.171 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710068757; cv=none; b=AuemMu2shqLkw7Tftg9lw+RemI2jSNkm+H0VgEvEOG8vuO0XKL5t+OnlPA123ksunHA9iPxWvUvH+YneoZT5ca8cdWHDGHnA2CwjGdLcY3rg7LqG8Ii4mLujc3T4sgGWfJbgrtME6UCJ9HYWvrmq2tJ+tmu/zZT6+0GtudygEKg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710068757; c=relaxed/simple; bh=U6Cd143IiAbQIzy7LThbKJiOUOpNgXAAuiouHksiYMI=; h=DKIM-Signature:Date:From:Subject:To:MIME-Version:Message-Id; b=CcQqX1kzZmNwDP4/yl5PEqezHQdR2n+Tbf5Bilf8TQStSjVfYkPo7YYR4Xgl4GxZSX5pySerIdd2jwXtSeGBmLgo8m1z5iZ2GGUS3tk8dC7maCJcDIwQRuFGlPfiyaC/d2BB5eliPUWS/IJV9Uq6R/LagKRQuaJ3RGVOSsgfYNk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4TsxsX102Jz9sS2; Sun, 10 Mar 2024 12:05:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gdcproject.org; s=MBO0001; t=1710068752; 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=bsSzF+EgOQW/GK10/2k1907tDBUWMT3ZXljz5IgWub4=; b=Rfc3pr3Mq6o/l2OYiklrQwjDc8Uuy7BwB7aafHhMZ/bPAhL8+BTNO54DxZ1VPUGw+qtv+H 5cx/UlszSCcyZQNcDYhrBlwmhcI1xf11ZjpJqys5r0cqZ7ka0PLdeVm9wdOthgd8qh7wpd hzxVyMzMNv5NRl7J5VyRSI9uyNjCEdi76tr2wRhmCDG9QiCGF7y1Qh/TNHMGM4HKZ5SVeO Nvoz11IY/1+PPPH0Gc8lMyVv8GSgbB2KwuTiPdTaeqN8lLr2AqW+XdRak2ZHZtFasFuO7W Oh6p+gpUuocR1RKk0BFMqc/P8I+xBPW26c9vOUd0/lJi761bvZ+99B2dgh92BQ== Date: Sun, 10 Mar 2024 12:05:47 +0100 From: Iain Buclaw Subject: Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features) To: Antoni Boucher , David Malcolm , gcc-patches@gcc.gnu.org, jit@gcc.gnu.org Cc: Arthur Cohen References: <8b0199d9835f568b7bcde41bf9432c21f604e489.camel@zoho.com> <755705e37731c4fbc3ab7eb1a96d8df0147bb002.camel@redhat.com> <6050c91ae34a2cdaeebd79ada9e2b9ffaf881e21.camel@zoho.com> <997ddb068ca13f755accd03f38141e56c87b84a7.camel@redhat.com> In-Reply-To: <997ddb068ca13f755accd03f38141e56c87b84a7.camel@redhat.com> MIME-Version: 1.0 Message-Id: <1710063672.3qlr6ik163.astroid@pulse.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,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: Excerpts from David Malcolm's message of M=C3=A4rz 5, 2024 4:09 pm: > 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-j= it.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 othe= r >> > 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=3Db1c06fd9723453dd2b2e= c306684cb806dc2b4fbb >> The equivalent to i386-jit.cc is there: >> https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D22e3557e2d52f129f2bb= fdc98688b945dba28dc9 >=20 > [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 ] >=20 > 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. >=20 That's certainly the case with the configure/make rules. Itself I think is copied originally from the {cpu_type}-protos.h machinery. It might be worth pointing out that the c-family of front-ends don't have separate headers because their per-target macros are defined in {cpu_type}.h directly - for better or worse. > 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). >=20 As far as I understand, the configure parts should all be identical between tm_p, tm_d, tm_rust, ..., so would benefit from being templated to aid any other front-ends adding in their own per target hooks. > 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 ? I don't know whether libgccjit can just pull in directly the implementation of the rust target hooks here. The per-frontend target hooks usually also make use of code specific to that front-end - TARGET_CPU_CPP_BUILTINS and others can't be used by a non-c-family front-end without adding a plethora of stubs, for example. Whether or not libgccjit wants to give identical information as as rust I think is a decision for you as the maintainer of its API. Iain.