Page MenuHomePhabricator

[InstructionCost] Don't conflate Invalid costs with Unknown costs.

Authored by sdesmalen on Mar 29 2021, 6:24 AM.



We previously made a change to getUserCost to return a Invalid cost
when one of the TTI costs returned '-1' (meaning 'unknown' or
'infinitely expensive'). It makes no sense to say that:

shufflevector <2 x i8> %x, <2 x i8> %y, <4 x i32> <i32 0, i32 1, i32 2, i32 3>

has an invalid cost. Perhaps the cost is not known, but the IR is valid
and can be code-generated. Invalid should only be used for IR that
cannot possibly be code-generated and where a cost is nonsensical.

With more passes now asserting that the cost must be valid, it is possible
that those assertions will fail for perfectly valid IR. An incomplete
cost-model probably shouldn't be a reason for the compiler to break.

It's better to consider these costs as 'very expensive' and ignore them
for other reasons. At some point, we should consider replacing -1 with
some other mechanism.

Diff Detail

Event Timeline

sdesmalen created this revision.Mar 29 2021, 6:24 AM
sdesmalen requested review of this revision.Mar 29 2021, 6:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 29 2021, 6:25 AM
paulwalker-arm accepted this revision.Mar 29 2021, 7:30 AM

I agree, InstructionCost::Invalid is solving a specific problem which is different to "Did not bother computing a real cost".

This revision is now accepted and ready to land.Mar 29 2021, 7:30 AM
dmgreen accepted this revision.Mar 29 2021, 10:50 AM
dmgreen added a subscriber: dmgreen.

I agree. "Invalid" is better than "Unknown".

I think we should be removing the -1 from shuffle costs too, but that is a different patch.

This revision was landed with ongoing or failed builds.Mar 30 2021, 1:31 AM
This revision was automatically updated to reflect the committed changes.