<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 5, 2015, at 4:46 PM, George Burgess IV <<a href="mailto:george.burgess.iv@gmail.com" class="">george.burgess.iv@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">+Yogesh -- he found bugs (llvm_unreachable reached -- looking into why now) and said that he'd be interested in helping. Yay!<div class=""><br class=""></div><div class="">Status update: Toy implementation of properly handling inttoptr/ptrtoint conversions (see: the fix for #2 on Danny's list) passes tests. I need to do a bit of clean up (and want to test it more thoroughly), and will hopefully have that patch out + a fix for the bug noted above by the end of the weekend</div><div class=""><br class=""></div><div class=""><div class="">George</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Feb 4, 2015 at 12:43 AM, George Burgess IV <span dir="ltr" class=""><<a href="mailto:george.burgess.iv@gmail.com" target="_blank" class="">george.burgess.iv@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Sounds good, I'll reword that comment. Also, the assert you mentioned turned out to be a bad assumption when combined with how I foresee us handling inttoptr/ptrtoint in the future, so I'll just replace it with slightly more robust code. :)<div class=""><br class=""></div><div class="">Thanks for the feedback,</div><div class="">George</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Feb 3, 2015 at 11:30 PM, Hal Finkel <span dir="ltr" class=""><<a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi George,<br class="">
<br class="">
+// Given an Instruction, this will add it to the graph, along with any<br class="">
<br class="">
+// Instructions that are potentially only available from said Instruction<br class="">
<br class="">
I think this comment is somewhat misleading. You can't really have orphaned instructions: instructions that have been inserted into a basic block must appear in its linked list of instructions that you'll visit when you iterate over all of them. You can have constantexprs, and I think that's what you're try to say.<br class="">
<br class="">
+      assert(Edge.From == Inst.get() &&<br class="">
<br class="">
+          "Expected ConstantExpr edge `From` to evaluate to the ConstantExpr");<br class="">
<br class="">
Indentation is odd here.<br class="">
<br class="">
For algorithmic considerations, I think that Danny is certainly the best person to review these.<br class="">
<br class="">
 -Hal<br class="">
<span class=""><br class="">
----- Original Message -----<br class="">
> From: "George Burgess IV" <<a href="mailto:george.burgess.iv@gmail.com" target="_blank" class="">george.burgess.iv@gmail.com</a>><br class="">
> To: "Hal J. Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a>><br class="">
> Cc: "Chandler Carruth" <<a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a>>, "Jiangning Liu" <<a href="mailto:Jiangning.Liu@arm.com" target="_blank" class="">Jiangning.Liu@arm.com</a>>, "LLVM Developers Mailing<br class="">
> List" <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank" class="">llvmdev@cs.uiuc.edu</a>>, "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org" target="_blank" class="">dberlin@dberlin.org</a>><br class="">
> Sent: Friday, January 30, 2015 10:34:43 PM<br class="">
> Subject: Re: [LLVMdev] question about enabling cfl-aa and collecting a57 numbers<br class="">
><br class="">
><br class="">
</span><div class=""><div class="">> So, I split it up into three patches:<br class="">
><br class="">
><br class="">
> - cflaa-danny-fixes.diff are (some of?) the fixes that Danny gave us<br class="">
> earlier for tests + the minimal modifications you’d need to make in<br class="">
> CFLAA to make them pass tests.<br class="">
> - cflaa-minor-bugfixes.diff consists primarily of a bug fix for<br class="">
> Argument handling — we’d always report NoAlias when one of the given<br class="">
> variables was an entirely unused argument<br class="">
> (We never added the appropriate Argument StratifiedAttr)<br class="">
> - cflaa-constexpr-fix.diff - The fix for the constexpr behavior we’ve<br class="">
> been seeing<br class="">
><br class="">
><br class="">
> Patches are meant to be applied in the order listed.<br class="">
><br class="">
><br class="">
> Also, I just wanted to thank everyone again for your help so far —<br class="">
> it’s greatly appreciated. :)<br class="">
><br class="">
><br class="">
> George<br class="">
><br class="">
><br class="">
</div></div>> On Jan 30, 2015, at 11:56 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a> > wrote:<br class="">
><br class="">
> ----- Original Message -----<br class="">
><br class="">
><br class="">
> From: "George Burgess IV" < <a href="mailto:george.burgess.iv@gmail.com" target="_blank" class="">george.burgess.iv@gmail.com</a> ><br class="">
> To: "Hal Finkel" < <a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a> ><br class="">
> Cc: "Chandler Carruth" < <a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a> >, "Jiangning Liu" <<br class="">
> <a href="mailto:Jiangning.Liu@arm.com" target="_blank" class="">Jiangning.Liu@arm.com</a> >, "LLVM Developers Mailing<br class="">
> List" < <a href="mailto:llvmdev@cs.uiuc.edu" target="_blank" class="">llvmdev@cs.uiuc.edu</a> >, "Daniel Berlin" < <a href="mailto:dberlin@dberlin.org" target="_blank" class="">dberlin@dberlin.org</a><br class="">
> ><br class="">
> Sent: Friday, January 30, 2015 10:29:07 AM<br class="">
<span class="">> Subject: Re: [LLVMdev] question about enabling cfl-aa and collecting<br class="">
> a57 numbers<br class="">
><br class="">
</span>> I had thought that the case that Danny had looked at had a constant<br class="">
> GEP, and so this constant might alias with other global pointers.<br class="">
> How is that handled now?<br class="">
> That issue had to do with that we assumed that for all arguments of a<br class="">
> given Instruction, each argument was either an Argument,<br class="">
> GlobalValue, or Inst in `for (auto& Bb : Inst.getBasicBlockList())<br class="">
> for (auto& Inst : Bb.getInstList())`. ConstantExprs didn't fit into<br class="">
> this instruction, because they aren't reached by said nested loop.<br class="">
><br class="">
><br class="">
> With this fix, if we detect that there's a relevant ConstantExpr,<br class="">
> we'll look into it as if it were a regular Instruction inside of<br class="">
> Bb.getInstList(), which causes us to correctly detect the globals,<br class="">
> etc.<br class="">
><br class="">
> Sounds good.<br class="">
><br class="">
> Thanks!<br class="">
><br class="">
> -Hal<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> (I included a test case specifically for this -- it's ugly, but we<br class="">
> have ~3 nested GEPs with a global at the innermost GEP. It produces<br class="">
> the appropriate output)<br class="">
><br class="">
><br class="">
> George<br class="">
><br class="">
><br class="">
> On Fri, Jan 30, 2015 at 10:56 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a> ><br class="">
> wrote:<br class="">
><br class="">
><br class="">
> ----- Original Message -----<br class="">
><br class="">
><br class="">
> From: "George Burgess IV" < <a href="mailto:george.burgess.iv@gmail.com" target="_blank" class="">george.burgess.iv@gmail.com</a> ><br class="">
> To: "Daniel Berlin" < <a href="mailto:dberlin@dberlin.org" target="_blank" class="">dberlin@dberlin.org</a> ><br class="">
> Cc: "Chandler Carruth" < <a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a> >, "Hal Finkel" <<br class="">
> <a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a> >, "Jiangning Liu"<br class="">
> < <a href="mailto:Jiangning.Liu@arm.com" target="_blank" class="">Jiangning.Liu@arm.com</a> >, "LLVM Developers Mailing List" <<br class="">
> <a href="mailto:llvmdev@cs.uiuc.edu" target="_blank" class="">llvmdev@cs.uiuc.edu</a> ><br class="">
> Sent: Friday, January 30, 2015 8:15:55 AM<br class="">
<span class="">> Subject: Re: [LLVMdev] question about enabling cfl-aa and<br class="">
> collecting a57 numbers<br class="">
><br class="">
><br class="">
><br class="">
</span>> I'm not exactly thrilled about the size of this diff -- I'll<br class="">
> happily<br class="">
> break it up into more manageable bits later today, because some of<br class="">
> it is test fixes, another bit is a minor bug fix, etc.<br class="">
><br class="">
> Yes, please break it into independent parts.<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> Important bit (WRT ConstantExpr): moved the loop body from<br class="">
> buildGraphFrom into a new function. The body has a few tweaks to<br class="">
> call constexprToEdges on all ConstantExprs that we encounter.<br class="">
> constexprToEdges, naturally, interprets a ConstantExpr (and all<br class="">
> nested ConstantExprs) and places the results into a<br class="">
> SmallVector<Edge>.<br class="">
><br class="">
><br class="">
> I'm assuming this method of handling ConstantExprs isn't 100%<br class="">
> correct<br class="">
> because I was told that handling them correctly would be more<br class="">
> difficult than I think it is. I can't quite figure out why, so<br class="">
> examples of cases that break my code would be greatly appreciated.<br class="">
> :)<br class="">
><br class="">
> I had thought that the case that Danny had looked at had a constant<br class="">
> GEP, and so this constant might alias with other global pointers.<br class="">
> How is that handled now?<br class="">
><br class="">
> Thanks again,<br class="">
> Hal<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> George<br class="">
><br class="">
><br class="">
> On Mon, Jan 26, 2015 at 2:43 PM, George Burgess IV <<br class="">
> <a href="mailto:george.burgess.iv@gmail.com" target="_blank" class="">george.burgess.iv@gmail.com</a> > wrote:<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> Inline<br class="">
><br class="">
><br class="">
> George<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> On Jan 26, 2015, at 1:05 PM, Daniel Berlin < <a href="mailto:dberlin@dberlin.org" target="_blank" class="">dberlin@dberlin.org</a> ><br class="">
> wrote:<br class="">
><br class="">
><br class="">
> George, given that, can you just build constexpr handling (it's not<br class="">
> as easy as you think) as a separate funciton and have it use it in<br class="">
> the right places?<br class="">
> Will do. :)<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> FWIW, my current list of CFLAA issues is:<br class="">
><br class="">
> 1. Unknown values (results from ptrtoint, incoming pointers, etc)<br class="">
> are<br class="">
> not treated as unknown. These should be done through graph edge (so<br class="">
> that they can be one way, otherwise, you will unify everything :P)<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> 2. Constexpr handling<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> ^^^ These are correctness issues. I'm pretty sure there are a few<br class="">
> more but i haven't finished auditing<br class="">
> 3. In a number of places we treat non-pointers as memory-locations<br class="">
> and unify them with pointers. This introduces a lot of spurious<br class="">
> aliasing.<br class="">
> 4. More generally, we induce a lot of spurious aliasing through<br class="">
> things at different dereference levels. In these cases, one may to<br class="">
> the other, but, for example, if we have a foo***, and a foo* (and<br class="">
> neither pointers to unknown things or escapes), the only way for<br class="">
> foo<br class="">
> *** to alias foo* is if there is a graph path with two dereferences<br class="">
> between them.<br class="">
> We seem to get this wrong sometimes. Agreed on all four. Though<br class="">
> naturally it should be fixed, I’d like to see how much of an issue<br class="">
> #4 ends up being when we properly deal with #3.<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> On Sun Jan 25 2015 at 6:44:07 PM Chandler Carruth <<br class="">
> <a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a> > wrote:<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> On Sun, Jan 25, 2015 at 6:37 PM, George Burgess IV <<br class="">
> <a href="mailto:george.burgess.iv@gmail.com" target="_blank" class="">george.burgess.iv@gmail.com</a> > wrote:<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> Fixing that still gives a wrong result, i haven't started to<br class="">
> track<br class="">
> down what *else* is going on here.<br class="">
><br class="">
><br class="">
> Running with the attached diff + a modified buildGraphFrom to<br class="">
> handle<br class="">
> the constexpr GEPs, we seem to flag everything in test2.ll<br class="">
> (conservatively) correctly.<br class="">
><br class="">
><br class="">
> Is `store` the only place we can expect to see these constexpr<br class="">
> analogs, or is just about anywhere fair game?<br class="">
><br class="">
><br class="">
> Any Value can be a ConstantExpr, so all operands to instructions<br class="">
> are<br class="">
> fair game.<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> --<br class="">
> Hal Finkel<br class="">
> Assistant Computational Scientist<br class="">
> Leadership Computing Facility<br class="">
> Argonne National Laboratory<br class="">
><br class="">
><br class="">
<span class=""><font color="#888888" class="">><br class="">
> --<br class="">
> Hal Finkel<br class="">
> Assistant Computational Scientist<br class="">
> Leadership Computing Facility<br class="">
> Argonne National Laboratory<br class="">
><br class="">
<br class="">
--<br class="">
Hal Finkel<br class="">
Assistant Computational Scientist<br class="">
Leadership Computing Facility<br class="">
Argonne National Laboratory<br class="">
</font></span></blockquote></div><br class=""></div>
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>