This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][AArch64] Implement ALU_BRANCH fusion
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: "Hurugalawadi, Naveen" <Naveen dot Hurugalawadi at cavium dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "Pinski, Andrew" <Andrew dot Pinski at cavium dot com>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, "nd at arm dot com" <nd at arm dot com>
- Date: Thu, 9 Mar 2017 10:22:01 +0000
- Subject: Re: [PATCH][AArch64] Implement ALU_BRANCH fusion
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 217.140.96.140) smtp.mailfrom=arm.com; cavium.com; dkim=none (message not signed) header.d=none;cavium.com; dmarc=bestguesspass action=none header.from=arm.com;
- Nodisclaimer: True
- References: <CO2PR07MB2694CB39F815C51139D35101832C0@CO2PR07MB2694.namprd07.prod.outlook.com> <20170308180359.GD25712@arm.com> <CO2PR07MB269496BC132974C448BFC7BB83210@CO2PR07MB2694.namprd07.prod.outlook.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Thu, Mar 09, 2017 at 06:22:33AM +0000, Hurugalawadi, Naveen wrote:
> Hi James,
>
> Thanks for the review and your comments.
>
> >> I'd need more detail on what types of instruction pairs you
> >> are trying to fuse.
>
> The documentation mentions it as follows:-
> Single uop ALU instruction may fuse with adjacent branch instruction in the
> same bundle
>
> >> This comment looks incorrect - there is no vulcan_alu_basic reservation
>
> Modified as per comment.
>
> Please let us know if the description is sufficient?
My reason for asking is that the instruction fusion implemented in LLVM
( lib/Target/AArch64/AArch64MacroFusion.cpp::shouldScheduleAdjacent ) is
between ALU instructions and conditional branches, while this patch fuses
ALU instructions and unconditional branches. I'm trying to understand why
there is a discrepancy, and consequently whether this patch is correct.
Your clarification helps, but it would be useful to know which sort of
branches you are actually targeting and to fix the disagreement between
this patch and LLVM.
Thanks,
James