[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel

["malitzke at metronets dot com" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6419 bytes --]



------- Comment #12 from malitzke at metronets dot com  2007-06-28 03:53 -------
Mr Pinski! Thanks for again doing the work for me.

I just had to take some time out for my annual checkup and to rebuild my big
machine's software after Gentoo on shutdown -h now deleted my /bin, /etc, and
/sbin directories. Luckkily Volkering is back in good health and completely
revamped slackware. I do not use redhat because they try to force down my
throat
Gnome and I do not use SUSe because they try to do the same thing with KDE. 

I hope the somewhat out of context quotes you provide come from the the real
spec and not the preliminary copy available on the net. GCC should have the
real spec, while I can find better use for my money. 

Now to your first sentence in comment 11:

The support obligation (contrary to that sentence is levied on the conforming
implementation and not on the conforming program. Now let us go the the real
issue namely the transformation of  unsigned long (not unsigned long long as in
my toy program) minuend and subtrahend subtraction into a 64 bit udivdi3. The
proof of my assertion lies in the fact that for a 64 bit machine the issue
never arises. I, certainly can not speak for Mr. Torvalds, he certainly doe not
need my help, but speaking for myself if find it preposterous a clearly faulty
interpretation of the standard used to ram down __my__ throat a transformation
from a clearly specified subtraction into a udivdi3 division. 

The erroneous interpretation stems from a complete ignorance (feigned or
actual)
of a non reflexive relation between program (this is the part missing from your
quote) and implementation into a reflexive. or, worse, equivalence relation.

I never disputed the fact that under the standard even the free-standing
implementation has an obligation to to provide udivdi3 for 32 bit machines. You 
disclosed your ignorance or, worse, morally questionable (your choice)
disregard for the real issue, namely trying to cover up a grave deficiency
(bug) in the GNU C compiler by specious arguments in using a division, instead
of the subtraction in your comment 1. If I or the kernel people had specified
an actual division,  instead of a carefully circumscribed subtraction we would
have gotten what we deserved.   

Yes, Mr Morton, looked for alternatives in order to avoid a confrontation, I am
not as conciliatory. In my opinion Mr. Torvalds hit the nail right on the head.
As an aside, I am not your messenger boy to propagate your ignorance or
maliciousness to third parties.

If this goes unchallenged the next possible result could be as follows:

Some GCC maintainer, claiming register pressure would resort to the following:
All Pentium CPU's have a floating point unit and there exists an integer load
and store operation for that floating point unit. Last time I looked floating
register, plus flags, save and restore are not atomic hence reentrancy goes
down the drain which potentially fatal results. 

The remainder clearly shows that some members of the GCC community agree that I
as a user have right to avoid having this inane substitution rammed down my
throat. Unfortunately thei proposed remedies either do not work or do not avoid
the real issue:

It would of course be easy to prevent the optimization by declaring nsec to be
volatile.  The question is whether the compiler can reasonably determine that
the optimization is inappropriate in this particular case.

Richard Guenther

an optimization issue and __udivdi3 can be
avoided
by using volatile as stated and verified.

  Manuel López-Ibáñez

Isn't there a way for __builtin_expect to modify this behaviour? After all, it
is telling us that the loop is cheap. And the difference in computation time is
not trivial at all.

The volatile fix would be fine, but (at least for me) does not work with the
kernel. There is that little message:

kernel/time.c:479: warning: passing argument 3 of 'div_long_rem_signed'
discards qualifiers from pointer target type.

and others like it, and, udivdi3 reappears.



Thank you (muchas gracias) for looking at the matter from a user's point of
view and considering my arguments concerning __builtin_expect. You seem to be
the first to look at the timings and amount of code generated. If you are
interested I have equivalent data taken on a MAC with dual G4's. I did not send
it so far because until you intervened I got mostly legalistic arguments and
proposed fixes that do no solve the real problem of avoiding both udivdi3 and
more importantly libgcc.

 Richard Guenther 

So this is now an enhancement request for sccp to honor loop roll count or
basic-block frequency and cost of the replacement.  Note the loop appears to be
peeled twice before sccp already, but peeling doesn't decay probabilities
further.

Testcase:

int rmg(unsigned long long nsec)
{
   int sec = 0;
   nsec++;
   while (__builtin_expect(nsec >= 1000000000UL, 0)) {
      nsec -= 1000000000UL;
      ++sec;
   }
   return sec;
}

note this can be worked around with -fno-tree-scev-cprop as well.

Manuel López-Ibáñez 


The flag just disables an optimisation. If you want to disable optimisations
just  use -O0. On the other hand, shouldn't -ffreestanding prevent udivdi3 ?
What about -fno-builtin-udivdi3 ?

Zdenek Dvorak


we used to take the cost of the replacement into account.  It caused so many
missed-optimization PRs that I decided to just disable it.  The main problem is
that while theoretically you can determine whether replacement is more costly
then performing the computation in the loop (although even this is nontrivial
in practice), it is very difficult to estimate the gains of enabling further
optimizations.

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.








-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494