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. Segher
