On Fri, Oct 5, 2018 at 4:29 AM Jan Hubicka <hubi...@ucw.cz> wrote: > > > > > The following fixes bogus differences in scalar iteration cost > > computed by the vectorizer when comparing 128 and 256 bit vectorizations. > > This was caused by the hook looking at the vector types mode even > > for kind == scalar_stmt and thus returning vector operation costs > > for things like add or negate. > > > > This is most noticable on targets where ix86_vec_cost applies > > multiplication based on vector size (TARGET_AVX128_OPTIMAL, thus > > Zen and Bulldozer). But it will also adjust the actual costs > > everywhere where scalar and vector costs diverge. > > > > The adjustments done for Silvermont also look broken since they > > are applied to both scalar and vector cost which makes it mostly > > a no-op. The patch adjusts it to only apply for vector costing > > but of course I didn't benchmark this and the magic number of 1.7 > > may not make sense after this fix so I'm happy to leave that > > out - Kirill? Should I just go ahead with that for trunk (we can > > revert or adjust if autotesters pick up regressions on your side)? > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK? > > > > Richard. > > > > 2018-10-04 Richard Biener <rguent...@suse.de> > > > > * config/i386/i386.c (ix86_add_stmt_cost): When scalar cost > > is asked for initialize mode to the component mode of the > > vector type. Make sure Bonnel and esp. other Atom cost > > adjustments are not done for scalar cost estimates. > OK,
This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87545 -- H.J.
