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 ;-) > 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. -- 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
