<div dir="ltr">Hi Hal,<br><div class="gmail_extra"><br><div class="gmail_quote">2014-09-16 13:18 GMT+08:00 Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><span>----- Original Message -----<br>
> From: "Jiangning Liu" <<a href="mailto:liujiangning1@gmail.com" target="_blank">liujiangning1@gmail.com</a>><br>
</span><span>> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
> Cc: <a href="mailto:reviews%2BD5322%2Bpublic%2B26bcfcc2c04b0b02@reviews.llvm.org" target="_blank">reviews+D5322+public+26bcfcc2c04b0b02@reviews.llvm.org</a>, <a href="mailto:mcrosier@codeaurora.org" target="_blank">mcrosier@codeaurora.org</a>, <a href="mailto:joerg@netbsd.org" target="_blank">joerg@netbsd.org</a>,<br>
> "<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a> for LLVM" <<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>><br>
> Sent: Tuesday, September 16, 2014 12:07:21 AM<br>
> Subject: Re: [PATCH] Add threshold for lowering lattice value 'overdefined' in LVI<br>
><br>
><br>
> Hi Hal,<br>
><br>
><br>
</span><span>> I don't understand why putting the count inside LVILatticeVal can be<br>
> helpful to the dilemma you mentioned? Can you explain more about<br>
> this? And why it can be more local that way?<br>
<br>
</span>Is the problem not that, in this worst case, we're doing too many expensive visits to some (LVILatticeVal, BB) pairs? With a global threshold for all (LVILatticeVal, BB) visits, we can do more optimization in some parts of the function than in others (because we'll visit some parts of the function before other parts). If we keep the count per value, then we limit the analysis done per value, but that is independent of where in the function it is.<br></blockquote><div><br></div><div>LazyValueInfo module provides interfaces getConstant and the like to it's customers. This kind of interface is to ask for V's value in basic block BB as specified by parameters like (Value *V, BasicBlock *BB, ...). Eventually, the algorithm tries to "solve()" the value by lowering the lattice value. Each time before "solving" the value, the counter I set will be clear/reset to 0, so it means my solution is already per value basis. To some extension, it is already independent of where it is in the function, because we can ask for "solving" the value anywhere in the function. When "solving" a single value for a specific block, the lattice lowering algorithm could visit very large number of other basic blocks(predecessors). The threshold I added for BB is avoid visiting too many BBs, and it simply bails out lowering for this specific value only.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><span><br>
><br>
><br>
> I think at present we have an unique ValueCacheEntryTy for each value<br>
> on a specific block. If we put a count inside LVILatticeVal, what is<br>
> the semantic of this count?<br>
<br>
</span>My thought was that it would be the same as the count you originally proposed, but per value. So we'd count the number of times the value had been marked as over-defined. And once the limit is reached, we'd give up.<br></blockquote><div><br></div><div>Those two threshold I added already coverd both per BB and per value. If what you are proposing is per Latice Value count and add threshold for this count, I don't see it could help to solving the delimma of optimizing early blocks only for very big functions, because we have unique Lative Value for each (BB, Value) pair in the algorithm, which are stack values returned by functions like getXXX().</div><div><br></div><div>The number of times the value had been marked as overdefined in a single value "solving" stage should be very small, because the algorithm will merge values after parsing predecessor for the value. If the value is lowered to be a fixed value, the algorithm will exit shortly. If the value after merge is still overdefined, the algorithm should not visit it through walking stack (<span>BlockValueStack</span><span></span>) again. Maybe I'm wrong about procedure, but this is my current understanding.</div><div><br></div><div>Thanks,</div><div>-Jiangning</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<br>
 -Hal<br>
</blockquote></div><br></div></div>