dblaikie added a subscriber: aprantl. dblaikie added a comment. In D143967#4441333 <https://reviews.llvm.org/D143967#4441333>, @eddyz87 wrote:
> In D143967#4438815 <https://reviews.llvm.org/D143967#4438815>, @dblaikie > wrote: > >> I haven't looked closely at this, but from a vague/quick reading, it sounds >> like this is creating annotations on certain type DINodes, but then moving >> them around to different types? It'd be nice if we could avoid that/create >> them in the right place in the first place. > > Hi @dblaikie, thank you for taking a look! > > I assume you refer to the "placeholder" nodes created for annotated types. > ... Yeah, seems unfortunate to break the abstractions and have to add members and finalizing for such a narrow feature too. Though I appreciate the complications with adding this during type building too. So you get some bunch of annotations from the `BTFTagAttributedType`, then you build the underlying type (which might already be built/needed/fine because it's used without attributes in other places/needs to exist independently) - and then at the end you copy any of these types that are needed and put the annotations on them? Does the `BTFTagAttributedType` always have to apply to the immediate type that's going to be modified/mutated to have the attributes applied to it directly? Is the set of types that may have these attributes/annotations added small/closed? (struct types, void, anything else? could you add tags to `int __tag *`, for instance and get a `DW_TAG_base_type` for "int" with annotations on it? If it's really generic/can apply to any type - but always the /immediate/ type (I guess with the special handling you've got to skip applying it to the `DW_TAG_const_type`, etc)... What if you skipped `getOrCreateType` - and called into the `CreateType` dispatch below that? Since you never want a cached instance of a type, right? You want to create a new copy of the type you could then apply annotations to. Except, I guess, in the instance you showed, where the type is being completed - can't go and create another one, because we're part-way through building this one... hmm, maybe you can, though? What happens if we start making a totally distinct copy of that same type? I guess there's some map that contains such partially completed types, and that map would get confused/break if we tried to build two types for the same type without adding in some extra key goo that contained the annotations... - maybe that wouldn't be too invasive, though? Hmm - I guess what to put in the type cache would be an interesting question. Though that does raise other questions. given this code: #define __tag1 __attribute__((btf_type_tag("tag1"))) struct st { struct st *self; }; struct st __tag1 x; What's the expected DWARF here? `x`'s type is a the attributed/annotated `st` type, but then does the `self` pointer inside there point to the attributed type or the unattributed type? Maybe what you've got is the best of some bad options, but I'm not sure/trying to think it through. (@aprantl wouldn't mind your perspective - if it's too much to consume easily, let me know and I can make a best-effort at summarizing, maybe even better over a video chat if you've got a few minutes) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D143967/new/ https://reviews.llvm.org/D143967 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
