On 07/07/2016 08:53 AM, 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.
My recollection of REGNO_POINTER_ALIGN is that it exists primarily to
allow the backends to emit better code in their block move/block zero
patterns. It may also allow for removal of redundant masking,
particularly for the alpha as we can track low order zero/nonzero bits
in pointers.
The middle end's expander code wasn't ever really made aware of
REGNO_POINTER_ALIGN -- it was primarily queried by the target expander code.
In other words, not having accurate REGNO_POINTER_ALIGN should never be
a correctness issue, just a potential performance issue. Furthermore,
if the backend isn't explicitly using REGNO_POINTER_ALIGN, then it's
highly unlikely that losing that information is ever going to be noticed
for block moves/initialization. Which just leaves the uses for removing
masking of low order bits in pointers, which doesn't really come up on
the PA often enough to matter. So I see no issues with losing the data
on the PA.
So I'm on board with what you're trying to do.
The only nit is whether or not to continue to use the nothrow_flag field
to carry this information. Given this is moving to a language specific,
I'd like to avoid that.
Can we allocate one of the "spare" bits in tree_type_common for lang_flag_7?
jeff
