On Wed, Oct 30, 2013 at 6:42 PM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Wed, Oct 30, 2013 at 12:11 PM, Jakub Jelinek <ja...@redhat.com> wrote: > >>> > Yesterday I've noticed that for AVX which allows unaligned operands in >>> > AVX arithmetics instructions we still don't combine unaligned loads with >>> > the >>> > AVX arithmetics instructions. So say for -O2 -mavx -ftree-vectorize >>> >>> This is actually PR 47754 that fell below radar for some reason... >> >> Apparently yes. >> >>> > the patch attempts to avoid gen_lowpart on the non-MEM lhs of the >>> > unaligned >>> > loads, which usually means combine will fail, by doing the load into a >>> > temporary pseudo in that case and then doing a pseudo to pseudo move with >>> > gen_lowpart on the rhs (which will be merged soon after into following >>> > instructions). >>> >>> Is this similar to PR44141? There were similar problems with V4SFmode >>> subregs, so combine was not able to merge load to the arithemtic insn. >> >> From the work on the vectorization last year I remember many cases where >> subregs (even equal size) on the LHS of instructions prevented combiner or >> other RTL optimizations from doing it's job. I believe I've changed some >> easy places that did that completely unnecessarily, but certainly have not >> went through all the code to look for other places where this is done. >> >> Perhaps let's hack up a checking pass that will after expansion walk the >> whole IL and complain about same sized subregs on the LHS of insns, then do >> make >> check with it for a couple of ISAs (-msse2,-msse4,-mavx,-mavx2 e.g.? >> >>> > I'll bootstrap/regtest this on x86_64-linux and i686-linux, unfortunately >>> > my >>> > bootstrap/regtest server isn't AVX capable. >>> >>> I can bootstrap the patch later today on IvyBridge with >>> --with-arch=core-avx-i --with-cpu=core-avx-i --with-fpmath=avx. >> >> That would be greatly appreciated, thanks. > > The bootstrap and regression test was OK for x86_64-linux-gnu {,-m32}. > > The failures in the attached report are either pre-existing or benign > due to core-avx-i default to AVX.
I was referring to the *runtime* failures here. > Please also mention PR44141 in the ChangeLog entry. Ops, this should be PR47754. Thanks, Uros.