public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/95685] New: Loop invariants can't be moved out of the loop
@ 2020-06-15 15:47 bina2374 at gmail dot com
  2020-06-16  0:31 ` [Bug tree-optimization/95685] " wilson at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: bina2374 at gmail dot com @ 2020-06-15 15:47 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95685

            Bug ID: 95685
           Summary: Loop invariants can't be moved out of the loop
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bina2374 at gmail dot com
                CC: kito at gcc dot gnu.org, wilson at gcc dot gnu.org
  Target Milestone: ---
            Target: riscv32-unknown-elf

Command line: bin/riscv64-unknown-elf-gcc -march=rv32imafc -mabi=ilp32f -O2
-funroll-loops bar.c -S

==========
 C Source
==========
unsigned short bar(unsigned char data, unsigned short crc) {
  unsigned char i = 0;

  for (i = 0; i < 3; i++) {
    data >>= 1;
    if ((data & 1) == 1)
      crc ^= 0x2001;
  }
  return crc;
}

=========
 GCC asm
=========
bar:
        srli    a4,a0,1
        andi    t0,a4,1
        mv      a5,a0
        mv      a0,a1
        beq     t0,zero,.L2
        li      t1,8192     #
        addi    t2,t1,1     # 0x2001
        xor     a0,a1,t2
.L2:
        srli    a1,a5,2
        andi    a2,a1,1
        beq     a2,zero,.L3
        li      a3,8192     #
        addi    a6,a3,1     # 0x2001
        xor     a0,a0,a6
.L3:
        srli    a7,a5,3
        andi    t3,a7,1
        beq     t3,zero,.L4
        li      t4,8192     #
        addi    t5,t4,1     # 0x2001
        xor     a0,a0,t5
.L4:
        ret

If I compile it without -funroll-loops, loop invariant code motion works:
bar:
        li      a2,8192     #
        mv      a4,a0
        li      a5,3
        mv      a0,a1
        addi    a2,a2,1     # 0x2001
.L3:
        srli    a4,a4,1
        addi    a5,a5,-1
        andi    a3,a4,1
        andi    a5,a5,0xff
        beq     a3,zero,.L2
        xor     a0,a0,a2
.L2:
        bne     a5,zero,.L3
        ret

I guess the problem is the order of optimization passes.
Because cunroll pass makes the loop no longer a loop, loop2_invariant can't
work on it.

=======================
 Ideal Code Generation 
=======================
bar:
        srli    a4,a0,1
        andi    t0,a4,1
        mv      a5,a0
        mv      a0,a1
        li      t1,8192     #
        addi    t2,t1,1     # t2 = 0x2001
        beq     t0,zero,.L2
        xor     a0,a1,t2
.L2:
        srli    a1,a5,2
        andi    a2,a1,1
        beq     a2,zero,.L3
        xor     a0,a0,t2    # Use t2
.L3:
        srli    a7,a5,3
        andi    t3,a7,1
        beq     t3,zero,.L4
        xor     a0,a0,t2    # Use t2
.L4:
        ret

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug tree-optimization/95685] Loop invariants can't be moved out of the loop
  2020-06-15 15:47 [Bug tree-optimization/95685] New: Loop invariants can't be moved out of the loop bina2374 at gmail dot com
@ 2020-06-16  0:31 ` wilson at gcc dot gnu.org
  2020-06-16  6:36 ` rguenth at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: wilson at gcc dot gnu.org @ 2020-06-16  0:31 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95685

--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
The problem with the constant isn't apparent until we reach RTL generation and
see that it requires two instructions to load.  Then once in RTL optimization
passes we have mostly block local optimizations that aren't going to notice the
same constant used in 3 different blocks and optimize it.  The if statement
inside the unrolled loop bodies prevent RTL optimization passes from fixing
this.  So yes, this would work better if we could do loop invariant code motion
before loop unrolling as you suggested.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug tree-optimization/95685] Loop invariants can't be moved out of the loop
  2020-06-15 15:47 [Bug tree-optimization/95685] New: Loop invariants can't be moved out of the loop bina2374 at gmail dot com
  2020-06-16  0:31 ` [Bug tree-optimization/95685] " wilson at gcc dot gnu.org
@ 2020-06-16  6:36 ` rguenth at gcc dot gnu.org
  2020-06-16  6:37 ` [Bug rtl-optimization/95685] " rguenth at gcc dot gnu.org
  2021-05-30 22:31 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-06-16  6:36 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95685

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I wonder why CSE2 (after loop) does not catch the redundancies at least.  Hmm,
guess EBB is too local?  But then there's gcse2?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug rtl-optimization/95685] Loop invariants can't be moved out of the loop
  2020-06-15 15:47 [Bug tree-optimization/95685] New: Loop invariants can't be moved out of the loop bina2374 at gmail dot com
  2020-06-16  0:31 ` [Bug tree-optimization/95685] " wilson at gcc dot gnu.org
  2020-06-16  6:36 ` rguenth at gcc dot gnu.org
@ 2020-06-16  6:37 ` rguenth at gcc dot gnu.org
  2021-05-30 22:31 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-06-16  6:37 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95685

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |rtl-optimization
           Keywords|                            |missed-optimization

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is about RTL btw, on GIMPLE the constants are always immediates.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug rtl-optimization/95685] Loop invariants can't be moved out of the loop
  2020-06-15 15:47 [Bug tree-optimization/95685] New: Loop invariants can't be moved out of the loop bina2374 at gmail dot com
                   ` (2 preceding siblings ...)
  2020-06-16  6:37 ` [Bug rtl-optimization/95685] " rguenth at gcc dot gnu.org
@ 2021-05-30 22:31 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-05-30 22:31 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95685

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
With -funroll-loops on the trunk for the aarch64 target, I get no loop any
more:
bar and seems like good code:
.LFB0:
        .cfi_startproc
        and     w1, w1, 65535
        mov     w2, 8193
        tst     w0, 2
        eor     w3, w1, w2
        csel    w4, w1, w3, eq
        tst     w0, 4
        eor     w5, w4, w2
        and     w6, w5, 65535
        csel    w7, w6, w4, ne
        tst     w0, 8
        eor     w0, w7, w2
        and     w8, w0, 65535
        csel    w0, w8, w7, ne
        ret

Oh I recongize this loop too, it is from coremark.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-05-30 22:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-15 15:47 [Bug tree-optimization/95685] New: Loop invariants can't be moved out of the loop bina2374 at gmail dot com
2020-06-16  0:31 ` [Bug tree-optimization/95685] " wilson at gcc dot gnu.org
2020-06-16  6:36 ` rguenth at gcc dot gnu.org
2020-06-16  6:37 ` [Bug rtl-optimization/95685] " rguenth at gcc dot gnu.org
2021-05-30 22:31 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).