<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 23, 2013 at 4:50 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><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 class="im">----- Original Message -----<br>
> From: "David Majnemer" <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
</div><div class="im">> Cc: "Renato Golin" <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>>, "LLVM" <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>

> Sent: Saturday, November 23, 2013 2:37:52 PM<br>
> Subject: Re: [LLVMdev] [RFC] Identifying access to errno<br>
><br>
><br>
</div><div class="im">> Oh, and I forgot a third "_doserrno" for which no amount of<br>
> documentation lends itself to a consistent description of its<br>
> behavior.<br>
<br>
</div>Are all of these things possibly set by cos(double) and friends?<br></blockquote><div><br></div><div>Math functions are special! :)</div><div><br></div><div>In error cases, they call a function call _matherr.  This function will typically set only errno.  However, programs which link dynamically against the MSVCRT are permitted to replace the function with whatever they want (this is documented behavior!); their _matherr might forward it's arguments to "fire_the_missiles".</div>
<div> </div><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">
<span class=""><font color="#888888"><br>
 -Hal<br>
</font></span><div class=""><div class="h5"><br>
><br>
><br>
><br>
> On Sat, Nov 23, 2013 at 12:28 PM, David Majnemer <<br>
> <a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a> > wrote:<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Sat, Nov 23, 2013 at 9:59 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > From: "Renato Golin" < <a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a> ><br>
> > To: "Hal Finkel" < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> > Cc: "LLVM" < <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a> ><br>
> > Sent: Saturday, November 23, 2013 10:53:09 AM<br>
> > Subject: Re: [LLVMdev] [RFC] Identifying access to errno<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On 23 November 2013 14:14, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> > wrote:<br>
> ><br>
> ><br>
> > On some systems (Linux/glibc, for example), some libm math<br>
> > functions<br>
> > (like cos(double)) might set errno. It is important that we model<br>
> > this, in general, to prevent miscompilation (we would not, for<br>
> > example, want to reorder a call to cos in between a call to open<br>
> > and<br>
> > a call to perror). However, almost no code in the wild checks errno<br>
> > after calls to libm math functions, and this errno-setting behavior<br>
> > prevents vectorization and other useful loop optimizations, CSE,<br>
> > etc. Also, currently, the scalar llvm.<libm function> intrinsics<br>
> > are<br>
> > subtly broken on systems where the underlying libm functions may<br>
> > set<br>
> > errno, because the intrinsics are readonly, and may be implemented<br>
> > by calls to the libm function (which might set errno), exposing us<br>
> > to reordering problems (as in the example above).<br>
> ><br>
> ><br>
> ><br>
> > Hi Hal,<br>
> ><br>
> ><br>
> > I'm confused. On one hand you're proposing us to stop reordering<br>
> > libm<br>
> > calls because they might set errno (I agree with this), but on the<br>
> > other hand you're saying that nobody cares and that prevents<br>
> > optimizations (not sure I agree with this).<br>
> ><br>
><br>
> What I'm saying is that very few people actually check errno after<br>
> libm calls, and so we're often preventing vectorization for no good<br>
> reason. However, obviously we still need to prove that no errno<br>
> access is occurring if we want to vectorize (unfortunately, our<br>
> ability to do this may be limited outside of an LTO context -- but<br>
> under fast-math or with some pragma, etc. we may be able to change<br>
> the default assumptions). In short, I'm proposing that we both:<br>
><br>
> 1. Be more strict to prevent unwanted reorderings (by actually<br>
> modeling that these functions may *write* to errno).<br>
><br>
> 2. Improve our modeling of errno so that we can ignore said writes<br>
> (safely) when we know that value of errno is unused. A setting like<br>
> -fno-math-errno should not "remove" the modeling of these writes,<br>
> just declare our disinterest in the resulting value.<br>
><br>
> But, what I'm trying to establish here is: how can we recognize<br>
> possible errno access so that explicitly modeling the writes to<br>
> errno does not unduly pessimize the surrounding code.<br>
><br>
><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > 1. Assume that all unknown external functions might read/write<br>
> > errno<br>
> ><br>
> > 2. Assume that all i32 pointers might point to errno (although we<br>
> > might be able to do better by somehow leveraging TBAA for "int"?)<br>
> ><br>
> ><br>
> ><br>
> > Something like "MayBeErr", "IsErr", "IsntErr".<br>
><br>
> On what?<br>
><br>
><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Does anyone see any problems with making stronger (type-based)<br>
> > assumptions re: errno (and, thus, on what things may alias with<br>
> > calls to errno-setting-libm functions)?<br>
> ><br>
> ><br>
> > I don't, but I'm trying to think of a way to disable it if we know<br>
> > it's "ok". Maybe -unsafe-math or something similar could disable<br>
> > this pass, because it is expensive and will impact generated code.<br>
> ><br>
><br>
> We already run IPO/FunctionAttrs, and if we're conservative about<br>
> escape, it would not add any additional expense. (Ff we do top-down<br>
> propagation for static functions (or more-generally for LTO), then<br>
> that could add overhead).<br>
><br>
><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > What if, for globals, we insisted that the global be named "errno"?<br>
> ><br>
> ><br>
> ><br>
> > I wouldn't be surprised if there was a system where the golbal<br>
> > error<br>
> > is not errno. Windows maybe?<br>
><br>
> Okay. We should check.<br>
><br>
><br>
><br>
> A Windows program can have two different global error numbers: Win32<br>
> and C-Runtime flavor.<br>
><br>
><br>
> The Win32 flavor is exposed via GetLastError/SetLastError[Ex]<br>
> The CRT flavor (errno) is, currently, exposed via a macro that<br>
> expands to (*_errno())<br>
><br>
><br>
><br>
><br>
> Thanks again,<br>
> Hal<br>
><br>
> ><br>
> ><br>
> > --renato<br>
><br>
><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div></div>