Ramana Radhakrishnan <ramana.radhakrish...@linaro.org> wrote:
> On 1 February 2011 14:01, Ulrich Weigand <ulrich.weig...@de.ibm.com>
wrote:
> > - You define new patterns neon_vzip<mode>_interleave etc. instead of
using
> > the existing neon_vzip<mode>_internal etc., presumably because the
> > existing patterns are broken. But because they are actually broken,
> > they should rather be fixed themselves (and *then* used instead of
> > duplicated).
>
> Are they actually broken ? I'd be worried if that were the case. My
> understanding is that the
> existing ones are being used for the Neon intrinsics / builtins.
Yes, they're broken, for the reason Ira originally points out:
"The problem with it is that it doesn't express the fact that the two
outputs of vzip depend on both inputs, which causes wrong code
generation in CSE:
for
(a,b)<- vzip (c,d)
and
(e,f) <- vzip (g,d)
CSE decides that b==f, since on RTL level b and f depend only on d."
(define_insn "neon_vzip<mode>_internal"
[(set (match_operand:VDQW 0 "s_register_operand" "=w")
(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
UNSPEC_VZIP1))
(set (match_operand:VDQW 2 "s_register_operand" "=w")
(unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
UNSPEC_VZIP2))]
The VZIP unspecs must have *both* input registers as operand, since
the output actually depends on both.
It may be that in the original use (where the output seems to always
be written to memory for some reason?) CSE rarely has an opportunity
for perform this transformation, but it's still at least latently
broken ...
> It would be a good thing to integrate the 2 of them together if at all
> possible.
I think if the original pattern is fixed, Ira should be able to just use
it without problem.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
