This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [AARCH64]Bug in fix for branch offsets over 1 MiB?


On 30 January 2018 at 09:28, Sameera Deshpande
<sameera.deshpande@linaro.org> wrote:
> On 30-Jan-2018 2:37 AM, "Richard Sandiford" <richard.sandiford@linaro.org>
> wrote:
>
> Sameera Deshpande <sameera.deshpande@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.radhakrishnan@arm.com|mailto:ramana.radhakrishnan@arm.com]>
>>                 Andre Vieira
>> <[andre.simoesdiasvieira@arm.com|mailto:andre.simoesdiasvieira@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.
>

Hi Richard,

I verified that it works. Thanks a lot! Will do the testing, and
update the patch.

-- 
- Thanks and regards,
  Sameera D.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]