<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>Now, looking further this optimization pass should also not mark variables as const if there was a dereference of them before that first assignment. I had code to do this (a hashtable that would track dereferences before assignment is done). But couldn't come up with a test case that would break the whole set of optimizations that Mesa does (lower jumps, or inlining, ... were getting in the way and hide the bug).</div>

</div></blockquote><div><br></div></div></div><div>I'm not sure I agree with this.  The real problem with the example code you showed above is that there's an implicit write to the variable c at the top of the function, so c is not in fact constant--it's written twice.  What we should really do is modify the optimization pass so that it's aware of the implicit write that happens in "in" and "inout" function args.<br>
</div><div>If we resolve the implicit write issue, there should be no harm in marking variables as const if there's a dereference of them before the first assignment, because a dereference of a variable before the first assignment is undefined.<br>
</div></div></div></div></blockquote><div><br></div><div>Right. I'm not sure what's the correct way of making constant variable pass robust, all I know is that in it's current form it is clearly wrong.</div><div>
<br></div><div>If function arguments do get marked as "one write", that effectively means they will be excluded from actual optimization until the function is inlined? Maybe that's okay, no sure.</div><div><br>
</div></div><div><br></div>-- <br>Aras Pranckevičius<br>work: <a href="http://unity3d.com">http://unity3d.com</a><br>home: <a href="http://aras-p.info">http://aras-p.info</a>
<div><br></div>