> Am 03.07.2019 um 22:47 schrieb Richard Sandiford <richard.sandif...@arm.com>: > > Segher Boessenkool <seg...@kernel.crashing.org> writes: >> On Tue, Jul 02, 2019 at 03:55:56PM +0200, Ilya Leoshkevich wrote: >>>> Am 02.07.2019 um 15:39 schrieb Jakub Jelinek <ja...@redhat.com>: >>>> On Tue, Jul 02, 2019 at 03:33:28PM +0200, Ilya Leoshkevich wrote: >>>>>> Am 02.07.2019 um 15:19 schrieb Segher Boessenkool >>>>>> <seg...@kernel.crashing.org>: >>>>>> >>>>>> 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 >>>>>>> >>>>>>> There already is FUNCTION_BOUNDARY for something similar, which fits in >>>>>>> well with STACK_BOUNDARY, PARM_BOUNDARY, many more *_BOUNDARY. I >>>>>>> realise >>>>>>> you may prefer a hook, but as long as we aren't getting rid of all the >>>>>>> other macros, what's the point? >>>>>> >>>>>> And maybe LABEL_BOUNDARY is bettter for this than INSN_BOUNDARY as well? >>>>> >>>>> Can’t we just use FUNCTION_BOUNDARY then? >>>>> I think .LASANPC is always emitted at the beginning of a function. >>>> >>>> Isn't e.g. the hotpatch sequence emitted before it? >>> >>> You are right, with -fpatchable-function-entry it’s moved. >>> >>> 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.
The new value should definitely be consistent with LABEL_ALIGN. Still, it is supposed to be applied primarily to trees, not rtxes, and I think that in this regard it groups nicer with *_BOUNDARY macros. Best regards, Ilya
