Page MenuHomePhabricator

[X86][CostModel] Adjust the costs of ZERO_EXTEND/SIGN_EXTEND with less than 128-bit inputs

Authored by craig.topper on Tue, Aug 13, 2:18 PM.



Now that we legalize by widening, the element types here won't change. Previously these were modeled as the elements being widened and then the instruction might become an AND or SHL/ASHR pair. But now they'll become something like a ZERO_EXTEND_VECTOR_INREG/SIGN_EXTEND_VECTOR_INREG.

For AVX2, when the destination type is legal its clear the cost should be 1 since we have extend instructions that can produce 256 bit vectors from less than 128 bit vectors. I'm a little less sure about AVX1 costs, but I think the ones I changed were definitely too high, but they might still be too high.

Diff Detail


Event Timeline

craig.topper created this revision.Tue, Aug 13, 2:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptTue, Aug 13, 2:18 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
RKSimon accepted this revision.Wed, Aug 14, 5:45 AM

LGTM - I agree the AVX1 256-bit result cases might need further tweaking (especially for extension ratio = 2 as we can cheaply use movx+unpckh), but that can wait for now.

611 ↗(On Diff #214918)

Please can you raise a bug about the lower v2i8 sext vectorizing but the upper 2 x i8 not?

This revision is now accepted and ready to land.Wed, Aug 14, 5:45 AM
This revision was automatically updated to reflect the committed changes.