From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id D4D363858D1E for ; Tue, 3 Jan 2023 18:28:50 +0000 (GMT) Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 739D028088F; Tue, 3 Jan 2023 19:28:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1672770529; 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: in-reply-to:in-reply-to:references:references; bh=vXvfrHJeiiNZo3K0yxbM78z81y9bzoeyfJjQXcBdHmE=; b=XCj9eVRTllt3fXg5iVsbWlcKmBX5e4AU1Lje0AV60NvueQGbh/cE6nGFYra0EE0Xa1RtnC aOMlptmvkhJ3WMiEulUS031aZayPXQ6KeZtLuSsOKv47Q4q8mOgrNYDPh+hxXZOZCAVpDE P/EefLVdb2wvd+/7jNqIVvCAhsIp7ss= Date: Tue, 3 Jan 2023 19:28:49 +0100 From: Jan Hubicka To: Alexander Monakov Cc: "Joshi, Tejas Sanjay" , "gcc-patches@gcc.gnu.org" , "Kumar, Venkataramanan" Subject: Re: [PATCH][X86_64] Separate znver4 insn reservations from older znvers Message-ID: References: <8e489785-b181-fbcf-e029-cd75796a6f28@ispras.ru> <27b06e9f-1e80-585d-624e-6f50475a5aa8@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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 Tue, 3 Jan 2023, Jan Hubicka wrote: > > > > * gcc/common/config/i386/i386-common.cc (processor_alias_table): > > > Use CPU_ZNVER4 for znver4. > > > * config/i386/i386.md: Add znver4.md. > > > * config/i386/znver4.md: New. > > OK, > > thanks! > > Honza, I'm curious what are your further plans for this, you mentioned > merging znver4.md back in znver.md if I recall correctly? I was looking into that over Christmas (and it was also reason for my first pass through where I was asking for various differences). There are number of small divergences between znver.md and znver4.md that seem to make the merged automaton bigger than having two automatons. So merging both meaningfuly would mean modifying znver1-3 model or znver4 models. With Tejas I think we mostly verified that the areas znver4 modes is different from znver1-3 are correct for znver4 and sometimes also for znver3 (for example the branching unit is present already there but not bodelled). Splitting znver1-3 and 4 is definitly not optimal. However given the time constrains and desire to not break znver1-3 I think going with znver4.md is good option at least for GCC12/13. Overall I am not sure how beneficial the model overall is: since we schedule on BB basis and model CPU as in-order with no register renaming, the scheduler has rarely chance to fill most of execution units and de-facto optimizes for wastly different CPU than reality is). We get noticebale SPEC perfomance boost for -fschedule-insns2 but it seems to be mostly for scheduling for latencies. LLVM's model seems to do more than we do, but comparing both compilers I was not really able to tell if either of them get noticeable benefit from the actual model of reservation units (and not only latencies). I would welcome toughts/ideas/measurements on this. Honza > > Alexander