On Fri, Apr 5, 2013 at 6:49 PM, Joe Groff <arcata at gmail.com> wrote: ... The platform is irrelevant; division by zero is undefined, and compilers> are allowed to optimize as if it can't happen. >Understood. I don't mean to nag, but I'm not arguing which is [more] correct: the Standards or the platform. Both have their own merits. At least to me they both have merits. The choice should be up to the compiler implementor. And, I would like to see LLVM make that choice easy for the compiler implementor. Maybe an anachronism, but there is some history of this option being built-in to other major compilers: GNU, Sun, HP, IBM, SGI, Compaq, etc. But, if others can not (or will not) benefit from this option, I will not force my individual needs on the whole. Both gcc and clang will lift the division out of this loop, for example,> causing the hardware trap to happen in the "wrong" place if bar is passed > zero: > > void foo(int x, int y); > > void bar(int x) { > for (int i = 0; i < 100; ++i) { > foo(i, 200/x); > } > } >I'm less concerned about "where" the trap happens as I am about "if" it happens. For example, a Fortran program with division-by-zero is, by the Standard, non-conforming. Pragmatically, not a Fortran program. Rather than wrong answers, I would like to see a hard error indicating that a program is non-conforming to the Standard. -Cameron>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130405/62181469/attachment.html>
On Apr 5, 2013, at 8:02 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote:> I'm less concerned about "where" the trap happens as I am about "if" it happens. For example, a Fortran program with division-by-zero is, by the Standard, non-conforming. Pragmatically, not a Fortran program. Rather than wrong answers, I would like to see a hard error indicating that a program is non-conforming to the Standard.As I've pointed out, clang does provide such functionality as an opt-in feature through its -fsanitize options. A hypothetical Fortran frontend could do the same, and even make it an opt-out feature if it chose. I'm sorry if its implementation mechanism doesn't match exactly what you want it to be, but it's not like nobody else has thought about this problem. They have, and they've designed and shipped a solution! Side note: even if the -fsanitize option introduces a branch around the division (which I haven't verified), it's quite unlikely to cause a significant performance regression. The branch to the error block should be perfectly predicted on any CPU made in the last 25 years. --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130405/9ff6913f/attachment.html>
I'm also not fully happy with LLVM's behavior here. There is another undefined case too, which is the minimum integer divided by -1. In Julia I can get "random" answers by doing: julia> sdiv_int(-9223372036854775808, -1) 87106304 julia> sdiv_int(-9223372036854775808, -1) 87108096 In other contexts where the arguments are not constant, this typically gives an FPE trap. More than insisting on a particular behavior, I'd like it to be consistent. I know the result is undefined, so LLVM's behavior here is valid, but I find that to be an overly lawyerly interpretation. Presumably the optimizer benefits from taking advantage of the undefined behavior, but to get a consistent result you need to check for both zero and this case, which is an awful lot of checks. Yes they will branch predict well, but this still can't be good, for code size if nothing else. How much performance can you really get by constant folding -9223372036854775808/-1 to an unspecified value? On Sat, Apr 6, 2013 at 1:18 AM, Owen Anderson <resistor at mac.com> wrote:> > On Apr 5, 2013, at 8:02 PM, Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > > I'm less concerned about "where" the trap happens as I am about "if" it > happens. For example, a Fortran program with division-by-zero is, by the > Standard, non-conforming. Pragmatically, not a Fortran program. Rather than > wrong answers, I would like to see a hard error indicating that a program is > non-conforming to the Standard. > > > As I've pointed out, clang does provide such functionality as an opt-in > feature through its -fsanitize options. A hypothetical Fortran frontend > could do the same, and even make it an opt-out feature if it chose. I'm > sorry if its implementation mechanism doesn't match exactly what you want it > to be, but it's not like nobody else has thought about this problem. They > have, and they've designed and shipped a solution! > > Side note: even if the -fsanitize option introduces a branch around the > division (which I haven't verified), it's quite unlikely to cause a > significant performance regression. The branch to the error block should be > perfectly predicted on any CPU made in the last 25 years. > > --Owen > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Hey Owen, Thanks for your reply. I definitely understand your perspective. Hopefully I can change it. }:-) On Sat, Apr 6, 2013 at 1:18 AM, Owen Anderson <resistor at mac.com> wrote: ...> As I've pointed out, clang does provide such functionality as an opt-in > feature through its -fsanitize options. A hypothetical Fortran frontend > could do the same, and even make it an opt-out feature if it chose. I'm > sorry if its implementation mechanism doesn't match exactly what you want > it to be, but it's not like nobody else has thought about this problem. > They have, and they've designed and shipped a solution! > > Side note: even if the -fsanitize option introduces a branch around the > division (which I haven't verified), it's quite unlikely to cause a > significant performance regression. The branch to the error block should > be perfectly predicted on any CPU made in the last 25 years. > >Even on a Xeon Phi? Just kidding around! All kidding aside, an instruction is an instruction. We have the functionality in hardware for free; it would be a shame not to use it. I should also mention that for our team, performance is job #1. Extra instructions, however insignificant, don't go over well without solid justification. Please don't misunderstand, I'm not trying to be unreasonable about this behaviour change. I do believe that there are a few strong arguments for this behaviour that we haven't touched upon yet. I also believe that this option would be an improvement to LLVM overall. But, I also haven't heard anyone in the community voicing interest. So, if no one speaks up and would like to discuss further, I'll be happy to keep such a change in my local branch. -Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130406/c66185f3/attachment.html>
Owen Anderson <resistor at mac.com> writes:> As I've pointed out, clang does provide such functionality as an > opt-in feature through its -fsanitize options. A hypothetical Fortran > frontend could do the same, and even make it an opt-out feature if it > chose. I'm sorry if its implementation mechanism doesn't match > exactly what you want it to be, but it's not like nobody else has > thought about this problem. They have, and they've designed and > shipped a solution!The problem with a clang implementation is that not everyone uses clang. It sure would be nice to have an option that could be set to not constant fold traps away. Then it would be easy for implementors to just set that option if they want. This is an optimization/codegen issue so it seems to me the fix ought to be there, not in the frontend. Is there great harm in adding an option here? -David