[RFC] Convert TYPE_ALIGN_OK into an TYPE_LANG_FLAG
Richard Biener
rguenther@suse.de
Fri Jul 8 07:39:00 GMT 2016
On Thu, 7 Jul 2016, Bernd Edlinger wrote:
> Hi,
>
> this patch re-factors the TYPE_ALIGN_OK into a new TYPE_LANG_FLAG,
> and removes one of the 9 parameters of get_inner_reference. It therefore
> simplifies the middle end slightly.
>
> It is quite a while ago, when I last proposed a similar patch, which focused
> only on get_inner_referene. According to Eric's comment, I extended
> it to cover also the TYPE_ALIGN_OK which is only in use by Ada today.
>
> As it turns out, the middle end does not need the TYPE_ALIGN_OK,
> but it cannot be completely removed, because Ada reads it back again,
> and it plays therefore the role of an additional TYPE_LANG_FLAG.
>
> Removing the use of TYPE_ALIGN_OK in the pa backend can't have any
> side-effect, because when I look at the definition of mark_reg_pointer
> the align parameter only has an influence on REGNO_POINTER_ALIGN.
> Because that is never used by the pa backend, the only other place where
> it is used in the middle end is in rtlanal.c, where it is only evaluated for
> stack_pointer_rtx, frame_pointer_rtx, and arg_pointer_rtx, but these
> registers do not hold arbitrary pointer values.
>
>
> Boot-strapped and Reg-tested on arm-linux-gnueabihf and x86_64-pc-linux.
> I have also built cross-compilers for hppa and mips targets.
> Is it OK for trunk?
The discussion last time ended with a mail from you that TYPE_ALIGN_OK
is "somehow" relevant in the Ada FE, but I didn't see any feedback
from Eric nor results from the "extended" testing we wanted to perform.
So is there any news on that front? That said, if we can remove
TYPE_ALIGN_OK setting from the Ada frontend then this patch becomes
much more obvious (and no need to find a lang-specific place for
TYPE_ALIGN_OK).
Richard.
More information about the Gcc-patches
mailing list