[Bug rtl-optimization/24760] New: -d option changes generated code

[Bug rtl-optimization/24760] New: -d option changes generated code

[amylaar at gcc dot gnu dot org]

When compiling some files, the -da option or - AFAICT - any of its constituent
options changes the generated code.  When using -da, the -quiet option can also
have an effect on the generated code, although this is harder to demonstrate.


-- 
           Summary: -d option changes generated code
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: amylaar at gcc dot gnu dot org


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

[Bug rtl-optimization/24760] -d option changes generated code

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-09 18:52 -------
Most (if not all) of these issues are usually a pass depending on addresses
being the same.
I think David E. has a bug filed about one of these issues already.


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[amylaar at gcc dot gnu dot org]

------- Comment #2 from amylaar at gcc dot gnu dot org  2005-11-09 18:59 -------
Created an attachment (id=10191)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10191&action=view)
test case

Mainline version 106440 configured for i686-pc-linux-gnu --with-arch=i686:
../../i686/gcc/cc1  -fpreprocessed cse.i -quiet  -g -O2   -o t.s-i0
produces different output than
../../i686/gcc/cc1  -fpreprocessed cse.i -quiet  -g -O2   -o t.s-i1 -da
or
../../i686/gcc/cc1  -fpreprocessed cse.i -quiet  -g -O2   -o t.s-ik -dk


Mainline version 106440 configured for sh-elf:
/mnt/scratch/nightly/2005-11-03/sh-elf/gcc/cc1 -fpreprocessed cse.i -quiet -m4 
-g -O2   -o t.s-0
produces different code than:
/mnt/scratch/nightly/2005-11-03/sh-elf/gcc/cc1 -fpreprocessed cse.i -quiet -m4 
-g -O2   -o t.s-1 -da


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[amylaar at gcc dot gnu dot org]

------- Comment #3 from amylaar at gcc dot gnu dot org  2005-11-09 19:08 -------
Created an attachment (id=10192)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10192&action=view)
test case

This is a shorter test case, but only debug information changes were observed
for this test case.  configured for i686-pc-linux-gnu or for sh-elf, compare
the output of:
./cc1 -fpreprocessed -g -O2  l0.c -o l0.s-0 
with:
./cc1 -fpreprocessed -g -O2  l0.c -o l0.s-1  -da


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[amylaar at gcc dot gnu dot org]

------- Comment #4 from amylaar at gcc dot gnu dot org  2005-11-09 19:35 -------
I have observed the -quiet influence only with a proprietary testcase so far
(EEMBC aiifft01/bmark.c for sh-elf -m4 -ml -g -O3 -version -fomit-frame-pointer
-funroll-loops --param max-inline-insns-single=50000).
Compiling with -da -quiet generally makes this code smaller than compiling with
-quiet only, but with a probability of about 1/5th -da -quiet produces larger
code.
-da without -quiet generally produces code that is larger than any of the above
scenarios, but sometimes it produces identical code to -quiet (without -da).


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[amylaar at gcc dot gnu dot org]

------- Comment #5 from amylaar at gcc dot gnu dot org  2005-11-09 20:56 -------
(In reply to comment #4)
> -da without -quiet generally produces code that is larger than any of the above
> scenarios, but sometimes it produces identical code to -quiet (without -da).
> 

I have now captured four different sets of debugging dumps (with different
code generated) for -da, and the first dump where they differ in things other
than mere pointers is 21.loop2_unroll .  Allocation of registers that
appear new in this dump appears to be different.

I think these statements are to blame:

 87487    rakdver   /* Allocate the basic variables (i0).  */
 89197      hagog   if (opt_info->insns_to_split)
 89197      hagog     htab_traverse (opt_info->insns_to_split,
allocate_basic_va

 89197      hagog   if (opt_info->insns_with_var_to_expand)
 89197      hagog     {
 89197      hagog       htab_traverse (opt_info->insns_with_var_to_expand, 
 89197      hagog                      insert_var_expansion_initialization, 
 89197      hagog                      opt_info->loop_preheader);
 89197      hagog       htab_traverse (opt_info->insns_with_var_to_expand, 
 89197      hagog                      combine_var_copies_in_loop_exit, 
 89197      hagog                      opt_info->loop_exit);
 89197      hagog     }

Unless you want to sort the insns that are found during a hash table traversal,
you have to fix the hash functions to be address-independent.
I think ve_info_hash and si_info_hash should use the uid of the insn rather
than its address.


-- 

amylaar at gcc dot gnu dot org changed:

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


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

[Bug rtl-optimization/24760] -d option changes generated code

[rakdver at gcc dot gnu dot org]

------- Comment #6 from rakdver at gcc dot gnu dot org  2005-11-09 22:36 -------
Yes, this is indeed the case.  I am testing the fix.


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[joern dot rennecke at st dot com]

------- Comment #7 from joern dot rennecke at st dot com  2005-11-10 14:11 -------
Subject: Re:  -d option changes generated code

rakdver at gcc dot gnu dot org wrote:

>------- Comment #6 from rakdver at gcc dot gnu dot org  2005-11-09 22:36 -------
>Yes, this is indeed the case.  I am testing the fix.
>
>
>  
>
I've tested the attached patch on i686-pc-linux-gnu native, X sh-elf and 
X sh64-elf.  No new regressions
except for a few more compilation timeouts for sh-elf and sh64-elf on 
borderline tests, i.e.
gcc.c-torture/compile/20001226-1.c, gcc.dg/c99-intconst-1.c and 
g++.dg/eh/cleanup1.C (I did the baseline
under lower load).

2005-11-10  J"orn Rennecke <joern.rennecke@st.com>

        * loop-unroll.c (si_info_hash, ve_info_hash): Use INSN_UID for hash.

Index: loop-unroll.c
===================================================================
--- loop-unroll.c       (revision 106440)
+++ loop-unroll.c       (working copy)
@@ -1475,7 +1475,7 @@
 static hashval_t
 si_info_hash (const void *ivts)
 {
-  return htab_hash_pointer (((struct iv_to_split *) ivts)->insn);
+  return (hashval_t) INSN_UID (((struct iv_to_split *) ivts)->insn);
 }

 /* An equality functions for information about insns to split.  */
@@ -1494,7 +1494,7 @@
 static hashval_t
 ve_info_hash (const void *ves)
 {
-  return htab_hash_pointer (((struct var_to_expand *) ves)->insn);
+  return (hashval_t) INSN_UID (((struct var_to_expand *) ves)->insn);
 }

 /* Return true if IVTS1 and IVTS2 (which are really both of type 


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[pinskia at physics dot uc dot edu]

------- Comment #8 from pinskia at gcc dot gnu dot org  2005-11-10 14:17 -------
Subject: Re:  -d option changes generated code

> 
> This is a multi-part message in MIME format.
> --------------070507020407080301090707
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> rakdver at gcc dot gnu dot org wrote:
> 
> >------- Comment #6 from rakdver at gcc dot gnu dot org  2005-11-09 22:36 -------
> >Yes, this is indeed the case.  I am testing the fix.
> >
> I've tested the attached patch on i686-pc-linux-gnu native, X sh-elf and 
> X sh64-elf.  No new regressions
> except for a few more compilation timeouts for sh-elf and sh64-elf on 
> borderline tests, i.e.
> gcc.c-torture/compile/20001226-1.c, gcc.dg/c99-intconst-1.c and 
> g++.dg/eh/cleanup1.C (I did the baseline
> under lower load).
> 
> 
> --------------070507020407080301090707
> Content-Type: text/plain;
>  name="tmp"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="tmp"
> 
> 2005-11-10  J"orn Rennecke <joern.rennecke@st.com>
> 
> 	* loop-unroll.c (si_info_hash, ve_info_hash): Use INSN_UID for hash.

This seems like the correct way to fix this.

-- Pinski


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2005-11-10 14:45 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-11-10 14:45:58
               date|                            |


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

[Bug rtl-optimization/24760] -d option changes generated code

[amylaar at gcc dot gnu dot org]

------- Comment #10 from amylaar at gcc dot gnu dot org  2005-11-11 13:39 -------
(In reply to comment #1)
> Most (if not all) of these issues are usually a pass depending on addresses
> being the same.
> I think David E. has a bug filed about one of these issues already.
> 

I've tried to search bugzilla for edelsohn and dje@ibm, but came up empty
each time.
The patch I posted appears to fix the different-code issues, but there is still
an issue with random debug information layout.  I would like to spin off the
random debug info issue into a separate PR - an old one if you can find a
matching one, otherwise we'll have to open a new one.  Whith PR24760 narrowed
to the random code issue from unrolling, we can progress it as having a
tested patch to fix it, i.e. set the patch keyword and the patch URL field.


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2005-11-11 15:37 -------
(In reply to comment #10)
> (In reply to comment #1)
> > Most (if not all) of these issues are usually a pass depending on addresses
> > being the same.
> > I think David E. has a bug filed about one of these issues already.
> > 
> I've tried to search bugzilla for edelsohn and dje@ibm, but came up empty
> each time.

dje@watson.ibm.com, PR 4520.


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[amylaar at gcc dot gnu dot org]

------- Comment #12 from amylaar at gcc dot gnu dot org  2005-11-11 16:32 -------
(In reply to comment #11)
 > dje@watson.ibm.com, PR 4520.

Thanks.  This PR is indeed about a different issue, so I have opened
PR24801 to track the debug info issue.


-- 


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

[Bug rtl-optimization/24760] -d option changes generated code

[amylaar at gcc dot gnu dot org]

------- Comment #13 from amylaar at gcc dot gnu dot org  2006-11-15 16:08 -------
This might be fixed now, but somebody should check before this PR is closed.


-- 

amylaar at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |29842
              nThis|                            |


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