This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] S/390: Improve storing asan frame_pc

> Am 03.07.2019 um 22:47 schrieb Richard Sandiford <>:
> 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 <>:
>>>>>> 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,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]