This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/32044] udivdi3 counterproductive, unwarranted use



------- Comment #3 from spark at gcc dot gnu dot org  2007-05-22 21:11 -------
(In reply to comment #0)
> First I am herewith re-afirming my formal request for Mr. Pinsk to refrain from
> having anything to do with my submissions.

Please refrain from insulting others.

> According to my (admittedly second hand (Fifth Edition of "C A Reference
> Manual"
> by Samuel P. Harbison III & Guy L. Stelle Jr) reading; GCC, by not providing a 
> means to disable the use of libgcc (including udivdi3) is not in strict 
> conformance with the C standard for free-standing use through C99. __udivdi3 is
> a reserved identifier 
> and hence non-conforming.

If you want to play the language laywer,
please read the C standard and tell me which clause this gcc behavior violates.

> As a 
> practical matter the use of __builtin_expect could be taken as signal to 
> allow only reordering of instructions (to avoid pipeline stalls and 
> reloading of caches) are to be avoided in the marked unlikely cases. Any 
> fundamental changes like exchanging a while and a subtraction for a
> non-hardware 
> divide should no occur

The meaning of __builtin_expect is as defined in the documentation.
This particular transformation has nothing to do with __builtin_expect.
The transformation happens regardless of __builtin_expect.

scev_const_prop eliminates the loop by replacing
the final value with an expression using divide.
Probably the right approach would be to prevent this from happening
ifthe final value expression looks expensive
(like DImode divide on targets without native DImode divide).


The following patch avoids the situation 
(probably the condition check is too conservative
so this isn't fully cooked yet):

diff -r f01bb94713f4 gcc/tree-scalar-evolution.c
--- a/gcc/tree-scalar-evolution.c       Mon May 14 13:52:18 2007 +0000
+++ b/gcc/tree-scalar-evolution.c       Tue May 22 20:09:08 2007 +0000
@@ -252,6 +252,9 @@ 02110-1301, USA.  */
 #include "tree-pass.h"
 #include "flags.h"
 #include "params.h"
+/* For optab access.  */
+#include "expr.h"
+#include "optabs.h"

 static tree analyze_scalar_evolution_1 (struct loop *, tree, tree);

@@ -2942,6 +2945,7 @@ scev_const_prop (void)
       edge exit;
       tree def, rslt, ass, niter;
       block_stmt_iterator bsi;
+      optab op;

       /* If we do not know exact number of iterations of the loop, we cannot
         replace the final value.  */
@@ -2957,6 +2961,10 @@ scev_const_prop (void)
         the elimination of the final value may reveal.  Therefore, we now
         eliminate the final values of induction variables unconditionally.  */
       if (niter == chrec_dont_know)
+       continue;
+      op = optab_for_tree_code (TREE_CODE (niter), TREE_TYPE (niter));
+      if (op->handlers[TYPE_MODE (TREE_TYPE (niter))].insn_code ==
CODE_FOR_nothing
+        && EDGE_FREQUENCY (exit) > 500)
        continue;

       /* Ensure that it is possible to insert new statements somewhere.  */


-- 

spark at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |spark at gcc dot gnu dot org


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]