On Tue, Mar 20, 2018 at 3:08 AM, 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 long
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
On Tue, Mar 20, 2018 at 11:41:01AM +0100, Richard Biener wrote:
> If the precision matches the mode maybe. But I thought we try to
> avoid using %al (HImode) or %ax (QImode) operands in the end?
Yes, but we try to do that only on the level of the emitted assembly,
sometimes we simply emit a QImod
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 n
On Tue, 20 Mar 2018, Jakub Jelinek wrote:
> On Tue, Mar 20, 2018 at 11:41:01AM +0100, Richard Biener wrote:
> > If the precision matches the mode maybe. But I thought we try to
> > avoid using %al (HImode) or %ax (QImode) operands in the end?
>
> Yes, but we try to do that only on the level of t
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 n
