[Bug target/60539] New: [SH] builtin string functions ignore loop and label alignment

[Bug target/60539] New: [SH] builtin string functions ignore loop and label alignment

[olegendo at gcc dot gnu.org]

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

            Bug ID: 60539
           Summary: [SH] builtin string functions ignore loop and label
                    alignment
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: olegendo at gcc dot gnu.org
                CC: christian.bruel at st dot com
            Target: sh*-*-*

The following function:

unsigned int test (const char* x)
{
  return __builtin_strlen (x);
}

compiled with -m4 -O2:
        mov     r4,r0
        tst     #3,r0
        bf/s    .L14
        mov     r4,r1
        mov     #0,r3
.L12:
        mov.l   @r1+,r2
        cmp/str r3,r2
        bf      .L12
        add     #-4,r1
.L14:
        mov.b   @r1+,r2
        tst     r2,r2
        bf/s    .L14
        mov     r1,r0
        rts
        subc    r4,r0

The loop and label alignments are missing.  E.g. when not optimizing for size,
the loop alignment is set to '4 bytes' (.align 2), which seems to be ignored by
the code that expands the builtin functions.

[Bug target/60539] [SH] builtin string functions ignore loop and label alignment

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chrbr at gcc dot gnu.org

--- Comment #1 from chrbr at gcc dot gnu.org ---
yes or not, it's not really ignored, it's the prob_likely value tuning. Setting
it to REG_BR_PROB_BASE restores the loop align but also impacts code ordering
for the byte-at-a-time code chunk that becomes less likely.

so we get worse:

    mov    r4,r0
    tst    #3,r0
    mov    r4,r1
    bt    .L10
.L6:
    mov.b    @r1+,r2
    tst    r2,r2
    bf    .L6
    mov    r1,r0
    rts    
    subc    r4,r0
    .align 1
.L10:
    mov    #0,r3
.L4:
    mov.l    @r1+,r2
    cmp/str    r3,r2
    bf    .L4
    bra    .L6
    add    #-4,r1

The problem is that .L14 is reached both from the word-at-atime paths and
byte-at-atime paths... and I was not able to find the proper tuning value to
favor boths given than the word loop iteration number is probably small
("strings are generally" not so big) and that the byte loop number of
iterations is less than 4, so introducing a .align here can be a cost.

I did try to introduce a UNSPECV_ALIGN here but without measuring any speed
improvement (or any small negative impact) on my board. Anyway any interesting
benchmarking tuning here is interesting, or even find a pathological case here
welcome,

[Bug target/60539] [SH] builtin string functions ignore loop and label alignment

[chrbr at gcc dot gnu.org]

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

--- Comment #2 from chrbr at gcc dot gnu.org ---
note also that instead of merging the 3 max remaining bytes after the
world-at-time loop with the byte-at-a-time loop I had a version that unrolled
the 3 of them of we have 2 different path (word,bytes) instead of 3 (words,
words+byte remaining, bytes).
But the additional CF complexity was not beneficial in average for my set of
benchmarks compared to a simple version with the remaining bytes falling thru
the byte-at-atime loop

[Bug target/60539] [SH] builtin string functions ignore loop and label alignment

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
As mentioned here
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01692.html:

> IMHO the problem is with the
> non-aligned loop stems from to the generic alignment code in final.c.

> Further tuning of static branch estimations, or tuning of the LOOP_ALIGN
> macro is needed.

This PR is about the fact that loops expanded by builtins don't get the loop
labels aligned automatically.  It just happens that on SH we have only the
strlen-like builtins so far that expand loops.