<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi, all:<br>
<br>
Per Chris and Nadav's request, I begin to write the code about
analyzing address-taken <br>
lazily. I realize the alias query could be initiated from any
context (*function* pass, loop pass etc), <br>
however, the analysis for global-variable-address-taken is conducted
in *module* scope. <br>
Is there any potential problem over here? (For instance, function
foo() and bar() comprise module m, <br>
however, at time optimizer is working on foo(), bar() is not
physically in that module. In this case, <br>
analyze global-variable on the fly doesn't make sense.)<br>
<br>
Thanks in advance!<br>
Shuxin<br>
<br>
<div class="moz-cite-prefix">On 10/30/13 2:08 PM, Chris Lattner
wrote:<br>
</div>
<blockquote
cite="mid:773C9D8D-958D-4959-AB09-3051014BF6E4@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<div>On Oct 30, 2013, at 10:37 AM, Shuxin Yang <<a
moz-do-not-send="true" href="mailto:shuxin.llvm@gmail.com">shuxin.llvm@gmail.com</a>>
wrote:</div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">Nadav:<br>
<br>
I don't think this is right approach for engineering. <br>
The time-complexity of re-analyzing addr_taken for each
single alias query depends on <br>
1. how many global variable<br>
2. how many occurrence of these global variables.<br>
3. how many queries the compiler have.<br>
<br>
3) depends on compiler. You never know what we will have
in the following few years. <br>
1 and 2 depends on the program. You never know what kind of
program you will run into. <br>
How can we use what we have today the extrapolate the future
ignoring the highly <br>
unpredictable complexity.<br>
</div>
</blockquote>
<div><br>
</div>
This logic doesn't make sense to me. You can implement it both
ways and get empirical results on *programs we have today* and
*in our compiler*. This is not a theoretical exercise.</div>
<div><br>
</div>
<div>In practice, walking the use list of a global variable is
very fast. As you've noticed, we already use this approach (in
an admittedly ad-hoc and decentralized way) throughout the
compiler.</div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> It's interesting that
recently, many EE magazine (circuit cellar, Elector, EE
times) are <br>
discussing buggy SW kill people. I remember some posts
complaining that some buggy program<br>
have amazingly large # of global variables. I can find one
post in Chinese website: <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://forum.xitek.com/thread-1226816-5-1-1.html">http://forum.xitek.com/thread-1226816-5-1-1.html</a><br>
<br>
The 1st post says, "a program has 11000 global
variables"!<br>
</div>
</blockquote>
<div><br>
</div>
<div>This is just FUD and completely unrelated to the
discussion.</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> As to "Can you
provide this data"? My answer is no, and I will not to
implement the analysis <br>
which perform on-the-fly analysis unless I'm convinced that
saving addr_taken bit to llvm::GlobalVariable <br>
is fundamentally flawed. <br>
</div>
</blockquote>
</div>
<br>
<div>You don't have to be convinced. The burden of proof is on
you - not on us to convince you.</div>
<div><br>
</div>
<div>Here's the deal: there are tons of "potentially useful"
things that could be encoded in the IR. Each thing added to IR
has a complexity increase on the entire compiler. Passes that
work on global variables will have to reason about this bit, and
transformations that could invalidate it (e.g. global merging)
will have to have code added to update/preserve it.</div>
<div><br>
</div>
<div>We are very conservative about changing IR for good reason.
We don't add caches to IR unless there is pretty much no other
way to achieve the result. In a perfect world, we would have
nothing redundant in the IR at all.</div>
<div><br>
</div>
<div>That said, I'm open to this attribute, because I think the
semantics can be nailed down tightly (though your "volatile"
discussion doesn't make any sense to me) it is widely useful,
and I don't think the burden of maintaining it will be that
high. However, before we do it, you need to demonstrate that
lazily computing it from use-def chains is *empirically worse*.</div>
<div><br>
</div>
<div>-Chris</div>
</blockquote>
<br>
</body>
</html>