question about attribute aligned for functions
Jeff Law
law@redhat.com
Sat Dec 1 00:12:00 GMT 2018
On 11/29/18 8:34 AM, Martin Sebor wrote:
>
> GCC does disallow decreasing the function alignment -- but only
> for functions that were already declared with a more restrictive
> one. Like this:
>
> Â __attribute__ ((aligned (4))) void f (void);
>
> Â __attribute__ ((aligned (2))) void f (void);
>
> Â warning: ignoring attribute âaligned (2)â because it conflicts with
> attribute âaligned (4)â
>
> It doesn't warn about going from the default (say 16 on i86)
> to something smaller, and it honors that lower alignment up
> to the supported minimum. It's probably worth clarifying in
> the manual. Let me propose something.
Please do. Thanks.
>
>>>>
>>>> Whether or not to warn in general if the alignment attribute is smaller
>>>> than the default may be subject to debate. I guess it depends on the
>>>> general intent that we'd find in real world codes.
>>>
>>> I would expect real world code to care about achieving at least
>>> the specified alignment.
>> If we only allow increasing, yes. At which point what do the values 0
>> or 1 realistically mean?
>
> If we only allowed increasing then both 0 and 1 would be
> meaningless.
>
>>
>> If we allow decreasing, then the user may be asking for a smaller
>> alignment to achieve better code density.
>
> Yes, that's definitely possible (I just opened pr88231 -
> aligned functions laid down inefficiently, as I noticed this
> doesn't work as well as it could and arguably should). But they
> can't get it if the target doesn't support it. In which case I
> think adding a new warning to point it out might be useful. At
> the same time, users wanting maximum density across all their
> targets shouldn't have to worry about what the minimum alignment
> is on each of them and hardwire different constants into
> the attribute. I think they should be able to specify 1 and
> have GCC round it up as necessary, with no warning. So I'd make
> the new warning off by default.
That seems like a better UI than forcing the user to know what their
target actually supports.
So, yea I think I'm in agreement with where you're going.
jeff
More information about the Gcc
mailing list