On Tue, 28 Feb 2023, Jakub Jelinek wrote:
> On Tue, Feb 28, 2023 at 12:05:20PM +0000, Richard Biener via Gcc-patches
> wrote:
> > > + p = &TYPE_POINTER_TO (TREE_TYPE (t));
> > > + else if (TREE_CODE (t) == REFERENCE_TYPE && !TYPE_REF_IS_RVALUE
> > > (t))
> > > + p = &TYPE_REFERENCE_TO (TREE_TYPE (t));
> > > + if (p)
> > > + {
> > > + tree t2;
> > > + for (t2 = *p; t2; t2 = TYPE_NEXT_PTR_TO (t2))
> > > + if (TYPE_MODE (t2) == TYPE_MODE (t)
> > > + && TYPE_REF_CAN_ALIAS_ALL (t2) == TYPE_REF_CAN_ALIAS_ALL (t))
> > > + break;
> >
> > Can we elide this searching please? Having duplicated should be harmless
> > unless proved otherwise.
>
> I've posted 2 patches (one inlined, another attached), the second one
> didn't do this at all.
Ah, didn't notice that.
> Having (too many) duplicates would be harmful because build_pointer_type
> etc. walk up to the whole length of list all the time. When the list
> length is bounded (say at most 2 modes - ptr_mode/Pmode, times 2 (the
> can alias all bool), then it doesn't hurt, if it could in theory be
> arbitrarily long, it would be a compile time problem.
> But given that we with the !TYPE_ATTRIBUTES/!TYPE_REF_IS_RVALUE change
> don't have a testcase that would show it is a problem actually ever
> encounterable, the second patch without this is fine I think.
I agree the attached patch is fine.
Richard.
