Hi!
I am seeing multiple assembler errors with error message "Error:
conditional branch out of range" for customer code.
The root cause of the bug is that conditional branches are generated
whose branch target ends up being too far away to be encoded in the
instruction. It appears that there was an attempt to fix this issue
in the below change:
commit 050af05b9761f1979f11c151519e7244d5becd7c
Author: thopre01 <thopre01@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Thu Aug 27 10:08:54 2015 +0000
2015-08-27 Ramana Radhakrishnan
<[ramana.radhakrish...@arm.com|mailto:ramana.radhakrish...@arm.com]>
Andre Vieira
<[andre.simoesdiasvie...@arm.com|mailto:andre.simoesdiasvie...@arm.com]>
gcc/
* config/aarch64/[aarch64.md|http://aarch64.md/] (*condjump):
Handle functions > 1 MiB.
(*cb<optab><mode>1): Likewise.
(*tb<optab><mode>1): Likewise.
(*cb<optab><mode>1): Likewise.
* config/aarch64/[iterators.md|http://iterators.md/] (inv_cb):
New code attribute.
(inv_tb): Likewise.
* config/aarch64/aarch64.c (aarch64_gen_far_branch): New.
* config/aarch64/aarch64-protos.h (aarch64_gen_far_branch): New.
gcc/testsuite/
* gcc.target/aarch64/long_branch_1.c: New test.
However, as per GCC Internal documentation, only special attribute
"length" should use PC and match_dup while defining an attribute. I
verified by looking at code in final pass, and realised that
get_attribute_length does not map directly to the functions generated
from the definition of attribute length in RTL patterns, but computes
the lengths in shorten_branches and uses insn_current_length as
intermediate function.
The far_branch attribute defined similar to attribute length expects
same values to be returned by (minus (match_dup 2) (pc)) which is
incorrect.
I am looking at TARGET_MACHINE_DEPENDENT_REORG macro instead like few
other architectures, to emit far branches.
Is that approach acceptable?
PS: I am waiting for customer's approval for attaching the test case.
--
- Thanks and regards,
Sameera D.
