This is an archive of the discontinued LLVM Phabricator instance.

[X86] Return 0 from TTI getNumberOfRegisters and getRegisterBitWidth on SSE1 only targets
AbandonedPublic

Authored by craig.topper on Jun 5 2020, 2:23 PM.

Details

Reviewers
RKSimon
spatel
Summary

SSE1 only supports vectors of v4f32. We're pretty much dependent on cost model calculations to prevent vectors of doubles or integers being generated. Or we rely on the backend scalarizing them. Even with that I'm not that confident in our SSE1 codegen quality.

We found a failure where the vectorizer was generating a call to a v4f64 SVML function with SSE1 only. This resulted in argument handling in the backend breaking the type down into scalars. Disabling SSE1 here prevents part of that although it still doesn't stop the vectorizer from generating the v4f64 call with SSE2

Diff Detail

Event Timeline

craig.topper created this revision.Jun 5 2020, 2:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 5 2020, 2:23 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
craig.topper edited the summary of this revision. (Show Details)Jun 5 2020, 2:26 PM
spatel added a comment.Jun 7 2020, 8:35 AM

Add a minimal test for SLP to make sure this is happening? Might be able to just add a RUN line to some existing test file.

llvm/lib/Target/X86/X86TargetTransformInfo.cpp
121–123

I'd word this differently to make it clearer:

// Avoid auto-vectorizing when compiling for SSE1 only. 
// That forces codegen to undo integer and v2f64 vectorization.

Add SSE1 command line to an SLP test.

Ideally getRegisterBitWidth/getNumberOfRegisters would distinguish between (legal) integer/float/double types more.

Have you made any progress on the SVML v4f64 SSE2 issue? I'm just wondering if that would avoid us needing to kill SSE1 vectorization entirely (although I realise its not a high priority target these days).

craig.topper abandoned this revision.Jun 28 2020, 11:08 AM