From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95341 invoked by alias); 23 Apr 2019 10:12:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 95329 invoked by uid 89); 23 Apr 2019 10:12:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_ASCII_DIVIDERS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:CAMfHzO, enter, HContent-Transfer-Encoding:8bit X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Apr 2019 10:12:41 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DFEAAAD05; Tue, 23 Apr 2019 10:12:38 +0000 (UTC) Subject: Re: [WIP][RFC] split of i386.c To: =?UTF-8?Q?Jan_Hubi=c4=8dka?= Cc: Uros Bizjak , Jeff Law , Eric Gallager , GCC Development , "H.J. Lu" , Jakub Jelinek References: <28098c4f-99a6-1004-90d4-82fa2f7eaa9c@redhat.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <3b9be0ba-2d68-573f-3b91-3487b1fc6f66@suse.cz> Date: Tue, 23 Apr 2019 10:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00235.txt.bz2 On 4/18/19 1:56 PM, Jan Hubička wrote: > Hello, > the patch looks good to me. I think in the copyright comment you want to > copy all the years of copyright of original i386.c since the code is not > from 2019. also there are missing licence comments in the .h files. Thanks for review. Yes, I'll copy the comment in all newly created .h and .c. Btw. David pointed out that newly created C++ files should have .cc extension. Do we want to do so in case of split? > I would probably put the bigger machine specific optimization passes into > separate files (these have noreason to be globbed). Let's do this in a next step. The file i386-features.c is quite small right now. > It will also make it more obvoius that i386 has couple of optimization > passes. Why scalar chain needs to be exported? I put that into an anonymous namespace. > > I think it would be nice to commit the patch early stage1 :) > Honza Thanks, I'm planning to rebase that once we enter a new stage1. Martin > > > > On Mon, Mar 18, 2019 at 3:19 PM Martin Liška wrote: > >> Hi. >> >> I'm sending first version of the split, which has following >> statistics: >> >> gcc/config.gcc | 5 +- >> gcc/config/i386/i386-builtins.c | 2563 ++++++++++ >> gcc/config/i386/i386-builtins.h | 314 ++ >> gcc/config/i386/i386-expand.c | 19868 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> gcc/config/i386/i386-expand.h | 40 + >> gcc/config/i386/i386-features.c | 2854 +++++++++++ >> gcc/config/i386/i386-features.h | 179 + >> gcc/config/i386/i386-options.c | 3678 ++++++++++++++ >> gcc/config/i386/i386-options.h | 76 + >> gcc/config/i386/i386-protos.h | 4 - >> gcc/config/i386/i386.c | 62939 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> gcc/config/i386/i386.h | 9 + >> gcc/config/i386/t-i386 | 16 + >> 13 files changed, 46542 insertions(+), 46003 deletions(-) >> >> The newly created files have following content: >> - i386-builtins.c - builtin-in handling, __builtin_cpu_is and >> __builtin_cpu_supports, target pragma handling >> - i386-expand.c - all scalar and vector expansion code >> - i386-features.c - contains isolated target features - vzerotoupper, stv, >> cet, rpad, multi-versioning, >> - i386-options.c - option related functions, target attribute handling >> >> Now the i386.c file is down in size: >> 23038 gcc/config/i386/i386.c >> >> Question is whether I should continue or not? Remaining content of the >> file is made of >> various costing functions, print_reg*, various target hooks, coff, ms_abi, >> retpolines, >> output-functions, etc. I don't see any further split point which should >> define a new >> file. >> >> Patch: >> https://drive.google.com/file/d/1SiNcR35DHMNBumyg5ltbOozEJ5Q0ajKn/view?usp=sharing >> >> Thoughts? >> Thanks, >> Martin >>