[Bug target/98931] New: arm: Assembly fails with "branch out of range or not a multiple of 2"

[Bug target/98931] New: arm: Assembly fails with "branch out of range or not a multiple of 2"

[acoplan at gcc dot gnu.org]

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

            Bug ID: 98931
           Summary: arm: Assembly fails with "branch out of range or not a
                    multiple of 2"
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

GCC's output fails to assemble for the following:

$ cat test.c
extern long long a[][20][26][26][22];
void foo()
{
  for (short d = 0; d+1; d++)
    for (unsigned e = 0; e < 25; e += 4)
      for (unsigned f = 0; f < 25; f += 4)
        for (int g = 0; g < 21; g += 4)
          a[4][d][e][f][g] = 0;
}
$ arm-eabi-gcc -c test.c -march=armv8.1-m.main -O3
--param=max-completely-peeled-insns=1300
/tmp/ccDd7AwT.s: Assembler messages:
/tmp/ccDd7AwT.s:1642: Error: branch out of range or not a multiple of 2

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2"

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|arm: Assembly fails with    |[11 Regression] arm:
                   |"branch out of range or not |Assembly fails with "branch
                   |a multiple of 2"            |out of range or not a
                   |                            |multiple of 2"
   Target Milestone|---                         |11.0
      Known to work|                            |10.2.1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |ktkachov at gcc dot gnu.org
     Ever confirmed|0                           |1
           Priority|P3                          |P1
   Last reconfirmed|                            |2021-02-02

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. Assembles fine on GCC 10.

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
            Summary|[11 Regression] arm:        |[11 Regression] arm:
                   |Assembly fails with "branch |Assembly fails with "branch
                   |out of range or not a       |out of range or not a
                   |multiple of 2"              |multiple of 2" since
                   |                            |r11-2012

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r11-2012-gd2ed233cb940aa3eecc163d98b47979dd81dbc0a

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And the problem is not something not being multiple of 2, but just out of range
jump.  The code has:
      10:       f04e e001       dls     lr, lr
      14:       9900            ldr     r1, [sp, #0]
...
    130e:       f00f c7ff       le      lr, 316 <foo+0x316>
if I manually move .L2 label so that it doesn't complain anymore, which means
it can jump only to -4096 bytes from the end of the le instruction, but it was
supposed to jump to foo+0x14, i.e. to 4862 bytes before the end of the le insn
at 0x1312.
So, either the computation of the instruction sizes is incorrect, or for this
kind of branch nothing checks whether the distance is in range.

Re: [Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[Andrea Corallo]

"jakub at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931
>
> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> And the problem is not something not being multiple of 2, but just out of range
> jump.  The code has:
>       10:       f04e e001       dls     lr, lr
>       14:       9900            ldr     r1, [sp, #0]
> ...
>     130e:       f00f c7ff       le      lr, 316 <foo+0x316>
> if I manually move .L2 label so that it doesn't complain anymore, which means
> it can jump only to -4096 bytes from the end of the le instruction, but it was
> supposed to jump to foo+0x14, i.e. to 4862 bytes before the end of the le insn
> at 0x1312.
> So, either the computation of the instruction sizes is incorrect, or for this
> kind of branch nothing checks whether the distance is in range.

I think this (the second) is the case.

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[andrea.corallo at arm dot com]

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

--- Comment #4 from Andrea Corallo <andrea.corallo at arm dot com> ---
"jakub at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931
>
> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> And the problem is not something not being multiple of 2, but just out of range
> jump.  The code has:
>       10:       f04e e001       dls     lr, lr
>       14:       9900            ldr     r1, [sp, #0]
> ...
>     130e:       f00f c7ff       le      lr, 316 <foo+0x316>
> if I manually move .L2 label so that it doesn't complain anymore, which means
> it can jump only to -4096 bytes from the end of the le instruction, but it was
> supposed to jump to foo+0x14, i.e. to 4862 bytes before the end of the le insn
> at 0x1312.
> So, either the computation of the instruction sizes is incorrect, or for this
> kind of branch nothing checks whether the distance is in range.

I think this (the second) is the case.

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
At the end of shorten_branches the label the doloop_end insn wants to jump to
has
(gdb) p insn_addresses_[2361]
$1 = (int &) @0x2e264ac: 22
and the doloop_end is
(gdb) p insn_addresses_[2397]
$2 = (int &) @0x2e2653c: 7150
If that is in bytes, then it is conservatively correct (perhaps too large), if
it is in 2 byte units, then it is not accurate.

Re: [Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[Andrea Corallo]

[-- Attachment #1: Type: text/plain, Size: 31 bytes --]

I'm testing the attached fix.


[-- Attachment #2: 0001-arm-Add-low-overhead-loop-address-range-check-PR9893.patch --]
[-- Type: text/plain, Size: 1504 bytes --]

>From 6de0603f3a5c86396d44250cb34d4451528681b1 Mon Sep 17 00:00:00 2001
From: Andrea Corallo <andrea.corallo@arm.com>
Date: Wed, 3 Feb 2021 15:21:54 +0100
Subject: [PATCH] arm: Add low overhead loop address range check [PR98931]

2021-02-03  Andrea Corallo  <andrea.corallo@arm.com>

	* config/arm/arm.c (arm_target_insn_ok_for_lob): Add address range
	check.
---
 gcc/config/arm/arm.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index e22396dbcd5..85c96cdb156 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -33769,10 +33769,22 @@ arm_target_insn_ok_for_lob (rtx insn)
      supported for 'low over head loop' making sure that LE target is
      above LE itself in the generated code.  */
 
-  return single_succ_p (bb)
-    && single_pred_p (bb)
-    && single_succ_edge (bb)->dest == single_pred_edge (bb)->src
-    && contains_no_active_insn_p (bb);
+  if  (!single_succ_p (bb)
+       || !single_pred_p (bb)
+       || single_succ_edge (bb)->dest != single_pred_edge (bb)->src
+       || !contains_no_active_insn_p (bb))
+    return false;
+
+  unsigned int distance = 0;
+  rtx_insn *curr_insn = BB_HEAD (single_succ_edge (bb)->dest);
+  while ((curr_insn = NEXT_INSN (curr_insn)))
+    distance += get_attr_length (curr_insn);
+
+  /* LE encodes the PC relative jump address in 12 bits.  */
+  if (distance >= (1 << 11))
+    return false;
+
+  return true;
 }
 
 #if CHECKING_P
-- 
2.20.1

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[andrea.corallo at arm dot com]

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

--- Comment #6 from Andrea Corallo <andrea.corallo at arm dot com> ---
I'm testing the attached fix.

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't think one can use get_attr_length until very late, at least definitely
not reliably, distances can shrink or grow a lot by other passes.
Is there some reason why the doloop_end insn pattern can't do what other
conditional jumps do, in particular have the length attribute on themselves
determine if they can use a short or long form and in the long form do
unconditional branches in addition to the conditional ones?
I guess one can't invert this insn, so if it is out of bounds, one would
probably need to le 1f; b 2f; 1: b lab; 2: or so instead of le lab if lab is
too far.
Walking all insns in between (especially when you don't give up when you reach
the limit) can increase compile time complexity on some functions too.

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Or if le lr,lab can only branch backwards, maybe
b 2f; 1: b lab; 2: le lr, 1b

Re: [Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[Andrea Corallo]

Right I'll rework the patch.

Thanks

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[andrea.corallo at arm dot com]

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

--- Comment #9 from Andrea Corallo <andrea.corallo at arm dot com> ---
Right I'll rework the patch.

Thanks

Re: [Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[Andrea Corallo]

[-- Attachment #1: Type: text/plain, Size: 156 bytes --]

Following suggestions I'm testing the attached emitting the following
for long branches where LE cannot cover:

        subs    lr, #1
        bmi     .L2


[-- Attachment #2: 0001-arm-Add-low-overhead-loop-address-range-check-PR9893.patch --]
[-- Type: text/plain, Size: 1205 bytes --]

>From 0cd38cb29829b48f96e8e060e7a875f49236b67b Mon Sep 17 00:00:00 2001
From: Andrea Corallo <andrea.corallo@arm.com>
Date: Wed, 3 Feb 2021 15:21:54 +0100
Subject: [PATCH] arm: Add low overhead loop address range check [PR98931]

2021-02-05  Andrea Corallo  <andrea.corallo@arm.com>

	* config/arm/thumb2.md: Generate alternative sequence for long
	range branches.
---
 gcc/config/arm/thumb2.md | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index bd53bf320de..a8327066bfe 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -1719,7 +1719,18 @@
               (set (reg:SI LR_REGNUM)
                    (plus:SI (reg:SI LR_REGNUM) (const_int -1)))])]
   "TARGET_32BIT && TARGET_HAVE_LOB"
-  "le\t%|lr, %l0")
+  "*
+  if (get_attr_length (insn) == 2)
+    return \"le\\t%|lr, %l0\";
+  else
+    return \"subs\\t%|lr, #1\;bmi\\t%l0\";
+  "
+  [(set (attr "length")
+        (if_then_else
+            (lt (minus (pc) (match_dup 0)) (const_int 1024))
+	    (const_int 2)
+	    (const_int 6)))
+   (set_attr "type" "branch")])
 
 (define_expand "doloop_begin"
   [(match_operand 0 "" "")
-- 
2.20.1

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[andrea.corallo at arm dot com]

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

--- Comment #10 from Andrea Corallo <andrea.corallo at arm dot com> ---
Following suggestions I'm testing the attached emitting the following
for long branches where LE cannot cover:

        subs    lr, #1
        bmi     .L2

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Isn't the normal length of short le lr, 1b 4 bytes rather than 2?

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[akrl at gcc dot gnu.org]

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

--- Comment #12 from akrl at gcc dot gnu.org ---
Right LE is 4 bytes, good catch thanks

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[akrl at gcc dot gnu.org]

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

--- Comment #13 from akrl at gcc dot gnu.org ---
Patch posted here:

<https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565044.html>

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrea Corallo <akrl@gcc.gnu.org>:

https://gcc.gnu.org/g:38c5703449c0638618ba6896f0d039c3868ad4e0

commit r11-7190-g38c5703449c0638618ba6896f0d039c3868ad4e0
Author: Andrea Corallo <andrea.corallo@arm.com>
Date:   Wed Feb 3 15:21:54 2021 +0100

    arm: Low overhead loop handle long range branches [PR98931]

    gcc/
            PR target/98931
            * config/arm/thumb2.md (*doloop_end_internal): Generate
            alternative sequence to handle long range branches.

    gcc/testsuite/
            PR target/98931
            * gcc.target/arm/pr98931.c: New testcase.

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[akrl at gcc dot gnu.org]

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

akrl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from akrl at gcc dot gnu.org ---
Fixed into master by 38c5703449c.

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Christophe Lyon <clyon@gcc.gnu.org>:

https://gcc.gnu.org/g:71b8ed7c61bc6f80df41f9aa3cf9eb57fb664e77

commit r11-7211-g71b8ed7c61bc6f80df41f9aa3cf9eb57fb664e77
Author: Christophe Lyon <christophe.lyon@linaro.org>
Date:   Fri Feb 12 14:14:45 2021 +0000

    testsuite, arm: Add -mthumb to pr98931.c [PR target/98931]

    This test forces -march=armv8.1-m.main, which supports only Thumb mode.
    However, if the toolchain is not configured --with-thumb, the test
    fails with:
    error: target CPU does not support ARM mode

    Adding -mthumb to dg-options fixes the problem.

    2021-02-12  Christophe Lyon  <christophe.lyon@linaro.org>

            PR target/98931
            gcc/testsuite/
            * gcc.target/arm/pr98931.c: Add -mthumb