4 ms·

But they only change their mind for this particular code, because it is part of a benchmark, which is the kind of code they supports instead of useful one.

by temac 11y ago

DannyBee 11y ago
This is Anton's view of the situation, and not an actual one AFAICT :) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 What really happened: It was diagnosed, and they produced a fix for the spec source code. SPEC said it does not plan to offer the fix. So they then went and said "okay, i guess we'll try to add an option to give people a chance to have this random crap work". The flag was added to disable this assumption so people could use it if they need it. I'm not sure what better response you want from developers than that. Nowhere, in any of the bug report, will you see someone say "yeah, we gotta make sure this still works because it's a benchmark". They treat it like any other undefined behavior bug, and say "that's undefined behavior". you can look through the bug database and find literally tens of thousands of cases where they say that, benchmarks, non-benchmarks, etc. They do it whether it's important for optimization or not. It's really pretty consistent. So taking this example and extrapolating that the only reason it was done is because it's a benchmark is, well, pretty typical of this author :)
- x0x0 11y ago
  Would it have gotten a special flag if it were not a SPEC benchmark? I read that as Anton's point.
  - DannyBee 11y ago
    Yes. It would have.
    - x0x0 11y ago
      well, that does make him seem a tad unreasonable then
    - AntonErtl 11y ago
      The "optimization" was added and turned on by default (for some higher optimization levels) in a pre-release of gcc-4.8. After it turned out to miscompile SPEC, they disabled it for the case occuring there (it still seems to be on by default for other cases); it was disabled in released gcc-4.8 and all following gcc versions. When I asked a gcc maintainer about that, he wrote that it turned out that this "optimization" did not really provide a significant performance benefit; I asked how they evaluated that and he wrote that they used a set of relevant benchmarks. I have seen little reluctance by the gcc maintainers in enabling "optimizations" by default, even if they miscompile real-world programs. My conclusion is that SPEC has a special status among gcc maintainers, but draw your own conclusions.
      - DannyBee 11y ago
        This optimization has been around a long time. You are wrong about the timeline, it was added in 2012 well before the 4.8 branch point (it's closer to the 4.7 timeline). It was not added in a pre-release of gcc 4.8, and it was actually added to target some common cases. And in fact, it existed before then in other forms (I can point you at code back to 2004 doing the same thing). It has been on by default there for a long time. It happened to not miscompile SPEC before then by luck. ". After it turned out to miscompile SPEC, they disabled it for the case occuring there (it still seems to be on by default for other cases);" No, it was not. It is on by default for all cases, AFAICT. Please point to the patch you think disabled it. " it was disabled in released gcc-4.8 and all following gcc versions." Again, i don't see a patch that does this. If this has happened, i imagine it's not on purpose. Here's the current state of this optimization: from https://gcc.gnu.org/svn/gcc/trunk/gcc/common.opt https://gcc.gnu.org/svn/gcc/trunk/gcc/common.opt faggressive-loop-optimizations Common Report Var(flag_aggressive_loop_optimizations) Optimization Init(1) Aggressively optimize loops using language constraints. The Init(1) means it's on by default. Note it is mentioned in the release notes for 4.8, for all versions: https://gcc.gnu.org/gcc-4.8/changes.html https://gcc.gnu.org/gcc-4.8/changes.html Nowhere will you see something that says it is not the default, or will you see changes mentioning the default was changed. " When I asked a gcc maintainer about that, he wrote that it turned out that this "optimization" did not really provide a significant performance benefit; I asked how they evaluated that and he wrote that they used a set of relevant benchmarks." Which "gcc maintainer" did you ask? I ask because i'm a listed maintainer for the SCEV related optimizations (see https://gcc.gnu.org/svn/gcc/trunk/MAINTAINERS https://gcc.gnu.org/svn/gcc/trunk/MAINTAINERS) and you didn't ask me :) I asked Sebastian as well, and you didn't ask him. While compiler vendors do target SPEC, GCC generally does not, and in fact, has pretty much repeatedly refused optimizations that are only useful for SPEC. FYI: putting optimization in quotes repeatedly does not help your case.

But they only change their mind for this particular code, because it is part of a benchmark, which is the kind of code they supports instead of useful one.

by temac 11y ago

But they only change their mind for this particular code, because it is part of a benchmark, which is the kind of code they supports instead of useful one.

DannyBee 11y ago

This is Anton's view of the situation, and not an actual one AFAICT :) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 What really happened: It was diagnosed, and they produced a fix for the spec source code. SPEC said it does not plan to offer the fix. So they then went and said "okay, i guess we'll try to add an option to give people a chance to have this random crap work". The flag was added to disable this assumption so people could use it if they need it. I'm not sure what better response you want from developers than that. Nowhere, in any of the bug report, will you see someone say "yeah, we gotta make sure this still works because it's a benchmark". They treat it like any other undefined behavior bug, and say "that's undefined behavior". you can look through the bug database and find literally tens of thousands of cases where they say that, benchmarks, non-benchmarks, etc. They do it whether it's important for optimization or not. It's really pretty consistent. So taking this example and extrapolating that the only reason it was done is because it's a benchmark is, well, pretty typical of this author :)

x0x0 11y ago
Would it have gotten a special flag if it were not a SPEC benchmark? I read that as Anton's point.
- DannyBee 11y ago
  Yes. It would have.
  - x0x0 11y ago
    well, that does make him seem a tad unreasonable then
  - AntonErtl 11y ago
    The "optimization" was added and turned on by default (for some higher optimization levels) in a pre-release of gcc-4.8. After it turned out to miscompile SPEC, they disabled it for the case occuring there (it still seems to be on by default for other cases); it was disabled in released gcc-4.8 and all following gcc versions. When I asked a gcc maintainer about that, he wrote that it turned out that this "optimization" did not really provide a significant performance benefit; I asked how they evaluated that and he wrote that they used a set of relevant benchmarks. I have seen little reluctance by the gcc maintainers in enabling "optimizations" by default, even if they miscompile real-world programs. My conclusion is that SPEC has a special status among gcc maintainers, but draw your own conclusions.
    - DannyBee 11y ago
      This optimization has been around a long time. You are wrong about the timeline, it was added in 2012 well before the 4.8 branch point (it's closer to the 4.7 timeline). It was not added in a pre-release of gcc 4.8, and it was actually added to target some common cases. And in fact, it existed before then in other forms (I can point you at code back to 2004 doing the same thing). It has been on by default there for a long time. It happened to not miscompile SPEC before then by luck. ". After it turned out to miscompile SPEC, they disabled it for the case occuring there (it still seems to be on by default for other cases);" No, it was not. It is on by default for all cases, AFAICT. Please point to the patch you think disabled it. " it was disabled in released gcc-4.8 and all following gcc versions." Again, i don't see a patch that does this. If this has happened, i imagine it's not on purpose. Here's the current state of this optimization: from https://gcc.gnu.org/svn/gcc/trunk/gcc/common.opt https://gcc.gnu.org/svn/gcc/trunk/gcc/common.opt faggressive-loop-optimizations Common Report Var(flag_aggressive_loop_optimizations) Optimization Init(1) Aggressively optimize loops using language constraints. The Init(1) means it's on by default. Note it is mentioned in the release notes for 4.8, for all versions: https://gcc.gnu.org/gcc-4.8/changes.html https://gcc.gnu.org/gcc-4.8/changes.html Nowhere will you see something that says it is not the default, or will you see changes mentioning the default was changed. " When I asked a gcc maintainer about that, he wrote that it turned out that this "optimization" did not really provide a significant performance benefit; I asked how they evaluated that and he wrote that they used a set of relevant benchmarks." Which "gcc maintainer" did you ask? I ask because i'm a listed maintainer for the SCEV related optimizations (see https://gcc.gnu.org/svn/gcc/trunk/MAINTAINERS https://gcc.gnu.org/svn/gcc/trunk/MAINTAINERS) and you didn't ask me :) I asked Sebastian as well, and you didn't ask him. While compiler vendors do target SPEC, GCC generally does not, and in fact, has pretty much repeatedly refused optimizations that are only useful for SPEC. FYI: putting optimization in quotes repeatedly does not help your case.