Hi,
During the little-endian vector modification work in 2014, I
accidentally introduced an error that Uli Weigand noticed this week.
This results in wrong code being generated for the
__builtin_altivec_lvxl and vec_lvxl interfaces; an "lvx" instruction is
generated instead of an "lvxl" instruction. Now, this is only a
performance issue, since the error just means a cache hint is not being
generated. However, it needs to be corrected, as below.
This brings up a point that, though we have many test cases for the
altivec built-ins, they only test that well-formed built-ins are
accepted. None of them test the actual code generation. I don't intend
to fix that here, but at some point we should do better with this. We
should definitely do better with future built-ins that we add.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. I hand-checked some of the existing test cases that invoke
__builtin_altivec_lvxl and vec_lvxl to verify correct code gen. Is this
okay for trunk? I would also like to backport this to GCC 5 and 4.9 if
that's acceptable.
Thanks,
Bill
2016-02-16 Bill Schmidt <wschm...@linux.vnet.ibm.com>
* config/rs6000/altivec.md (*altivec_lvxl_<mode>_internal): Output
correct instruction.
Index: gcc/config/rs6000/altivec.md
===================================================================
--- gcc/config/rs6000/altivec.md (revision 233466)
+++ gcc/config/rs6000/altivec.md (working copy)
@@ -2511,7 +2511,7 @@
(match_operand:VM2 1 "memory_operand" "Z"))
(unspec [(const_int 0)] UNSPEC_SET_VSCR)])]
"TARGET_ALTIVEC"
- "lvx %0,%y1"
+ "lvxl %0,%y1"
[(set_attr "type" "vecload")])
(define_expand "altivec_lvx_<mode>"
