On Thu, Sep 26, 2019 at 4:05 AM Alexandre Oliva <ol...@adacore.com> wrote: > > On Sep 13, 2019, Richard Biener <richard.guent...@gmail.com> wrote: > > > On Fri, Sep 13, 2019 at 1:32 AM Alexandre Oliva <ol...@adacore.com> wrote: > >> On Sep 12, 2019, Richard Biener <richard.guent...@gmail.com> wrote: > > >> > So - maybe we can have the patch a bit cleaner by adding > >> > a flag to add_type_attribute saying we only want it if it's > >> > different from that already present (on the specification DIE)? > > >> That's exactly what I meant completing_type_p to check. Do you mean it > >> should be stricter, do it more cheaply, or what? > > > I meant to do it more cheaply > > How? If it's the same type, lookup will find the DIE and be done with > it. If it's not, we'll want to build a new DIE anyway. Where > computation is there to avoid that is not already avoided? > > > also the name completing_type_p is > > misleading IMHO since it simply checks (re-)creating the type DIE > > will yield a different one > > True. The expectation is that the type of a decl will not transition > from complete to incomplete. different_type_p would be more accurate > for unexpected frontends that behaved so weirdly, but not quite as > intuitive as to the intent. I still like completing_type_p better, but > if you insist, I'll change it. Bonus points for a better name ;-)
Heh, I don't have one - which usually makes me simply inline the beast into the single caller :P Maybe simply have_new_type_for_decl_with_old_die_p? Or new_type_for_die_p? > > sure how that would look like (create a new variable DIE and > > splice out "common" parts into an abstract DIE used by > > both the old and the new DIE?) > > In my exhaustive verification of all hits of completing_type_p in an > all-languages bootstrap, we had either a new DIE for the outermost array > type, now with bounds, sharing the remaining array dimensions; an > alternate symbolic name ultimately referring to the same type > definition; or an extra const-qualifying DIE for a const array type > whose base type is already const-qualified. None of these seemed > excessive to me, though the last one might be desirable and not too hard > to avoid. > > I haven't seen any case of transitioning to less-defined types. Yeah, that would be surprising indeed. The patch is OK with using new_type_for_die_p. Thanks, Richard. > -- > Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo > Be the change, be Free! FSF VP & FSF Latin America board member > GNU Toolchain Engineer Free Software Evangelist > Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
