This is an archive of the discontinued LLVM Phabricator instance.

ComputeLineNumbers: delete SSE2 vectorization
ClosedPublic

Authored by MaskRay on Dec 8 2018, 11:33 PM.

Details

Summary

SSE2 vectorization was added in 2012, but it is 2018 now and I can't
observe any performance boost with the existing _mm_movemask_epi8 or the following SSE4.2 (compiling with -msse4.2):

__m128i C = _mm_setr_epi8('\r','\n',0,0,0,0,0,0,0,0,0,0,0,0,0,0);
_mm_cmpestri(C, 2, Chunk, 16, _SIDD_UBYTE_OPS | _SIDD_CMP_EQUAL_ANY | _SIDD_POSITIVE_POLARITY | _SIDD_LEAST_SIGNIFICANT)

Delete the vectorization to simplify the code.

Also don't check the line ending sequence \n\r

Diff Detail

Event Timeline

MaskRay created this revision.Dec 8 2018, 11:33 PM
MaskRay added a reviewer: Restricted Project.Dec 8 2018, 11:35 PM
bkramer accepted this revision.Dec 9 2018, 9:55 PM

The performance difference on preprocessing huge files was tiny back then, doesn't surprise me that it disappeared. What did you test this on?

Dropping it is fine with me.

This revision is now accepted and ready to land.Dec 9 2018, 9:55 PM

The performance difference on preprocessing huge files was tiny back then, doesn't surprise me that it disappeared. What did you test this on?

I tested it on

cat lib/Sema/*.cpp lib/CodeGen/*.cpp > /tmp/all.cpp
perf stat -r 10 clang -E /tmp/all.cpp [-I extracted from build.ninja]

and /tmp/all.cpp (13M) repeated 3 and 9 times.

This revision was automatically updated to reflect the committed changes.

I'm hitting a crash by this code,

getting:

exception thrown: RuntimeError: unreachable,RuntimeError: unreachable
    at ComputeLineNumbers(clang::DiagnosticsEngine&, clang::SrcMgr::ContentCache*, llvm::BumpPtrAllocatorImpl<llvm::MallocAllocator, 4096ul, 4096ul>&, clang::SourceManager const&, bool&) (wasm-function[21781]:719)
    at clang::SourceManager::getLineNumber(clang::FileID, unsigned int, bool*) const (wasm-function[21780]:187)
    at clang::SourceManager::getPresumedLoc(clang::SourceLocation, bool) const (wasm-function[21779]:733)
    at clang::Preprocessor::HandlePragmaSystemHeader(clang::Token&) (wasm-function[21284]:297)
    at (anonymous namespace)::PragmaSystemHeaderHandler::HandlePragma(clang::Preprocessor&, clang::PragmaIntroducer, clang::Token&) (wasm-function[21317]:5)
    at clang::PragmaNamespace::HandlePragma(clang::Preprocessor&, clang::PragmaIntroducer, clang::Token&) (wasm-function[21278]:565)
    at clang::PragmaNamespace::HandlePragma(clang::Preprocessor&, clang::PragmaIntroducer, clang::Token&) (wasm-function[21278]:565)
    at clang::Preprocessor::HandlePragmaDirective(clang::PragmaIntroducer) (wasm-function[21279]:142)
    at clang::Preprocessor::HandleDirective(clang::Token&) (wasm-function[21157]:1721)
    at clang::Lexer::LexTokenInternal(clang::Token&, bool) (wasm-function[20897]:14349)

The reason seems to be that the code appears to expect the Buf is zero ended, but it doesn't seem to be the case. The last character of the Buf was actually \n

Herald added a project: Restricted Project. · View Herald TranscriptNov 26 2019, 9:32 AM

I'm hitting a crash by this code,

getting:

exception thrown: RuntimeError: unreachable,RuntimeError: unreachable
    at ComputeLineNumbers(clang::DiagnosticsEngine&, clang::SrcMgr::ContentCache*, llvm::BumpPtrAllocatorImpl<llvm::MallocAllocator, 4096ul, 4096ul>&, clang::SourceManager const&, bool&) (wasm-function[21781]:719)
    at clang::SourceManager::getLineNumber(clang::FileID, unsigned int, bool*) const (wasm-function[21780]:187)
    at clang::SourceManager::getPresumedLoc(clang::SourceLocation, bool) const (wasm-function[21779]:733)
    at clang::Preprocessor::HandlePragmaSystemHeader(clang::Token&) (wasm-function[21284]:297)
    at (anonymous namespace)::PragmaSystemHeaderHandler::HandlePragma(clang::Preprocessor&, clang::PragmaIntroducer, clang::Token&) (wasm-function[21317]:5)
    at clang::PragmaNamespace::HandlePragma(clang::Preprocessor&, clang::PragmaIntroducer, clang::Token&) (wasm-function[21278]:565)
    at clang::PragmaNamespace::HandlePragma(clang::Preprocessor&, clang::PragmaIntroducer, clang::Token&) (wasm-function[21278]:565)
    at clang::Preprocessor::HandlePragmaDirective(clang::PragmaIntroducer) (wasm-function[21279]:142)
    at clang::Preprocessor::HandleDirective(clang::Token&) (wasm-function[21157]:1721)
    at clang::Lexer::LexTokenInternal(clang::Token&, bool) (wasm-function[20897]:14349)

The reason seems to be that the code appears to expect the Buf is zero ended, but it doesn't seem to be the case. The last character of the Buf was actually \n

ComputeLineNumbers assumes that the buffer has a NUL terminator (RequiresNullTerminator in lib/Support/MemoryBuffer.cpp). The function has the assumption both before and after the change (I don't think this patch should be blamed...). That said, a detailed reproducible instruction will be useful, though I think the mostly likely problem is that your code does not set RequiresNullTerminator when calling one of the MemoryBuffer creation routines.