<div dir="ltr"><div class="gmail_extra">On Sun, Apr 7, 2013 at 9:28 PM, Cameron McInally <span dir="ltr"><<a href="mailto:cameron.mcinally@nyu.edu" target="_blank" class="cremed">cameron.mcinally@nyu.edu</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra">More productive (IMO) is to emit explicit guards against the undefined behavior in your language, much as -fsanitize does for undefined behavior in C++. Then work to build a mode where a specific target can take advantage of target specific trapping behaviors to emit these guards more efficiently. This will allow LLVM's optimizers to continue to function in the world they were designed for, and with a set of rules that we know how to build efficient optimizers around, and your source programs can operate in a world with checked behavior rather than undefined behavior. As a useful side-effect, you can defer the target-specific optimizations until you have benchmarks (internally is fine!) and can demonstrate the performance problems (if any).</div>

</div></blockquote><div><br></div></div><div>Regrettably, this implementation does not suit my needs.</div></blockquote><div><br></div><div style>I'm curious why you think so... I think it would very closely match your needs:</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> The constant folding would still occur</div></blockquote><div><br></div><div style>No? At least, I don't see why.</div>
<div style><br></div><div style>I don't know what your frontend is doing (but my impression is that it is not Clang? If I'm wrong, let me know...) but the common idiom is to emit nothing as a constant other than immediate values, and let LLVM's optimizers figure it out. A consequence of this pattern combined with inserting guards is that (at most) the optimizer will fold directly to the trap. You should be able to control the exact structure in the FE though.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> and I would like to produce the actual division, since the instruction is non-maskable on x86.</div>
</blockquote><div><br></div><div style>Yes, and this is the point I was driving at with the comments about a target specific optimization. It is reasonable for the x86 backend to recognize the pattern of testing for a zero divisor and trapping if it occurs, and transform that into an unconditional divide relying on the hardware trap instead. I think it is not unreasonable to have this strategy result in one of two generated code patterns in the overwhelming majority of cases:</div>
<div style><br></div><div style>1) An unconditional trap because the optimizer proved divide by zero</div><div style>2) A direct divide instruction which relies on the x86 trapping behavior.</div><div style><br></div><div style>
That said, it remains a fairly significant amount of work to arrive at this place. Just trying to point out a reasonable approach to arriving there.</div></div></div></div>