On Tue, 20 Mar 2018, Jakub Jelinek wrote: > On Tue, Mar 20, 2018 at 11:08:12AM +0100, Richard Biener wrote: > > With the x86 vectorizer cost-model rewrite we ended up costing > > scalar conversions as nothing. After my patch using the proper > > target cost estimates for the scalar version this now exposes > > underestimating scalar cost and thus no longer vectorizing > > the testcase in this PR. This fix is to restrict zero-costing > > to sign-conversions, all other conversions are possibly > > value-changing. I guess some zero-extensions are free as well > > but I didn't want to get too fancy as I'm not sure about > > QImode -> SImode conversions for example since whether > > that's free (can just use %eax instead of %ax) likely depends on > > context. > > Aren't casts from integral to integral with smaller precision also always > zero cost, at least for scalar code? It just expands to using a SUBREG > of whatever holds the larger value.
If the precision matches the mode maybe. But I thought we try to avoid using %al (HImode) or %ax (QImode) operands in the end? So it doesn't matter what we expand to but the code-generation in the end is what matters? Btw, the patched behavior is now that of GCC 7 apart from the sign-conversion case costing nothing. If x86 maintainers want to get fancy they can do that but I'm not too familiar with the code to tell. The only case I'm reasonably sure is zero-extension from SImode to DImode which should be always free since moves to %eax are zero-extending to 64bits. Btw, float <-> int conversions will run into the generic costing for vector_stmt and all other conversions into generic vec_promote_demote costing. An alternative patch would be to just cost sign-extensions (and maybe non-mode-size ones of any kind). Richard.
