This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PING][PATCH, AArch64] Disable reg offset in quad-word store for Falkor
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>, James Greenhalgh <James dot Greenhalgh at arm dot com>, "kugan dot vivekanandarajah at linaro dot org" <kugan dot vivekanandarajah at linaro dot org>, "pinskia at gmail dot com" <pinskia at gmail dot com>, Jim Wilson <wilson at tuliptree dot org>
- Date: Wed, 17 Jan 2018 13:37:51 +0000
- Subject: Re: [PING][PATCH, AArch64] Disable reg offset in quad-word store for Falkor
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco dot Dijkstra at arm dot com;
- Nodisclaimer: True
- References: <DB6PR0801MB2053E725CB1788AFB8BAEA5C83E90@DB6PR0801MB2053.eurprd08.prod.outlook.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
(finished version this time, somehow Outlook loves to send emails early...)
Hi,
In general I think the best way to achieve this would be to use the
existing cost models which are there for exactly this purpose. If
this doesn't work well enough then we should fix those. As is,
this patch disables a whole class of instructions for a specific
target rather than simply telling GCC that they are expensive and
should only be used if there is no cheaper alternative.
Also there is potential impact on generic code from:
(define_insn "*aarch64_simd_mov<VQ:mode>"
[(set (match_operand:VQ 0 "nonimmediate_operand"
- "=w, Umq, m, w, ?r, ?w, ?r, w")
+ "=w, Umq, Utf, w, ?r, ?w, ?r, w")
(match_operand:VQ 1 "general_operand"
- "m, Dz, w, w, w, r, r, Dn"))]
+ "m, Dz, w, w, w, r, r, Dn"))]
It seems an 'm' constraint has special meaning in the register allocator,
using a different constraint can block certain simplifications (for example
merging stack offsets into load/store in the post-reload cleanup pass),
so we'd need to verify this doesn't cause regressions.
Also it is best to introduce generic interfaces:
+/* Return TRUE if OP is a good address mode for movti target on falkor. */
+bool
+aarch64_falkor_movti_target_operand_p (rtx op)
+(define_memory_constraint "Utf"
+ "@iternal
+ A good address for a falkor movti target operand."
+ (and (match_code "mem")
+ (match_test "aarch64_falkor_movti_target_operand_p (op)")))
We should use generic names here even if the current implementation
wants to do something specific for Falkor.
Wilco