Re: Bug in Instruction Combination procedure and RTL generation.

["J.J. Garcia" <stigmatedbrain at gmail dot com>]

El lun, 04-09-2006 a las 09:20 +0200, Paolo Bonzini escribiÃ:
> J.J. Garcia wrote:
> > Hi all,
> > 
> > I'm trying to debug a code optimization in gcc for an specific arch, to
> > be more explicit it's for gcc 2.95.3 for Metaware ARC target
> > architecture, i know the old release of compiler and i know there will
> > not be lot of support about it, anyway im keep on trying..., 
> 
> The "bug" is still there in the most recent version of GCC, but AFAIK (I 
>   speak RTL, but I don't speak ARC assembly) the optimization is ok.

First of all thx for fast reply and hints,

Sorry, what do you mean with "is still there"? which release/arc/bug-
entry at bugzilla is pointing the same? 'Couse if i compile on x86 as:

----
[root@sparkbox solvebug1]# gcc -o test bug1-prb04503-1-new.c
[root@sparkbox solvebug1]# ./test
[root@sparkbox solvebug1]# echo $?
0
[root@sparkbox solvebug1]# gcc -v
Leyendo especificaciones de /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configurado con: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Modelo de hilos: posix
gcc versiÃn 3.4.5 20051201 (Red Hat 3.4.5-2)
----

Initial condition is [ Test (9 >= 10)] and as expected in x86 the cmp is
being done correctly AFAIK with -O2:

08048368 <uifprb04503_A>:
 8048368:       55                      push   %ebp
 8048369:       89 e5                   mov    %esp,%ebp
 804836b:       83 7d 08 0a             cmpl   $0xa,0x8(%ebp)
 804836f:       19 c0                   sbb    %eax,%eax
 8048371:       83 e0 31                and    $0x31,%eax
 8048374:       83 c0 14                add    $0x14,%eax
 8048377:       c9                      leave
 8048378:       c3                      ret
 8048379:       8d 76 00                lea    0x0(%esi),%esi

0804837c <main>:
 804837c:       55                      push   %ebp
 804837d:       89 e5                   mov    %esp,%ebp
 804837f:       83 ec 08                sub    $0x8,%esp
 8048382:       83 e4 f0                and    $0xfffffff0,%esp
 8048385:       83 ec 10                sub    $0x10,%esp
 8048388:       6a 09                   push   $0x9
 804838a:       e8 d9 ff ff ff          call   8048368 <uifprb04503_A>
<...>

Sorry, prior to continue i forgot to include last line in ARC assembler
code for main function when calling to test-function (presetting 'r0'
value b4 fork to function, slight detail...):

0000010c <main>:
     10c:       04 3e 0e 10     100e3e04     st         blink,[sp,4]
     110:       00 36 0e 10     100e3600     st         fp,[sp]
     114:       00 38 6e 63     636e3800     mov        fp,sp
     118:       10 7e 8e 53     538e7e10     sub        sp,sp,16
     11c:       a0 f9 ff 2f     2ffff9a0     bl.d   ec <uifprb04503_A>
---> 120:       09 fe 1f 60     601ffe09     mov        r0,9

> 
> The change is from:
> 
> (set (reg:CC 61 cc)
>          (compare:CC (reg/v:SI 69 [ n ])
>              (const_int 9 [0x9])))
> (set (reg/v:SI 67 [ test_value ])
>          (if_then_else:SI (ltu (reg:CC 61 cc) (const_int 0 [0x0]))
>               (const_int 69 [0x45])
>               (reg:SI 71)))
> 
> 
> to
> 
> (set (reg:CC 61 cc)
>          (compare:CC (reg/v:SI 69 [ n ])
>              (const_int 8 [0x9])))
> (set (reg/v:SI 67 [ test_value ])
>          (if_then_else:SI (leu (reg:CC 61 cc) (const_int 0 [0x0]))
>               (const_int 69 [0x45])
>               (reg:SI 71)))
> 
> Testing < 9 is the same as testing <= 8.
> 
> The assembly seems also ok, since ".ls" is the translation of the "leu" 
> RTL code.  By comparison, "ltu" would become "c".

I think 'mov.ls' is correct, what is failing is to test against 8 in ARC
asm statement 'sub.f 0,r0,8' (update flags from 'r0 - 8' aritmetic
operation) it should be against 9:

000000ec <uifprb04503_A>:
      ec:       00 36 0e 10     100e3600     st         fp,[sp]
      f0:       00 38 6e 63     636e3800     mov        fp,sp
      f4:       08 7a e0 57     57e07a08     sub.f      0,r0,8
      f8:       14 fe 1f 60     601ffe14     mov        r0,20
      fc:       0e 7c 1f 60     601f7c0e     mov.ls     r0,69

See comparison in function:

unsigned int
uifprb04503_A (unsigned int n)
{
  unsigned int test_value = 69;

  if ( n >= SINGULARP )
  {
     test_value = 20;
  }

  return test_value;
}

What is expected is:
if n >= 10 ---> return 20
   n < 10  ---> return 69
or
   n <= 9 (adapted to be used with .ls) 

What is obtained from objdump is:
if n <= 8 <--- (mov.ls) --> 69
   n >  8 ----------------> return 20
or
   n >= 9 (deduced, bad then against original)

And if i understand correctly from RTL:

(const_int 9 + ltu) is optimized to (const_int 8 + leu)

Which as you say is correct, but:

should not it be 10 instead 9?

Attached the full .rtl (i think it's the initial approach output from
gcc), the .flow and .combine files


TIA

Jose.


> 
> While unexpected, this change is done by GCC as part of "canonicalizing" 
> expressions so that, for example, it could detect that "<= 8" and "< 9" 
> are really testing the same condition.
> 
> All this said, remember that the correct place to report a bug is the 
> GCC bugzilla at http://gcc.gnu.org/bugzilla
> 
> Paolo

Attachment: bug1-prb04503-1-new.c.rtl
Description: Text document

Attachment: bug1-prb04503-1-new.c.combine
Description: Text document

Attachment: bug1-prb04503-1-new.c.flow
Description: Text document