[BitcodeAnalyzer] allow a motivated user to dump BLOCKINFO

This adds the `--dump-blockinfo` flag to `llvm-bcanalyzer`, allowing a sufficiently motivated user to dump (parts of) the `BLOCKINFO_BLOCK`

[BitcodeAnalyzer] allow a motivated user to dump BLOCKINFO

This adds the `--dump-blockinfo` flag to `llvm-bcanalyzer`, allowing a sufficiently motivated user to dump (parts of) the `BLOCKINFO_BLOCK` block. The default behavior is unchanged, and `--dump-blockinfo` only takes effect in the same context as other flags that control dump behavior (i.e., requires that `--dump` is also passed).

Reviewed By: tejohnson

Differential Revision: https://reviews.llvm.org/D107536

show more ...

[DebugInfo] Add DIArgList MD to store multple values in DbgVariableIntrinsics

This patch adds a new metadata node, DIArgList, which contains a list of SSA
values. This node is in many ways similar i

[DebugInfo] Add DIArgList MD to store multple values in DbgVariableIntrinsics

This patch adds a new metadata node, DIArgList, which contains a list of SSA
values. This node is in many ways similar in function to the existing
ValueAsMetadata node, with the difference being that it tracks a list instead of
a single value. Internally, it uses ValueAsMetadata to track the individual
values, but there is also a reasonable amount of DIArgList-specific
value-tracking logic on top of that. Similar to ValueAsMetadata, it is a special
case in parsing and printing due to the fact that it requires a function state
(as it may reference function-local values).

This patch should not result in any immediate functional change; it allows for
DIArgLists to be parsed and printed, but debug variable intrinsics do not yet
recognize them as a valid argument (outside of parsing).

Differential Revision: https://reviews.llvm.org/D88175

show more ...

[llvm][Bitcode] Add bitcode reader/writer for DSOLocalEquivalent

This is necessary for compilation with [thin]lto.

Differential Revision: https://reviews.llvm.org/D96170

[BitCodeAnalyzer] Add a few missing TYPE_CODES and MODULE_CODE_COMDAT to GetCodeName

Happened to notice some of these printing as UnknownCode while running llvm-bcanalyzer on a bc file I had.

Diffe

[BitCodeAnalyzer] Add a few missing TYPE_CODES and MODULE_CODE_COMDAT to GetCodeName

Happened to notice some of these printing as UnknownCode while running llvm-bcanalyzer on a bc file I had.

Differential Revision: https://reviews.llvm.org/D86900

show more ...

Remove references to the 4.0 release as a major breaking (NFC)

This is cleaning up comments (mostly in the bitcode handling) about
removing some backward compatibility aspect in the 4.0 release.
His

Remove references to the 4.0 release as a major breaking (NFC)

This is cleaning up comments (mostly in the bitcode handling) about
removing some backward compatibility aspect in the 4.0 release.
Historically, "4.0" was used during the development of the 3.x
versions as "this future major breaking change version". At the time
the major number was used to indicate the compatibility. When we
reached 3.9 we decided to change the numbering, instead of going to
3.10 we went to 4.0 but after changing the meaning of the major
number to not mean anything anymore with respect to bitcode backward
compatibility.

The current policy
(https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility)
indicates only now:

The current LLVM version supports loading any bitcode since version 3.0.

Differential Revision: https://reviews.llvm.org/D82514

show more ...

[StackSafety] Add info into function summary

Summary:
This patch adds optional field into function summary,
implements asm and bitcode serialization. YAML
serialization is omitted and can be added l

[StackSafety] Add info into function summary

Summary:
This patch adds optional field into function summary,
implements asm and bitcode serialization. YAML
serialization is omitted and can be added later if
needed.

This patch includes this information into summary only
if module contains at least one sanitize_memtag function.
In a near future MTE is the user of the analysis.
Later if needed we can provede more direct control
on when information is included into summary.

Reviewers: eugenis

Subscribers: hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D80908

show more ...

[ThinLTO] Compute the basic block count across modules.

Summary:
Count the per-module number of basic blocks when the module summary is computed
and sum them up during Thin LTO indexing.

This is us

[ThinLTO] Compute the basic block count across modules.

Summary:
Count the per-module number of basic blocks when the module summary is computed
and sum them up during Thin LTO indexing.

This is used to estimate the working set size under the partial sample PGO.

This is split off of D79831.

Reviewers: davidxl, espindola

Subscribers: emaste, inglorion, hiraditya, MaskRay, steven_wu, dexonsmith, arphaman, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D80403

show more ...

[llvm-bcanalyzer] Simplify code. NFCI.

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3b

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.

show more ...

Remove redundant "std::move"s in return statements

Reland: [Remarks] Add an LLVM-bitstream-based remark serializer

Add a new serializer, using a binary format based on the LLVM bitstream
format.

This format provides a way to serialize the remarks i

Reland: [Remarks] Add an LLVM-bitstream-based remark serializer

Add a new serializer, using a binary format based on the LLVM bitstream
format.

This format provides a way to serialize the remarks in two modes:

1) Separate mode: the metadata is separate from the remark entries.
2) Standalone mode: the metadata and the remark entries are in the same
file.

The format contains:

* a meta block: container version, container type, string table,
external file path, remark version
* a remark block: type, remark name, pass name, function name, debug
file, debug line, debug column, hotness, arguments (key, value, debug
file, debug line, debug column)

A string table is required for this format, which will be dumped in the
meta block to be consumed before parsing the remark blocks.

On clang itself, we noticed a size reduction of 13.4x compared to YAML,
and a compile-time reduction of between 1.7% and 3.5% on CTMark.

Differential Revision: https://reviews.llvm.org/D63466

Original llvm-svn: 367364
Revert llvm-svn: 367370

llvm-svn: 367372

show more ...

Revert "[Remarks] Add an LLVM-bitstream-based remark serializer"

This reverts commit r367364.

Breaks some bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/3161/steps/annotat

Revert "[Remarks] Add an LLVM-bitstream-based remark serializer"

This reverts commit r367364.

Breaks some bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/3161/steps/annotate/logs/stdio

llvm-svn: 367370

show more ...

[Remarks] Add an LLVM-bitstream-based remark serializer

Add a new serializer, using a binary format based on the LLVM bitstream
format.

This format provides a way to serialize the remarks in two mo

[Remarks] Add an LLVM-bitstream-based remark serializer

Add a new serializer, using a binary format based on the LLVM bitstream
format.

This format provides a way to serialize the remarks in two modes:

1) Separate mode: the metadata is separate from the remark entries.
2) Standalone mode: the metadata and the remark entries are in the same
file.

The format contains:

* a meta block: container version, container type, string table,
external file path, remark version
* a remark block: type, remark name, pass name, function name, debug
file, debug line, debug column, hotness, arguments (key, value, debug
file, debug line, debug column)

A string table is required for this format, which will be dumped in the
meta block to be consumed before parsing the remark blocks.

On clang itself, we noticed a size reduction of 13.4x compared to YAML,
and a compile-time reduction of between 1.7% and 3.5% on CTMark.

Differential Revision: https://reviews.llvm.org/D63466

llvm-svn: 367364

show more ...

[llvm-bcanalyzer] Fixed error 'Expected<T> must be checked before access or destruction'

After rL365286 I had failing test:
LLVM :: tools/gold/X86/v1.12/thinlto_emit_linked_objects.ll

It was fail

[llvm-bcanalyzer] Fixed error 'Expected<T> must be checked before access or destruction'

After rL365286 I had failing test:
LLVM :: tools/gold/X86/v1.12/thinlto_emit_linked_objects.ll

It was failing with the output:
$ llvm-bcanalyzer --dump llvm/test/tools/gold/X86/v1.12/Output/thinlto_emit_linked_objects.ll.tmp3.o.thinlto.bc
Expected<T> must be checked before access or destruction.
Unchecked Expected<T> contained error:
Unexpected end of file reading 0 of 0 bytesStack dump:

Change-Id: I07e03262074ea5e0aae7a8d787d5487c87f914a2
llvm-svn: 366387

show more ...

[Bitcode] Explicitly include Bitstream/BitCodes.h and BitstreamWriter.h

This fixes a modules issue.

llvm-svn: 365580

[Bitcode][NFC] Remove unused variable from BitcodeAnalyzer

llvm-svn: 365340

[llvm-bcanalyzer] Refactor and move to libLLVMBitReader

This allows us to use the analyzer from unit tests.

* Refactor the interface to use proper error handling for most functions
after JF's wor

[llvm-bcanalyzer] Refactor and move to libLLVMBitReader

This allows us to use the analyzer from unit tests.

* Refactor the interface to use proper error handling for most functions
after JF's work.
* Move everything into a BitstreamAnalyzer class.
* Move that to Bitcode/BitcodeAnalyzer.h.

Differential Revision: https://reviews.llvm.org/D64116

llvm-svn: 365286

show more ...