[PATCH] Fix PR84986

[Jan Hubicka]

The way i originally made the code was going through ix86_rtx_costs
and factoring out/simplifying logic that translates directly to trees.
With NOP_EXPR I probably only tought of subgregs and other free stuff
which truly_noop_* probably simulates quite well.

ix86_rtx_costs understand how to zero extend, sign extend, and fp
conversions, but for scalar code only. I do remember looking into some
testcases with noop conversions that needs to be vectorized, so
costing them zero did improve code, but hopefully noop test will pass
for those.

We may get fancier next stage1 or if regressions surfaces.
Patch is OK. Thanks for looking into this!

Honza

Dne 2018-03-20 05:41, Richard Biener napsal:
> 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.