<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 7, 2013 at 8:31 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank" class="cremed">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2s8" style="overflow:hidden">If the value is captured, then I need to make sure that there are no blocking (synchronizing) calls along the execution path. This includes analyzing the function containing the malloc/free. I could just reject captured malloc values, but, unless I'm going to reject any execution path with any function call, then I need to know if the functions will return normally (regardless of whether or not the malloc is captured). And since I need to know if the functions on the execution path return normally anyway, I might as well look for the problematic loops (and atomic/volatile accesses) while I'm at it.<br>
</div></blockquote><div><br></div><div>I really, *really* think that a function attribute that is propagated up the call graph is the only scalable and effective way to implement this. I think doing it in your pass is the wrong design.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2s8" style="overflow:hidden">
<br>
I could certainly start with a version that just rejects all function calls, but it is not clear to me that the rest of it is particularly complicated; and I would not be satisfied with such a solution: it would miss a bunch of low-hanging fruit.</div>
</blockquote></div><br>As discussed with you in person, I think that this is essentially going to be a prototype anyways, and will need to be modified significantly (both in design and implementation) before being enabled. So I think a conservative version is fine, and I wouldn't even bother enabling it by default. The goal of committing an early version is not to start catching some missed optimization opportunities but to make subsequent development incremental and easier to review.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I still really do not think we have the right design here specifically as regards interactions with SROA. I think that's OK because we can fix that incrementally.</div>
</div>