From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29610 invoked by alias); 3 Jul 2019 20:47:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 28962 invoked by uid 89); 3 Jul 2019 20:47:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=54AM, label_boundary, 54am, 16am X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Jul 2019 20:47:55 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 251FC2B; Wed, 3 Jul 2019 13:47:53 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.39]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4EFC13F703; Wed, 3 Jul 2019 13:47:52 -0700 (PDT) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool ,Ilya Leoshkevich , Jakub Jelinek , GCC Patches , krebbel@linux.ibm.com, richard.sandiford@arm.com Cc: Ilya Leoshkevich , Jakub Jelinek , GCC Patches , krebbel@linux.ibm.com Subject: Re: [PATCH] S/390: Improve storing asan frame_pc References: <20190702085154.26981-1-iii@linux.ibm.com> <20190702130216.GI18316@gate.crashing.org> <20190702131957.GJ18316@gate.crashing.org> <3CC32047-1B4E-46E5-B3DE-B53B870CD565@linux.ibm.com> <20190702133935.GN815@tucnak> <89059C46-E9E7-4689-8241-C251148EABC3@linux.ibm.com> <20190702142623.GL18316@gate.crashing.org> Date: Wed, 03 Jul 2019 21:49:00 -0000 In-Reply-To: <20190702142623.GL18316@gate.crashing.org> (Segher Boessenkool's message of "Tue, 2 Jul 2019 09:26:23 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-07/txt/msg00297.txt.bz2 Segher Boessenkool writes: > On Tue, Jul 02, 2019 at 03:55:56PM +0200, Ilya Leoshkevich wrote: >> > Am 02.07.2019 um 15:39 schrieb Jakub Jelinek : >> > On Tue, Jul 02, 2019 at 03:33:28PM +0200, Ilya Leoshkevich wrote: >> >>> Am 02.07.2019 um 15:19 schrieb Segher Boessenkool : >> >>>=20 >> >>> On Tue, Jul 02, 2019 at 08:02:16AM -0500, Segher Boessenkool wrote: >> >>>> On Tue, Jul 02, 2019 at 10:51:54AM +0200, Ilya Leoshkevich wrote: >> >>>>> +#undef TARGET_INSN_ALIGNMENT >> >>>>> +#define TARGET_INSN_ALIGNMENT 16 >> >>>>=20 >> >>>> There already is FUNCTION_BOUNDARY for something similar, which fit= s in >> >>>> well with STACK_BOUNDARY, PARM_BOUNDARY, many more *_BOUNDARY. I r= ealise >> >>>> you may prefer a hook, but as long as we aren't getting rid of all = the >> >>>> other macros, what's the point? >> >>>=20 >> >>> And maybe LABEL_BOUNDARY is bettter for this than INSN_BOUNDARY as w= ell? >> >>=20 >> >> Can=E2=80=99t we just use FUNCTION_BOUNDARY then? >> >> I think .LASANPC is always emitted at the beginning of a function. >> >=20 >> > Isn't e.g. the hotpatch sequence emitted before it? >>=20 >> You are right, with -fpatchable-function-entry it=E2=80=99s moved. >>=20 >> So, I guess I should stick with the current approach. >> I could change TARGET_INSN_ALIGNMENT hook to INSN_BOUNDARY macro if that >> would better match the current design. I would still call it INSN, and >> not LABEL, because LABEL can refer to data. > > On some archs LABEL_BOUNDARY can be bigger than INSN_BOUNDARY (just like > FUNCTION_BOUNDARY can be even bigger, like on 390 :-) ) > > Either will work for your purposes afaics. > > LABEL in RTL is always a CODE_LABEL I think? Maybe CODE_LABEL_BOUNDARY > would make it clearer, it's not like a short name for this is useful > anyway. IIUC the new value is effectively a mandatory/guaranteed minimum value of align_labels/LABEL_ALIGN that applies even in blocks optimized for size. So IMO sticking with *_ALIGNMENT would be better. Thanks, Richard