<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ok, replying anew now that I understand why reasoning about abstract
locations for each object doesn't work.<br>
<br>
The general idea of describing a set of load and stores which belong
to a particular invariant group seems reasonable. I've got some
questions/comments on the specifics, but the overall direction seems
entirely workable for the specific problem you're trying to solve.
<br>
<br>
<br>
Quoting from the google doc: <span
style="font-size:14.666666666666666px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">"If
we don’t know definition of some function, we assume that it will
not call @llvm.invariant.group.barrier().</span>"<br>
This part really really bugs me. We generally try to assume minimal
knowledge of external functions (i.e. they can do anything) and this
assumption would invert that. Is there a way we can rephrase the
proposal which avoids the need for this? I'm not quite clear what
this assumption buys us.<br>
<br>
<br>
Is there a particular reason why a load or store must belong to a
single invariant group rather than be a member of several? I don't
have an immediate use case in mind, but it seems potentially
useful. <br>
<br>
<br>
"<span
style="font-size:20px;font-family:Arial;color:#000000;background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">i8*
@llvm.invariant.group.barrier(i8*):</span><span
style="font-size:14.666666666666666px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">
Given a pointer, produces another pointer that aliases the first
but which is considered different for the purposes of load
!invariant.group metadata.</span>"<br>
The definition here minorly bugs me. This might just be a matter of
wordsmithing, but it seems strange to me that this can't be defined
in terms of the assumptions allowed about the memory through the two
pointers. If I'm looking at this instruction in memory dependence
analysis, what am I allowed to assume, not assume? The current
definition doesn't make this obvious. One option: "produces another
pointer which aliases the first, but where any invariant assumptions
introduced by invariant.group metadata have been striped away."<br>
<br>
<br>
The notion of using the assume seems to make sense. I could see an
argument for extending the invariant.group metadata with a way to
express the assumed value, but we could also make that extension at
a later time if needed.<br>
<br>
<br>
I'm wondering if there's a problematic interaction with CSE here.
Consider this example is pseudo LLVM IR:<br>
v1 = load i64, %p, !invariant.group !Type1<br>
; I called destructor/placement new for the same type, but that
optimized entirely away<br>
p2 = invariant.group.barrier(p1)<br>
if (p1 != p2) return.<br>
store i64 0, %p2, !invariant.group !Type1<br>
v2 = load i64, %p2, !invariant.group !Type1<br>
ret i64 v1 - v2<br>
<br>
(Assume that !Type is used to describe a write once integer field
within some class. Not all instances have the same integer value.)<br>
<br>
Having CSE turn this into:<br>
v1 = load i64, %p, !invariant.group !Type1<br>
p2 = invariant.group.barrier(p1)<br>
if (p1 != p2) return.<br>
store i64 0, %p1, !invariant.group !Type1<br>
v2 = load i64, %p1, !invariant.group !Type1<br>
ret i64 v1 - v2<br>
<br>
And then GVN turn this into:<br>
v1 = load i64, %p, !invariant.group !Type1<br>
p2 = invariant.group.barrier(p1)<br>
if (p1 != p2) return.<br>
ret i64 v1 - v1 (-> 0)<br>
<br>
This doesn't seem like the result I'd expect. Is there something
about my initial IR which is wrong/invalid in some way? Is the
invariant.group required to be specific to a single bitpattern
across all usages within a function/module/context? That would be
reasonable, but I don't think is explicit said right now. It also
makes !invariant.group effectively useless for describing constant
fields which are constant per instance rather than per-class. <br>
<br>
<br>
Philip<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 07/22/2015 02:55 PM, Piotr Padlewski
wrote:<br>
</div>
<blockquote
cite="mid:CABUQfFrc_ywRN7h13=erx1Eq+vyTmFFeWZbrXQJ7NX2Km=zGFA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi folks,</div>
<div>this summer I will work with Richard Smith on clang
devirtualization. Check out our proposal:</div>
<div><br>
</div>
<a moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA_edit-3Fusp-3Dsharing&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-sGvXxkjadRLtXcTi4kOVPumoH-0XOKmk_vgUTcYugY&s=hHoo6tgC-NooXdIwbBwT_D8sIw8fcYF4XvBRI8Lr9Eg&e=">https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing</a><br>
<div><br>
</div>
<div>And modified LangRef</div>
<div><a moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11399&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-sGvXxkjadRLtXcTi4kOVPumoH-0XOKmk_vgUTcYugY&s=L6_vdinD06uAwgm4OJGL5QxKw8Tzfa_4DxPwf3Zj704&e=">http://reviews.llvm.org/D11399</a><br>
</div>
<div><br>
</div>
<div>You can also check out previous disscussion that was
started before our proposal was ready - <a
moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-July/044052.html">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-July/044052.html</a></div>
<div><br>
</div>
<div>Regards</div>
<div>Piotr Padlewski</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>