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

            Bug ID: 102756
           Summary: [12 Regression] Vectorizer change creates poor code
                    for c-c++-common/torture/vector-compare-2.c
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: law at gcc dot gnu.org
  Target Milestone: ---

The visium-elf port is a bit broken in that any code which calls abort will
fail to link.   This has turned out to be useful in that it has pointed out
cases where the quality of our code generation has suffered.

The change to turn on the vectorizer by default at -O2 is yet another example.

c-c++-common/torture/vector-compare-2.c before the vectorizer change compiled
down to this code at -O2:



        .file   "j.c"
        .text
        .align  4
        .p2align 8
        .global foo
        .type   foo, @function
foo:
        moviu   r9,65535
        movil   r9,65533
        write.l (r1),r9
        write.l 1(r1),r9
        write.l 2(r1),r9
        bra     tr,r21,r0               ;return
         write.l 3(r1),r9
        .size   foo, .-foo
        .section        .text.startup,"ax",@progbits
        .align  4
        .p2align 8
        .global main
        .type   main, @function
main:
        bra     tr,r21,r0               ;return
         moviq   r1,0           ;movsi  r  J
        .size   main, .-main
        .ident  "GCC: (GNU) 12.0.0 20211008 (experimental)"


Of particular note "main" does _not_ call abort.  The optimizers have figured
everything out and realized that it should never abort.

After enabling the vectorizer at -O2 we get:
        .file   "j.c"
        .text
        .align  4
        .p2align 8
        .global foo
        .type   foo, @function
foo:
        moviu   r9,65535
        movil   r9,65533
        write.l (r1),r9
        write.l 1(r1),r9
        write.l 2(r1),r9
        bra     tr,r21,r0               ;return
         write.l 3(r1),r9
        .size   foo, .-foo
        .section        .text.startup,"ax",@progbits
        .align  4
        .p2align 8
        .global main
        .type   main, @function
main:
        subi    sp,36
        moviq   r10,23          ;movsi  r  J
        write.l (sp),fp
        move.l  fp,sp           ;stack_save
        add.l   r8,fp,r10
        lsr.l   r8,r8,4
        asl.l   r8,r8,4
        moviu   r9,65535
        write.l 1(sp),r21
        movil   r9,65533
        write.l (r8),r9
        write.l 1(r8),r9
        write.l 2(r8),r9
        write.l 3(r8),r9
        move.l  r10,r8
        moviq   r8,16           ;movsi  r  J
        add.l   r7,r10,r8
.L5:
        read.l  r8,(r10)
        cmp.l   r8,r9
        brr     ne,.L8
         addi    r10,4
        cmp.l   r10,r7
        brr     ne,.L5
         moviq   r1,0           ;movsi  r  J
        read.l  fp,(sp)
        read.l  r21,1(sp)
        bra     tr,r21,r0               ;return
         addi    sp,36          ;stack pop
.L8:
        moviu   r10,%u abort
        movil   r10,%l abort
        bra     tr,r10,r21
         nop            ;call
        .size   main, .-main
        .ident  "GCC: (GNU) 12.0.0 20211008 (experimental)"


Note how there's a call to abort starting at the label .L8.  And more generally
the code in "main" is considerably larger and more complex.

This is a code quality regression.

Reply via email to