<div dir="ltr">SGTM then.<div>I'll let george continue taking a look.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 10:06 AM, Jia Chen <span dir="ltr"><<a href="mailto:grievejia@gmail.com" target="_blank">grievejia@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grievejia added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D21387#458889" rel="noreferrer" target="_blank">http://reviews.llvm.org/D21387#458889</a>, @dberlin wrote:<br>
<br>
> It's not clear to me why you don't, long term, end up with attributes both<br>
>  for edges and nodes.<br>
><br>
> For example, for edges, to support field-sensitive analysis, you will<br>
>  either need the offset or something as an edge attribute, so you can<br>
>  differentiate what edge to follow for a given offset.<br>
>  (unless y'all know another way)<br>
<br>
<br>
</span>Edge attributes could be useful. I totally agree.<br>
<br>
However, the semanitics of StratifiedAttr, in it current form, describes something about nodes, not edges. When CFLGraph gets translated to StratifiedSets, those "edge" attributes on CFLGraph will become "node" attributes in StratifiedSets anyway. So IMO it makes more sense to move StratifiedAttr from edges to nodes.<br>
<br>
You are right that for field sensitivity we may need to attach certain information to edges in the future. But those information will look very different from the StratifiedAttr we have right now.<br>
<br>
<br>
<a href="http://reviews.llvm.org/D21387" rel="noreferrer" target="_blank">http://reviews.llvm.org/D21387</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>