<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Dmitry,<br>
<br>
In general, you can not safely make assumptions about your
optimizer preserving values. This is fundementally unsafe and is
ill-advised. <br>
<br>
For your particular example, you have a derived pointer which is
live and a base pointer which is not. Have you confirmed that the
derived value (&(obj->some_member)) is available? I would
expect it to be. Given that, your GC has (most of) the
information it needs. Conservative GCs typically consider
interior pointers to objects (i.e. something which is likely a
derived pointer) to be a pointer to the object for exactly this
reason. Now, you can run into cases where the compiler creates a
temporary pointer outside of the object (or worse, into another),
but these are rare in practice. Can I ask what GC library you're
using? To my knowledge, most of the major ones handle interior
pointers just fine. <br>
<br>
If you're interested in pursuing a non-conservative root scanning
policy, I'd suggest you look at the statepoint intrinsics
implemented here:
<a class="moz-txt-link-freetext" href="https://github.com/AzulSystems/llvm-late-safepoint-placement">https://github.com/AzulSystems/llvm-late-safepoint-placement</a><br>
<br>
Yours,<br>
Philip<br>
<br>
On 08/05/2014 11:14 AM, Reid Kleckner wrote:<br>
</div>
<blockquote
cite="mid:CACs=ty+Q-80XzTpX1aOAvp2dq0rEL=6EBH5U-8ubPFp1VWiM2w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>This isn't really feasible.<br>
</div>
<div><br>
</div>
<div>First, you are asking for a warning from LLVM's optimizers,
which we strive to avoid, as they are unstable and affected by
optimization levels.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Second, there are many, many
optimizations that transform code in ways that could remove gc
roots, and it is not practical to annotate them all.</div>
<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">If you have a relocating GC, you need
to implement something more sophisticated like Phillip's late
safepoint insertion approach.<br>
<br>
<div class="gmail_quote">On Tue, Aug 5, 2014 at 4:55 AM,
Dmitry Antipov <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:antipov@dev.rtsoft.ru" target="_blank">antipov@dev.rtsoft.ru</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
it it possible to get a kind of diagnostics if the
variable<br>
is totally optimized away? For example, in:<br>
<br>
void foo (struct some_type *obj) {<br>
... some code where 'obj' is not used ...<br>
bar (obj->some_member);<br>
... some code where 'obj' is not used again ...<br>
baz (obj->some_member);<br>
}<br>
<br>
'obj' is likely to be optimized away so only
'obj->some_member' really<br>
exists (in a register or stack location). Getting
diagnostics<br>
or preserving 'obj' may be important if there is a GC
which scans<br>
C stack and registers conservatively - if there is no
direct reference<br>
to 'obj', it's likely to be reclaimed and so
'obj->some_member'<br>
becomes garbage.<br>
<br>
Dmitry<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>