<div dir="ltr">Hi Siddharth,<div><br></div><div>SCEVExpander::expandCodeFor takes the insert point as an argument, so that's entirely client-controlled. That insert point also never changes. So there is no need to ever query it from the expander.</div><div><br></div><div>On the other hand, if you wanted to pass around an expander object to expand multiple SCEVs, I think it's much clearer to pass the insert point instead. Again, no hidden state!</div><div><br></div><div>Cheers,</div><div>Philip</div><div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-03 12:20 GMT+02:00 Siddharth Bhat <span dir="ltr"><<a href="mailto:siddu.druid@gmail.com" target="_blank">siddu.druid@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey, <div><br></div><div>Alternatively, expose a SCEVExpander::getInsertPoint? This would proxy the underlying IRbuilder, with no real state sharing, other than the current insert point. </div><div><br></div><div>This will be less ugly than recieving the expanded SCEV value, casting to an instruction, and feeding this to the IRBuilder.</div><div><br></div><div>Cheers,</div><div>siddharth<div><div class="h5"><br><br><div class="gmail_quote"><div dir="ltr">On Thu 3 May, 2018, 15:36 Philip Pfaffe via llvm-dev, <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Alex, Sanjoy,<div><br></div><div>exposing the internal IRBuilder to users of SCEVExpander violates information hiding, and encourages the tight coupling that makes code bases such as Polly so hard to maintain. SCEVExpander::<wbr>expandCodeFor returns a Value that (if it's an instruction) can be used to update the insert point of the client's IRBuilder. Is that not enough? </div><div><br></div><div>No hidden state, no hidden state transitions, so it's locally clear to a reader how the IRBuilder moves.</div><div><br></div><div>Cheers,</div><div>Philip</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-04-29 20:50 GMT+02:00 Sanjoy Das via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alexandre,<br>
<br>
Sorry I missed this -- I was on vacation when you sent this.<br>
<br>
SCEVExpander already has an IRBuilder in it but AFAICT it isn't<br>
exposed as a public interface. I'd be fine if you wanted to expose a<br>
public `GetIRBuilder()` accessor that let a SCEVExpander client use<br>
the same IRBuilder as SCEVExpander.<br>
<br>
-- Sanjoy<br>
<div><div class="m_8091846157843613532m_5887538694788328120h5"><br>
On Fri, Apr 6, 2018 at 10:55 AM, Alexandre Isoard via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hello,<br>
><br>
> I use SCEVExpander and IRBuilder to generate some code and I frequently<br>
> end-up breaking dominance because the SCEVExpander insertion point and the<br>
> IRBuilder insertion point do not advance in synchrony.<br>
><br>
> Ideally, I could build a SCEVExpander based on an existing IRBuilder (so<br>
> that they move each other). Or even better, SCEVExpander inherit from<br>
> IRBuilder and basically extend it with SCEV expander capabilities (then I<br>
> don't need to use a separate IRBuilder).<br>
><br>
> Or maybe I am using them wrong? What is the intended way to use those?<br>
><br>
> --<br>
> Alexandre Isoard<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
><br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr" class="m_8091846157843613532gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Sending this from my phone, please excuse any typos!</div></div>
</font></span></blockquote></div><br></div>