On 30-Jan-2018 2:37 AM, "Richard Sandiford" <richard.sandif...@linaro.org> wrote:
Sameera Deshpande <sameera.deshpa...@linaro.org> writes: > 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? I don't think we need to go that far. The INSN_ADDRESSES should be correct when outputting the instructions, so does it work if we use those instead of get_attr_far_branch? Thanks, Richard > PS: I am waiting for customer's approval for attaching the test case. Hi Richard, Thanks for your reply. I will try using INSN_ADDRESSES and will get back to you. - Thanks and regards, Sameera D.
