Re: question about attribute aligned for functions

[Jeff Law <law at redhat dot com>]

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