[PATCH] D114394: Compile-time computation of string attribute hashes

[serge via Phabricator via llvm-commits]

serge-sans-paille updated this revision to Diff 393058.
serge-sans-paille added a comment.

Use a DenseSet instead of a DenseMap to store the StringPool.

Some benchmark feedback (using a release build compiled with LTO), in number of instructions

|              | sqlite3.c -c -O0 | sqlite3.c -S -emit-llvm | sqlite3.ll -c |
| before patch | 6.12G            | 4.68G                   | 4.42G         |
| after patch  | 6.06G            | 4.62G                   | 4.38G         |
|

I also tried some micro benchmark on the C-API and C++ API, using compile-time known Attribute name

  #include "llvm-c/Core.h"
  #include <cstdio>
  #include <cstring>
  
  int main(int argc, char** argv) {
  
    int n = strlen(argv[0]);
    LLVMContextRef ctx = LLVMContextCreate();
    LLVMModuleRef mod = LLVMModuleCreateWithName("name");
    LLVMAttributeRef Key =
        LLVMCreateStringAttribute(ctx, argv[0], n, "myvalue", 7);
    LLVMValueRef value = LLVMGetIntrinsicDeclaration(mod, 25, {}, 0);
    LLVMDumpValue(value);
    LLVMAddAttributeAtIndex(value, 0, Key);
    unsigned size;
    char buffer[100];
    for (int i = 0; i < 10000; ++i) {
      for (int j = 0; j < 1000; ++j) {
        LLVMGetStringAttributeAtIndex(value, 0, argv[0], n);
        size += n;
      }
    }
    return size;
  }

Here are the result (in seconds)

|                  | C API | C++ API |
| before the patch | 0.12  | 0.12    |
| after the patch  | 0.14  | 0.08    |
|

So basically, the drawback of this patch is that there is a double lookup (and thus two calls to `strcmp`) for each dynamic attribute request.
The advantage is that there's a single lookup and no allocation for static attribute request. At least for clang, this seems to be the most common request.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114394/new/

https://reviews.llvm.org/D114394

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/include/llvm/Analysis/VectorUtils.h
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/IR/Assumptions.h
  llvm/include/llvm/IR/Attributes.h
  llvm/include/llvm/IR/Function.h
  llvm/include/llvm/IR/GlobalVariable.h
  llvm/include/llvm/IR/InstrTypes.h
  llvm/include/llvm/ProfileData/SampleProf.h
  llvm/lib/Analysis/InlineCost.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/lib/IR/AttributeImpl.h
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/lib/IR/Function.cpp
  llvm/lib/IR/Instructions.cpp
  llvm/lib/IR/LLVMContextImpl.h
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/IPO/Attributor.cpp
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
  llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/lib/Transforms/Utils/EntryExitInstrumenter.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D114394.393058.patch
Type: text/x-patch
Size: 57208 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211209/2c13697e/attachment.bin>