On 07/07/16 17:40, Jeff Law wrote: > 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? >
Yes I agree, there are still 26 spare bits, so there is absolutely no need to squeeze that info in the base.nothrow_flag. Thanks Bernd.
