On Mon, May 25, 2015 at 06:39:36AM +0100, Kumar, Venkataramanan wrote:
> Ping!
>
> -----Original Message-----
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
> Behalf Of Kumar, Venkataramanan
> Sent: Tuesday, May 19, 2015 9:07 PM
> To: James Greenhalgh (james.greenha...@arm.com); gcc-patches@gcc.gnu.org
> Cc: Kyrill Tkachov (kyrylo.tkac...@arm.com); ramana.radhakrish...@arm.com;
> seg...@kernel.crashing.org; Marcus Shawcroft (marcus.shawcr...@arm.com)
> Subject: [Patch] [AArch64] PR target 66049: fix add/extend gcc test suite
> failures
>
> Hi Maintainers,
>
> Please find the attached patch, that fixes add/extend gcc test suite failures
> in Aarch64 target.
> Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049
>
> These tests started to fail after we prevented combiner from converting shift
> RTX to mult RTX, when the RTX is not inside a memory operation (r222874) .
> Now I have added new add/extend patterns which are based on shift operations,
> to fix these cases.
>
> Testing status with the patch.
>
> (1) GCC bootstrap on AArch64 successful.
> (2) SPEC2006 INT runs did not show any degradation.
> (3) gcc regression testing passed.
Perfect, thank you.
> Is this OK for trunk ?
Yup, this is OK for trunk. Make sure you reference the PR number
in the ChangeLog entry and close off the BZ entry when this is done.
Thanks again for your patience.
> +;; zero_extend version of above
> +(define_insn "*add_uxtsi_shift2_uxtw"
> + [(set (match_operand:DI 0 "register_operand" "=rk")
> + (zero_extend:DI
> + (plus:SI (and:SI
> + (ashift:SI (match_operand:SI 1 "register_operand" "r")
> + (match_operand 2 "aarch64_imm3" "Ui3"))
> + (match_operand 3 "const_int_operand" "n"))
> + (match_operand:SI 4 "register_operand" "r"))))]
> + "aarch64_uxt_size (INTVAL (operands[2]), INTVAL (operands[3])) != 0"
> + "*
> + operands[3] = GEN_INT (aarch64_uxt_size (INTVAL (operands[2]),
> + INTVAL (operands[3])));
> + return \"add\t%w0, %w4, %w1, uxt%e3 %2\";"
> + [(set_attr "type" "alu_ext")]
> +)
> +
You don't have to fix it in this patch (as it matches existing style), but
if you are looking for a cleanup, we should use the
{
/* Code */
}
syntax in these patterns and avoid all the escaping of '"'.
Cheers,
James
