<div dir="ltr"><div dir="auto">Ah yes, of course! For our thesis we're trying to reconstruct Value names from the IR to C syntax, to help with clarity in optimisation remarks. To do this for something like a GetElementPointer we first have to find the name of the pointer operand, and then we try to name the offsets. Naming array offsets is relatively straightforward, but for structs we need the DICompositeType which contains the struct field names. So we make the recursive call to name the pointer operand also return the operand's DIType, and from this we get the base type of the pointer. However  we're struggling with handling bitcasts properly at the moment. When the pointer operand of a GEP is a bitcast, say from a struct pointer type to a pointer to the struct's first field we can figure that out by diffing the Value types and then traversing the DIType accordingly. When the cast is  from smaller to wider type, on the other hand, we cannot just traverse the DIType structure to the wider type as the link is only in one direction. We recognise that there may be several potential wider types matching the Value type, but this is a best effort matching.</div><div dir="auto"><br></div><div>We have discussed traversing all the DITypes in the module to find uses of the smaller type, and we have also thought about making changes to clang to emit debug variable intrinsics for bitcasts so we can find the correct DIType from the bitcast instruction itself. We're not sure how feasible these are in the grander scheme of things. Would emitting debug variable intrinsics for all bitcasts have a semantics mismatch in later passes when DWARF data is generated? Is it feasible to traverse all of the DITypes without damaging performance too much? Would saving the uses in the reverse direction like for Values have too large of a memory footprint? Obviously we'll make the changes we need to make things work for our thesis, but if possible we would like to not make changes that are invasive enough that it's unmergeable back into mainline LLVM.</div><div><br></div><div>/Henrik<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 25 Mar 2020, 18:10 Adrian Prantl, <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It might help if you could explain what you are *actually* trying to do, since there are often other solutions for the higher-level problem that fit better into the design and architecture.<br>
<br>
-- adrian<br>
<br>
> On Mar 25, 2020, at 4:01 AM, Henrik Olsson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> I'm looking for a way to efficiently traverse the Metadata structure in reverse, or otherwise find DITypes that refer to another DIType. As an example, say I have a DICompositeType describing a struct. Now I want to find other DITypes containing this type, e.g. a DIDerivedType describing its pointer type, or another struct containing this struct as one of its fields. Is this possible in LLVM today? Would it be unreasonable to save Metadata to Metadata uses, like what is done for Value to Value uses?<br>
> <br>
> Any help would be greatly appreciated,<br>
> Henrik<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote></div>