This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR43814] Assume function arguments of pointer type are aligned.
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Maxim Kuvyrkov <maxim at codesourcery dot com>
- Cc: Tom de Vries <Tom_deVries at mentor dot com>, Tom de Vries <vries at codesourcery dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 19 Oct 2011 10:43:06 +0200
- Subject: Re: [PATCH, PR43814] Assume function arguments of pointer type are aligned.
- References: <4E787543.1090009@codesourcery.com> <CAFiYyc1-2tmJLz_Z+cWK2sk7Nsvjw7HFvu32BmVtMj0qYv++7Q@mail.gmail.com> <4E839DE5.4070709@mentor.com> <4E842BD6.9030102@mentor.com> <CAFiYyc0ydyddfVnaQgxyzzOxH4CoYtUDYezSAF7B3OiTH_XOEw@mail.gmail.com> <F1DF64C6-59AD-4A8E-A398-42A50CD9E5FF@codesourcery.com>
On Wed, Oct 19, 2011 at 1:58 AM, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
> On 29/09/2011, at 10:23 PM, Richard Guenther wrote:
>
>> On Thu, Sep 29, 2011 at 10:27 AM, Tom de Vries <Tom_deVries@mentor.com> wrote:
>
>> + ? ? ? ? ? ? ?&& SSA_NAME_IS_DEFAULT_DEF (expr)
>> + ? ? ? ? ? ? ?&& TREE_CODE (var) == PARM_DECL
>> + ? ? ? ? ? ? ?&& POINTER_TYPE_P (TREE_TYPE (var))
>> + ? ? ? ? ? ? ?&& TYPE_USER_ALIGN (TREE_TYPE (TREE_TYPE (var))))
>> + ? ? ? val = get_align_value (TYPE_ALIGN (TREE_TYPE (TREE_TYPE (var))),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TREE_TYPE (var), 0);
>>
>> I realize that the scope where this applies is pretty narrow (and thus
>> bad fallout is quite unlikely). ?But I suppose we should document
>> somewhere that GCC treats alignment attributes on parameters
>> more strict than say, on assignments.
>
> Richard, the intention here is for a follow up patch to change "&& TYPE_USER_ALIGN" to "&& (TYPE_USER_ALIGN || flag_assume_aligned_parameters)". ?I understand that you will probably not like the idea of adding flag_assume_aligned_parameters, but it wouldn't make such an option any less valuable for experienced users of GCC. ?For some users this option will the additional piece of rope to hang themselves; for others it will produce good benefits of better performance.
>
> [Disclaimer: I've put significant amount of my time into investigation of this problem and hate to see it all go to waste :-).]
It's not wasted, but using it as part of a bad solution isn't good either ;)
I do want a start to a more general solution that also will fix the ever present
wrong-code bugs on strict-align targets with respect to excessive alignment
we assume for them. This doesn't seem to be one, but instead it seems
to introduce more inconsistencies which is very bad.
What exact problems do you try to solve (I presume not the artificial
testcase in the PR)?
Thanks,
Richard.