[{"id":3685623,"web_url":"http://patchwork.ozlabs.org/comment/3685623/","msgid":"<afhtgiEw8zHnkoPe@gate>","list_archive_url":null,"date":"2026-05-04T09:57:22","subject":"Re: [COMMITTED] rs6000: Add -mcpu=future support and built-in gating\n infrastructure","submitter":{"id":134,"url":"http://patchwork.ozlabs.org/api/people/134/","name":"Segher Boessenkool","email":"segher@kernel.crashing.org"},"content":"Hi!\n\n(Who told you you could commit this?  I didn't see that happening.)\n\nOn Mon, May 04, 2026 at 02:38:30PM +0530, Kishan Parmar wrote:\n> This patch introduces support for the -mcpu=future option, intended to\n> enable experimental processor features that may or may not be included\n> in future Power processors. The option serves as a placeholder for\n> development and evaluation purposes, and may be renamed if a\n> corresponding processor is defined.\n\nIt adds a new CPU named \"future\", which is a stand-in for a CPU that may\nor may not eventually be created and released.\n\nIt does not add an option: we have had the -mcpu= option sice forever.\n\n> In addition, this change adds suppor for gating rs6000 built-ins using\n> a new target predicate \"future\", corresponding to -mcpu=future.\n\nThat is a very nasty generic name for such a non-generic thing.\n\n> This\n> extends rs6000-gen-builtins.cc and rs6000-builtin.cc to recognize\n> [future] as a valid predicate, allowing new built-ins defined in .bif\n> files to be conditionally enabled.\n\nSo it is a different thing from -mcpu=future even?  Huh.  What is a\nrealistic use case for it?\n\nI guess you want this to have builtins that are only valid with\n-mcpu=future in effect?  Then just say that please!\n\n> \t* config.gcc (powerpc*-*-*): Add support for supporting\n> \t--with-cpu=future.\n\nPlease make more factually correct changelog entries?  \"Add a \"future\"\nprocessor type\", or something like that.  And there is something you can\nhang that off on.  \"Add new RS6000_CPU (\"future\")\" or something?\n\n> @@ -5870,7 +5870,7 @@ case \"${target}\" in\n>  \t\t\t\teval \"with_$which=405\"\n>  \t\t\t\t;;\n>  \t\t\t\"\" | common | native \\\n> -\t\t\t| power[3456789] | power1[01] | power5+ | power6x \\\n> +\t\t\t| power[3456789] | power1[01] | future | power5+ | power6x \\\n>  \t\t\t| powerpc | powerpc64 | powerpc64le \\\n>  \t\t\t| rs64 \\\n>  \t\t\t| 401 | 403 | 405 | 405fp | 440 | 440fp | 464 | 464fp \\\n\nPlease keep things ordered.  \"future\" should come last.  Hrm, actually\npower5+ and power6x are the weird ones, I see.  Bah.  Maybe the list\ncould be reordered a bit so those make more sense, but urgh, it won't\never become really better.  A comment could make things clearer maybe?\n\n\nSegher","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org; dmarc=none (p=none dis=none)\n header.from=kernel.crashing.org","sourceware.org;\n spf=pass smtp.mailfrom=kernel.crashing.org","server2.sourceware.org;\n arc=none smtp.remote-ip=63.228.1.57"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g8HBp2ZyLz1y04\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 04 May 2026 19:57:52 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id B02C34BAE7DA\n\tfor <incoming@patchwork.ozlabs.org>; Mon,  4 May 2026 09:57:49 +0000 (GMT)","from gate.crashing.org (gate.crashing.org [63.228.1.57])\n by sourceware.org (Postfix) with ESMTP id 96A444BABF2C\n for <gcc-patches@gcc.gnu.org>; Mon,  4 May 2026 09:57:23 +0000 (GMT)","from gate.crashing.org (localhost [127.0.0.1])\n by gate.crashing.org (8.18.1/8.18.1/Debian-2) with ESMTP id 6449vM9Z2268370;\n Mon, 4 May 2026 04:57:22 -0500","(from segher@localhost)\n by gate.crashing.org (8.18.1/8.18.1/Submit) id 6449vMWn2268369;\n Mon, 4 May 2026 04:57:22 -0500"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org B02C34BAE7DA","OpenDKIM Filter v2.11.0 sourceware.org 96A444BABF2C"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 96A444BABF2C","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 96A444BABF2C","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777888643; cv=none;\n b=HSsrf8YgCM1sekAnZ6xDKYw6bvrRKMZTT5QZs5VV3PqCuNtzbZTN7KzzO88+NORRBsF+Xlm8UjvVadeIRm174y1n8do6gRcVE+4GXMkM3pzJtc1RVpxgucwUWRL2l9QWob8sPX/VgFIEF0nkYJL88FXfzoUcsQVpuI0L+9ttUUM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777888643; c=relaxed/simple;\n bh=XzXwq50IwS7lgjVmSvZVMRMPivRVDJ1fjf4E2Rer3Ps=;\n h=Date:From:To:Subject:Message-ID:MIME-Version;\n b=Nt1eZ+tBE5HG8uuGdYnjd5VV60yE7xkb+o4ehgElAeecrVssFaSeXNy7vPohlp9mNqWXOxyFjuhb92hlZguT8iHij182MLNkHh7YbAcoffApEwtanTvew8DJmRRKkDjjmWyZvH2HulY6PeVuvDcStBg27EsZNfUyhM77Yueda9g=","ARC-Authentication-Results":"i=1; server2.sourceware.org","X-Authentication-Warning":"gate.crashing.org: segher set sender to\n segher@kernel.crashing.org using -f","Date":"Mon, 4 May 2026 04:57:22 -0500","From":"segher@kernel.crashing.org","To":"Kishan Parmar <kishan@linux.ibm.com>","Cc":"meissner@linux.ibm.com, jskumari@linux.ibm.com, mmatti@linux.ibm.com,\n gcc-patches@gcc.gnu.org, avinashd@linux.ibm.com, vijay@linux.ibm.com","Subject":"Re: [COMMITTED] rs6000: Add -mcpu=future support and built-in gating\n infrastructure","Message-ID":"<afhtgiEw8zHnkoPe@gate>","References":"<20260504090830.3526306-1-kishan@linux.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260504090830.3526306-1-kishan@linux.ibm.com>","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]