Evgeny Karpov <evgeny.kar...@microsoft.com> writes:
>> Wednesday, October 23, 2024
>> Richard Sandiford <richard.sandif...@arm.com> wrote:
>>
>>> Or, even if that does work, it isn't clear to me why patching
>>> ASM_OUTPUT_ALIGNED_LOCAL is a complete solution to the problem.
>>
>> This patch reproduces the same code as it was done without declaring
>> ASM_OUTPUT_ALIGNED_LOCAL.
>> ASM_OUTPUT_ALIGNED_LOCAL is needed to get the alignment value and handle it
>> when it is bigger than BIGGEST_ALIGNMENT.
>> In all other cases, the code is the same.
>>
>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/varasm.cc;h=c2540055421641caed08113d92dbeff7ffc09f49;hb=refs/heads/master#l2137
>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/varasm.cc;h=c2540055421641caed08113d92dbeff7ffc09f49;hb=refs/heads/master#l2233
>
> Does this information provide more clarity on ASM_OUTPUT_ALIGNED_LOCAL usage?
> If not, this patch will be dropped as a low priority, and FFmpeg, which
> requires this change, will be patched
> to avoid using alignment higher than 16 bytes on AArch64.
Hmm, I see. I think this is surprising enough that it would be worth
a comment. How about:
/* Since the assembly directive only specifies a size, and not an
alignment, we need to follow the default ASM_OUTPUT_LOCAL behavior
and round the size up to at least a multiple of BIGGEST_ALIGNMENT bits,
so that each uninitialized object starts on such a boundary.
However, we also want to allow the alignment (and thus minimum size)
to exceed BIGGEST_ALIGNMENT. */
But how does using a larger size force the linker to assign a larger
alignment than BIGGEST_ALIGNMENT? Is there a second limit in play?
Or does this patch not guarantee that the ffmpeg variable gets the
alignment it wants? Is it just about suppresing the error?
If it's just about suppressing the error without guaranteeing the
requested alignment, then, yeah, I think patching ffmpeg would
be better. If the patch does guarantee the alignment, then the
patch seems ok, but I think the comment should explain how, and
explain why BIGGEST_ALIGNMENT isn't larger.
Thanks,
Richard
