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 819CF3875450 for ; Wed, 26 Jun 2024 21:55:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 819CF3875450 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 819CF3875450 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=1719438928; cv=none; b=Ft/SW6PX+3+lJJeutPjkQzFxqwps8NYVC1MQwxFqV6q7axRkUeSf5QZ24OKKnHyubc4gRqKs8uyiqtnKWw4Iv6LMzI5hpU4v32cKrX6mH0ia+IogirVdW+t7Myd8NDoSsP5veyI8D5aKqKKv7TyqTL6i0aqW9kFYHu28xjAo5w4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719438928; c=relaxed/simple; bh=DzdPiw7HDdEgNtrmW94mjBkbST9Pp/A66XH5iVQB4LY=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=lZ9JA/+EboGVFucs6S4w4zUB2RATWUeOUnfdCid+bHYhDgwRCbD/0ooFiDLTmBMZ2DG53/E50UwsZbKCkTRtl8v33NujH4FtmTn0VpqAeSmD+kwbb+8WUrlU4D5WKxJ695q5IUFoaHKe1NgmmyP6IcI9DbkPw4f3HqFUJmSkox8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1719438926; 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=ZaH/Hkslvg8Gm9nknPa74YvAWF5chTjD+ezjK8pY+5k=; b=i2mnvdChAiLoxuIp2zlccXyLQDarbR1kcigxr/Q3RywS8cn69CHie9puPr0d+Hbp87S2eK 05o0bwhYxRHSmyc9BrZeZgkvBdTU+JKnzTcNIZWonntUYHe2MriAKRZ54KfXNui7kLc1w+ PIwu7kwCJzdnEXDDPtL230Jx6ruTrks= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-58-4EYM7Z1-MXW55nsVKuKgrw-1; Wed, 26 Jun 2024 17:55:23 -0400 X-MC-Unique: 4EYM7Z1-MXW55nsVKuKgrw-1 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-79cf8cea82bso201028485a.1 for ; Wed, 26 Jun 2024 14:55:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719438923; x=1720043723; 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=ZaH/Hkslvg8Gm9nknPa74YvAWF5chTjD+ezjK8pY+5k=; b=b+dKnAItp9Vv731YTPYSJTfY1EAUy9vDZW5woPp7pq/hT6WU16rR21KfNwgwxLcf3Z N1ZN3rrkenWs0tkOkwGo+Zy7eFjT8YUQaCD7Rqs06cb++W9so1BuLKfXs2VUUOl+DEmw DTFANIZA3Ngt0PmTmJS56ZYfgIb7AGCsWf9HfdILXQPF5BCY0gFwq0rdTWAHMMNoYRte dn3YZJBhG0NIX5PQTDqEtt00jtlLn8Jn4YAxf3m4Xvnh/xM7ZD8CwFTvqS+UNDUq+Lhi OdBXMch9JdbAbcuR2TQj6w/WqqSYpzTdlLzVfCrl4w/jCMkA2DIq8kYyXBdId42t59Dg e9nA== X-Forwarded-Encrypted: i=1; AJvYcCVnAXIQXh8ohorNXPhmpyIlFkijzTblznhXJM/UWgMwmkp31Eo3OimpxnRyX0fawDRi//ll5BhRyMjX+AQ/8gJ8KeEIpvCsPA== X-Gm-Message-State: AOJu0YxQogevqX4hEvzHadbkG0ZJsxhEHTfSE69SXAF6BkNmh5O5jbIz /GX8IHxaXabrL6Ttq76YDKoApman98Bkyg39myGxtInogX2ddJ6Tr+TX8+D8uf578mNefO1/dTa 6hdiMnJma45s5uQVSnhGgh4FD7eh1dtVBOEMmP1/3URMs3KXbWqYRx74= X-Received: by 2002:a05:620a:258b:b0:797:9a2c:7301 with SMTP id af79cd13be357-79bdec53274mr1848441685a.6.1719438923443; Wed, 26 Jun 2024 14:55:23 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEPIQ5aCEMp257QXSsd8f6p5Wbp8ns7La5slNvDAaet9bsSXu6Cz5OMZV1vgrtS4RiLjpaRKQ== X-Received: by 2002:a05:620a:258b:b0:797:9a2c:7301 with SMTP id af79cd13be357-79bdec53274mr1848439885a.6.1719438923090; Wed, 26 Jun 2024 14:55:23 -0700 (PDT) Received: from t14s.localdomain (c-76-28-97-5.hsd1.ma.comcast.net. [76.28.97.5]) by smtp.gmail.com with ESMTPSA id af79cd13be357-79bce91dae3sm532567485a.88.2024.06.26.14.55.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Jun 2024 14:55:22 -0700 (PDT) Message-ID: <879997c7b22053595a52a19cb528c79a84908e17.camel@redhat.com> Subject: Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features) From: David Malcolm To: Iain Buclaw , Antoni Boucher , gcc-patches@gcc.gnu.org, jit@gcc.gnu.org Cc: Arthur Cohen Date: Wed, 26 Jun 2024 17:55:21 -0400 In-Reply-To: <1710063672.3qlr6ik163.astroid@pulse.none> References: <8b0199d9835f568b7bcde41bf9432c21f604e489.camel@zoho.com> <755705e37731c4fbc3ab7eb1a96d8df0147bb002.camel@redhat.com> <6050c91ae34a2cdaeebd79ada9e2b9ffaf881e21.camel@zoho.com> <997ddb068ca13f755accd03f38141e56c87b84a7.camel@redhat.com> <1710063672.3qlr6ik163.astroid@pulse.none> 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=-3.8 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 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 Sun, 2024-03-10 at 12:05 +0100, Iain Buclaw wrote: > 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/i38= 6-jit.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 sourc= e > > > > 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=3Db1c06fd9723453dd2= b2ec306684cb806dc2b4fbb > > > The equivalent to i386-jit.cc is there: > > > https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D22e3557e2d52f129f= 2bbfdc98688b945dba28dc9 > >=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=C2=A0] > >=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 >=20 > That's certainly the case with the configure/make rules. Itself I > think > is copied originally from the {cpu_type}-protos.h machinery. >=20 > 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. >=20 > > 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 >=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. >=20 > > 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?=C2=A0 If so, is it presumably a goal that > > libgccjit gives identical results to gccrs?=C2=A0 If so, would it be > > crazy > > for libgccjit to consume e.g. config/i386/i386-rust.cc ? >=20 > I don't know whether libgccjit can just pull in directly the > implementation of the rust target hooks here. Sorry for the delay in responding. I don't want to be in the business of maintaining a copy of the per- target code for "jit", and I think it makes sense for libgccjit to return identical information compared to gccrs. So I think it would be ideal for jit to share code with rust for this, rather than do a one-time copy-and-paste followed by a ongoing "keep things updated" treadmill. Presumably there would be Makefile.in issues given that e.g. Makefile has i386-rust.o listed in: # Target specific, Rust specific object file RUST_TARGET_OBJS=3D i386-rust.o linux-rust.o One approach might be to move e.g. the i386-rust.cc code into, say, a i386-rust-and-jit.inc file and #include it from i386-rust.cc and i386- jit.cc (with a similar approach for other targets) Antoni, Arthur, would you each be OK with that? > =C2=A0 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. >=20 > 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. Also a question for Antoni and Arthur: is that desirable for the two gcc rust approaches? Thanks Dave