[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #42 from pinskia at gcc dot gnu dot org 2008-01-15 05:47 --- (In reply to comment #40) > This bug cause linux kernel unable to compile. So I think it must be fixed > before 4.3 is released Except there is two parts to this bug, first it is a bug in the linux kernel for not including this function. Second the GCC bug is that it produces less than optimal code but that should not be a blocker for GCC 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #41 from ismail at pardus dot org dot tr 2008-01-15 02:42 --- (In reply to comment #40) > This bug cause linux kernel unable to compile. So I think it must be fixed > before 4.3 is released Yes and there is a known workaround, see comment #28 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #40 from stevenyi at 163 dot com 2008-01-15 02:39 --- This bug cause linux kernel unable to compile. So I think it must be fixed before 4.3 is released -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #39 from mark at codesourcery dot com 2008-01-04 04:43 --- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use fche at redhat dot com wrote: >> Downgrading to P4. We seem to have consensus that this is [not] a GCC >> wrong-code >> bug. > > Yeah, it seems to be a mistaken expectation of -ffreestanding not to > call libgcc. Maybe a new option to that effect would help? I don't think there's a practical, platform-independent way for GCC to avoid calling libgcc. On some platforms, it has to do that for pretty basic operations. I think we just need to accept that the libgcc API is part of what's required by the compiler; you could imagine that it is "as-if" weak definitions of these functions were emitted in every assembly file by the compiler itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #38 from fche at redhat dot com 2008-01-04 03:19 --- (In reply to comment #37) > Downgrading to P4. We seem to have consensus that this is [not] a GCC > wrong-code > bug. Yeah, it seems to be a mistaken expectation of -ffreestanding not to call libgcc. Maybe a new option to that effect would help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #37 from mmitchel at gcc dot gnu dot org 2008-01-02 23:17 --- Downgrading to P4. We seem to have consensus that this is now a GCC wrong-code bug. I can't tell if we think this is an optimization bug or not; if we do think so, please bump this back to P3, with a test-case showing the poor optimization choice. I will review and upgrade to P2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #36 from pinskia at gcc dot gnu dot org 2007-12-26 01:29 --- *** Bug 33419 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bernds_cb1 at t-online dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #35 from mark at codesourcery dot com 2007-11-27 19:45 --- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use bunk at stusta dot de wrote: > Even if this specific issue in the kernel would turn out as a misoptimization, > the general problem would still remain waiting to pop up at some later time at > a different place. Indeed. However, I think that the kernel developers should be aware that GCC is not designed to avoid libgcc functions. GCC fundamentally assumes that it may call various functions from libgcc as it pleases. (Sometimes it may do so for good reasons, sometimes it may be that it does it suboptimally.) Because there's nothing in GCC to keep it from "randomly" calling libgcc functions, if the kernel wants to be robust against different versions of GCC, it should provide definitions of these functions. There's no easy way to make GCC avoid these functions. That's not meant to defend GCC calling this particular function in this particular circumstance, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #34 from jakub at gcc dot gnu dot org 2007-11-27 19:43 ---
I certainly agree with Mark here, we can talk whether on a particular arch
with particular options this transformation is a win or not, but when the
kernel
people decide to implement libgcc on their own and intentionally leave parts of
it out, they need to handle the consequences of that.
The addition of asm ("" : "+r" (nsec)); to the loop I suggested, perhaps hidden
in some macro, will act as an optimization barrier against it and won't (unlike
volatile) cost anything.
Even when the current scev-cprop transformation might not be a win in the case
of
__builtin_expect unlikely loop, the compiler e.g. could decide to transform
this into:
if (__builtin_expect (nsec < NSEC_PER_SEC, 1))
sec += nsec / NSEC_PER_SEC, nsec %= NSEC_PER_SEC;
or e.g.
if (__builtin_expect (nsec < NSEC_PER_SEC * 10, 1))
while (__builtin_expect (nsec > NSEC_PER_SEC, 0))
nsec -= NSEC_PER_SEC, sec++;
else
sec += nsec / NSEC_PER_SEC, nsec %= NSEC_PER_SEC;
which would still reference __udivdi3, but wouldn't be (measurably) slower in
case nsec is really small, yet would be much faster if nsec happens to be big.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #33 from rakdver at kam dot mff dot cuni dot cz 2007-11-27 19:42 --- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use > > --- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43 > > --- > > This is IMHO at most a QOI issue - at Novell we mark timespec_add_ns's u64 > > parameter as volatile to work around this issue. I expect upstream to adopt > > a workaround as well. Note that some targets in the kernel have parts of > > libgcc implemented, but i?86 misses at least __udivdi3. > > I am not a kernel developer, but my feeling as a GCC developer is that > you must provide the entry points in libgcc whenever you are linking > code compiled with GCC. In other words, that GCC should be free to use > functions from libgcc as it pleases. I would agree with this. Even if we somehow prevent gcc from using __udivdi3 in this particular case, there is no guarantee that gcc will not decide to use this or some other function from the libgcc runtime at some other place (unless we decide to have some kind of -dont-use-libgcc flag, which would however be a bit difficult to implement, and it would make us fail to compile some valid codes). > Of course, it might be a GCC optimization bug to call __udivdi3; perhaps > it could generate more efficient code that doesn't call that function. Definitely. It is particularly annoying that this is the case where the programmer went through the pain of avoiding the usage of division, just to have it "optimized" back in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #32 from bunk at stusta dot de 2007-11-27 19:31 --- (In reply to comment #30) >... > I am not a kernel developer, but my feeling as a GCC developer is that > you must provide the entry points in libgcc whenever you are linking > code compiled with GCC. In other words, that GCC should be free to use > functions from libgcc as it pleases. >... Status quo up to gcc 4.2 was that gcc did not use them in the kernel on i386. The root of the problem is that your feeling and what the kernel currently implements do not match, and some flamewars^Wdiscussions might be required for getting this sorted out in either gcc or the kernel... Even if this specific issue in the kernel would turn out as a misoptimization, the general problem would still remain waiting to pop up at some later time at a different place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #31 from bunk at stusta dot de 2007-11-27 19:16 --- (In reply to comment #29) > This is IMHO at most a QOI issue - at Novell we mark timespec_add_ns's u64 > parameter as volatile to work around this issue. I expect upstream to adopt > a workaround as well. Note that some targets in the kernel have parts of > libgcc implemented, but i?86 misses at least __udivdi3. The problem is that this is very fragile - imagine what might happen when a frequently used struct member gets changed from int to u64. After all, when looking at current practice, the kernel will support being built with gcc 4.3 until 2013 or 2014. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #30 from mark at codesourcery dot com 2007-11-27 18:58 --- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use rguenth at gcc dot gnu dot org wrote: > --- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43 > --- > This is IMHO at most a QOI issue - at Novell we mark timespec_add_ns's u64 > parameter as volatile to work around this issue. I expect upstream to adopt > a workaround as well. Note that some targets in the kernel have parts of > libgcc implemented, but i?86 misses at least __udivdi3. I am not a kernel developer, but my feeling as a GCC developer is that you must provide the entry points in libgcc whenever you are linking code compiled with GCC. In other words, that GCC should be free to use functions from libgcc as it pleases. Of course, it might be a GCC optimization bug to call __udivdi3; perhaps it could generate more efficient code that doesn't call that function. Do others agree? That this is at most an optimization issue, but not a correctness issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43 --- This is IMHO at most a QOI issue - at Novell we mark timespec_add_ns's u64 parameter as volatile to work around this issue. I expect upstream to adopt a workaround as well. Note that some targets in the kernel have parts of libgcc implemented, but i?86 misses at least __udivdi3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #28 from ismail at pardus dot org dot tr 2007-11-27 05:55 --- Mark, Linux 2.6 tree as of this minute doesn't compile with gcc 4.3 trunk. You need to add -fno-tree-scev-cprop to the KBUILD_CFLAGS, but this is not upstreamed yet and I am not sure if it'll be accepted in case it results in a performance regression. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #27 from mmitchel at gcc dot gnu dot org 2007-11-27 05:51 --- Ian, Diego, Richard G. -- I don't understand the state of this issue. Do we still think we have a problem that needs fixing in GCC? Has the Linux kernel worked around the issue? I'm interested both in knowing whether or not the compiler has a bug and, if it does, whether than affects current versions of the kernel. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #26 from ismail at pardus dot org dot tr 2007-11-20 21:19 --- *** Bug 34167 has been marked as a duplicate of this bug. *** -- ismail at pardus dot org dot tr changed: What|Removed |Added CC||ismail at pardus dot org dot ||tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #25 from bunk at stusta dot de 2007-11-10 07:41 --- Adding workarounds in all affected places in the kernel would be horribly fragile, but I've confirmed your -fno-tree-scev-cprop suggestion works around it and I'll submit a patch to the Linux kernel to use it with gcc 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #24 from rguenther at suse dot de 2007-11-09 17:11 --- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use On Fri, 9 Nov 2007, bunk at stusta dot de wrote: > --- Comment #23 from bunk at stusta dot de 2007-11-09 17:09 --- > We need a way to globally prevent it in the kernel or it will be a repeating > source of problems there. > > Is -fno-tree-scev-cprop a reasonable (and not too expensive) workaround for > the > Linux kernel? Yes, as is using volatile on this particular loop variable. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #23 from bunk at stusta dot de 2007-11-09 17:09 --- We need a way to globally prevent it in the kernel or it will be a repeating source of problems there. Is -fno-tree-scev-cprop a reasonable (and not too expensive) workaround for the Linux kernel? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #22 from rguenther at suse dot de 2007-11-09 16:33 --- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use On Fri, 9 Nov 2007, bunk at stusta dot de wrote: > --- Comment #21 from bunk at stusta dot de 2007-11-09 16:26 --- > Let's leave the right/wrong discussion and look at it more pragmatically: > > Could gcc get some kind of --expensive-libgcc flag that tells gcc that libgcc > calls are a bit more expensive than usually and should be avoided? While this is technically possible we already face stability and maintainability problems in other areas where we do so (for example the conditionally available C99 math has in the past lead to many internal compiler errors). So I would prefer not to go this route. Which does _not_ mean that we absolutely will not fix this issue and try to avoid creating final value replacement that involves a division/modulus. But as there exist multiple work-arounds for this issue, a nice and complete solution is certainly not very high priority. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #21 from bunk at stusta dot de 2007-11-09 16:26 --- Let's leave the right/wrong discussion and look at it more pragmatically: Could gcc get some kind of --expensive-libgcc flag that tells gcc that libgcc calls are a bit more expensive than usually and should be avoided? -- bunk at stusta dot de changed: What|Removed |Added CC||bunk at stusta dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-11-08 14:46 --- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use > --- Comment #19 from manu at gcc dot gnu dot org 2007-11-08 14:22 --- > (In reply to comment #16) > > One possible solution would be to annotate the division by the expected > > value > > of the result. Division expanders then may decide whether to expand to > > machine > > instruction/libcall or to check for small values of the result in if-guards > > first. > > > > Well, that won't achieve at all what the user wants, that is, to not get a > call > to __udividi3. However, it would avoid calling the division most of the time, i.e., for performance this would be a possible solution. > There are 2 issues here: > > 1) GCC replaces the loop by division. This may or may not be more efficient. > In > this case, it is not. In many other cases, it is. The code performing the replacement should probably check what is the expected # of iterations of the loop, and compute which way is more efficient. However, it is a bit difficult to get this work correctly. > 2) The user does not want a call to __udividi3. There is nothing wrong with calling __udividi3, once the division is introduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #19 from manu at gcc dot gnu dot org 2007-11-08 14:22 --- (In reply to comment #16) > One possible solution would be to annotate the division by the expected value > of the result. Division expanders then may decide whether to expand to > machine > instruction/libcall or to check for small values of the result in if-guards > first. > Well, that won't achieve at all what the user wants, that is, to not get a call to __udividi3. There are 2 issues here: 1) GCC replaces the loop by division. This may or may not be more efficient. In this case, it is not. In many other cases, it is. 2) The user does not want a call to __udividi3. If I understand correctly you need __udividi3 to do the division, am I wrong? Of course, you could "inline" it or link statically to avoid libgcc. The former will pessimize the code in most cases and the latter can be done by the user. Tricky. Is it possible to fix (2) without fixing (1)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #18 from manu at gcc dot gnu dot org 2007-11-08 13:47 --- (In reply to comment #4) > > (probably the condition check is too conservative > > so this isn't fully cooked yet): > > Way too conservative because even if you don't have the opcode, sometimes code > can be produced without calling the libcall. > If you change the define to: > #define NSEC_PER_SEC 0x1000UL > > You will not get an call udividi3, though there is still a divide in unsigned > long long, the division can be done exactly (via shifting). > Just to understand the issue better. Which pass/function is responsible to detect that the division can be done exactly and replace it by a shift? Can't this be checked when the result is computed and moved outside the loop? By the way, __builtin_expect generates a probability of >90% of exiting the loop. Shouldn't that be taken into account when moving anything outside the loop? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
