<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 12, 2013 at 5:28 AM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Manman, thanks for the heads up.  I looked into what it would take to produce<br>
full struct TBAA metadata from the GCC aliasing info (GCC has aliasing info for<br>
struct types, in fact for any type), but it looks kind of tricky.  The problem<br>
is the "offset" field, which doesn't exist in GCC.  In GCC the aliasing<br>
information forms a DAG, with a node for each type, plus a special root node.<br></blockquote><div>This sound similar to clang's TBAA.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

How language types turn into GCC TBAA DAG nodes depends on the language, but<br>
for a simple language like C it is set up like this: scalar types just have an<br>
edge to the root node; struct types have edges to the nodes for the types of<br>
its fields. </blockquote><div><br></div><div>This sounds similar to clang's TBAA as well. Struct types have edges to the field types, but</div><div>we attach an offset for each edge. The TBAA tags also have an access offset and we can use</div>
<div>the access offset and the DAG to decide the access path for the tag. I don't know how gcc's</div><div>TBAA figures out the access path.</div><div><br></div><div>Thanks,</div><div>Manman</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 This is pretty similar to what you have set up, but there is no<br>
offset, and it is not clear how I can get hold of one in general (I need to<br>
look into this more though).<br>
<br>
There are other problems with the offset field too:<br>
<br>
(1) many languages have array types.  For these languages it is natural to have<br>
a node for the array type with an edge to the node for the element type.  But<br>
there is no reasonable offset in general: arrays have many elements (all of the<br>
same type) but each at a different offset.  A possibility is to create one node<br>
per element, but since arrays often have thousands of elements this would create<br>
vast amounts of metadata.  There could be an artificial limit: only produce TBAA<br>
info for arrays with less than X elements, but that is a bit nasty.  It would<br>
also mean not producing any TBAA info for array types with variable size that<br>
you can find in some languages.<br>
<br>
(2) some languages have struct types with fields at variable offsets (i.e. the<br>
offset is determined by the value of some variable, often the value of another<br>
field in the struct).  As the offset is not a constant, it is not possible to<br>
put it in the metadata.  Not producing TBAA info for these types would be a<br>
pity.<br>
<br>
An interesting part of the GCC design is that there is no distinction between<br>
scalar and struct nodes: all nodes are equal.  You can *define* a "scalar" node<br>
to be one which only has an edge to the root, but they might not correspond to<br>
the scalar types in the original language.  In fact I don't think nodes have to<br>
have anything to do with a type at all, they seem to be arbitrary cookies.<br>
<br>
It's a pity that the LLVM design hardwires in the offset.  It looks like it has<br>
been designed with only C like languages in mind, which isn't surprising but is<br>
limiting.  Is the offset field really useful/necessary?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best wishes, Duncan.<div class="HOEnZb"><div class="h5"><br>
<br>
On 08/10/13 02:47, Manman Ren wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Duncan,<br>
<br>
I am hoping to remove the support for the old TBAA format soon.<br>
You should be able to switch to the new format by replacing<br>
<br>
MDNode *AliasTag = MDHelper.createTBAANode(<u></u>TreeName, getTBAARoot());<br>
<br>
with<br>
MDNode *AliasType = MDHelper.<u></u>createTBAAScalarTypeNode(<u></u>TreeName, getTBAARoot());<br>
MDNode *AliasTag = MDHelper.<u></u>createTBAAStructTagNode(<u></u>AliasType, AliasType, 0)<br>
<br>
Also replacing<br>
LeafTag->replaceAllUsesWith(<u></u>getTBAARoot());<br>
<br>
with<br>
MDNode *Root = getTBAARoot();<br>
LeafTag->replaceAllUsesWith(<u></u>MDHelper.<u></u>createTBAAStructTagNode(Root, Root, 0)<br>
<br>
The document is currently at the beginning of TypeBasedAliasAnalysis.cpp. I am<br>
going to update the language ref when struct-path aware TBAA is on by default.<br>
<br>
Let me know if you have any problem with it.<br>
<br>
Thanks,<br>
Manman<br>
<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div>