Page MenuHomePhabricator

[RISCV] Mark FSIN and other math functions as Expand for scalable vectors.
ClosedPublic

Authored by craig.topper on Apr 14 2022, 8:53 AM.

Details

Summary

This prevents them from being assumed legal by the cost model.

This matches what is done for AArch64 SVE.

Diff Detail

Event Timeline

craig.topper created this revision.Apr 14 2022, 8:53 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 14 2022, 8:53 AM
craig.topper requested review of this revision.Apr 14 2022, 8:53 AM

I would like to ask a question:

What are the benefits of illegal costs? Is there a problem that illegal costs are trying to solve?

craig.topper added a comment.EditedApr 18 2022, 6:55 PM

I would like to ask a question:

What are the benefits of illegal costs? Is there a problem that illegal costs are trying to solve?

It prevents the vectorizer from creating llvm.sin, etc. with scalable vector types since they will crash in the backend.

Add rint and nearbyint

I agree they should probably be invalid, conceptually, but in reality I don't like that we have users of cost models crash when encountering invalid costs, with the rationale that the IR shouldn't contain anything with an invalid cost. I don't see how those two models are compatible.

I agree they should probably be invalid, conceptually, but in reality I don't like that we have users of cost models crash when encountering invalid costs, with the rationale that the IR shouldn't contain anything with an invalid cost. I don't see how those two models are compatible.

Invalid cost is a recent concept. Did the project fail to update some code to comprehend the possibility of invalid costs?

I agree they should probably be invalid, conceptually, but in reality I don't like that we have users of cost models crash when encountering invalid costs, with the rationale that the IR shouldn't contain anything with an invalid cost. I don't see how those two models are compatible.

Invalid cost is a recent concept. Did the project fail to update some code to comprehend the possibility of invalid costs?

To be honest, I don't have a good idea about the broader community view on invalid costs so I can't say for sure. I'm sure I've seen it argued in a review that invalid costs are a symptom of invalid IR which should have been legalized before reaching whichever part of code crashed. I can't find where I thought I saw that, though. I might have dreamed it.

CodeMetrics is one that definitely hard-crashes on invalid costs, and that's used by several optimizations that form the standard pipeline.

It's doubly hard for scalable-vector targets because many of the base TTIs assume fixed-length vectors and I've seen it argued in D119529 (maybe where @liaolucy is coming from) that that's acceptable. We can't assume anything other than invalid costs for scalable vectors in base TTI functions. But then, in my opinion, forcing targets to fully cost everything before things stop crashing is asking too much.

On reflection, it's the combination of these two issues that's making life hard. We have to fully cost everything scalable but we also can't return invalid costs to get there without making assumptions.

I would like to ask a question:

What are the benefits of illegal costs? Is there a problem that illegal costs are trying to solve?

It prevents the vectorizer from creating llvm.sin, etc. with scalable vector types since they will crash in the backend.

Thank Craig , I get the crash today.

This patch fix tsvc s451 crash.

fatal error: error in backend: Cannot select: t12: nxv2f32 = fsin nnan ninf nsz arcp contract afn reassoc t7
  t7: nxv2f32,ch = load<(load unknown-size from %ir.uglygep51, align 16, !tbaa !4)> t0, t4, undef:i64
    t4: i64 = add t3, t81
      t3: i64,ch = CopyFromReg t0, Register:i64 %12
        t2: i64 = Register %12
      t81: i64 = ADDI t80, TargetGlobalAddress:i64<ptr @b> 0 [TF=3]
        t80: i64 = LUI TargetGlobalAddress:i64<ptr @b> 0 [TF=4]
          t78: i64 = TargetGlobalAddress<ptr @b> 0 [TF=4]
        t79: i64 = TargetGlobalAddress<ptr @b> 0 [TF=3]
    t6: i64 = undef
In function: s451
reames accepted this revision.Thu, Jun 9, 5:26 PM

LGTM

For context, I've been landing patches to remove the "crash on invalid cost" issue that got discussed earlier in this review. As of now, there are no cases that I'm aware of where an invalid cost can lead to a crash. We'll probably find a couple more as time goes by, but the major changes are in, and these are just bugs we should fix.

This revision is now accepted and ready to land.Thu, Jun 9, 5:26 PM
This revision was landed with ongoing or failed builds.Fri, Jun 10, 8:52 AM
This revision was automatically updated to reflect the committed changes.