This helps with testing and debugging for paths that are assumed
absolute.
It also uses a FileError to provide the file path it's trying to open.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@375008 91177308-0d34-0410-b5e6-96231b3b80d8
After changing the remark serialization, we now pass StringRefs to the
serializer. We should use StringRef for StringBlockVal, to avoid
creating temporary objects, which then cause StringBlockVal.Value to
point to invalid memory.
Reviewers: thegameg, anemet
Reviewed By: thegameg
Differential Revision: https://reviews.llvm.org/D68571
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@373923 91177308-0d34-0410-b5e6-96231b3b80d8
It should be allowed to take a string table in case all the strings in
the remarks point there, but it shouldn't use it during serialization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372042 91177308-0d34-0410-b5e6-96231b3b80d8
The bitstream remark serializer landed in r367372.
This adds a bitstream remark parser that parser bitstream remark files
to llvm::remarks::Remark objects through the RemarkParser interface.
A few interesting things to point out:
* There are parsing helpers to parse the different types of blocks
* The main parsing helper allows us to parse remark metadata and open an
external file containing the encoded remarks
* This adds a dependency from the Remarks library to the BitstreamReader
library
* The testing strategy is to create a remark entry through YAML, parse
it, serialize it to bitstream, parse that back and compare the objects.
* There are close to no tests for malformed bitstream remarks, due to
the lack of textual format for the bitstream format.
* This adds a new C API for parsing bitstream remarks:
LLVMRemarkParserCreateBitstream.
* This bumps the REMARKS_API_VERSION to 1.
Differential Revision: https://reviews.llvm.org/D67134
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371429 91177308-0d34-0410-b5e6-96231b3b80d8
In order to keep remarks around, we need to make them tied to a string
table.
Users then can delete the parser and rely on the string table to keep
the memory of the strings alive and deduplicated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371233 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@369013 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367372 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367364 91177308-0d34-0410-b5e6-96231b3b80d8
The default mode is separate, where the metadata is serialized
separately from the remarks.
Another mode is the standalone mode, where the metadata is serialized
before the remarks, on the same stream.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367328 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support to the yaml remark parser to be able to parse remarks
directly from the metadata.
This supports parsing separate metadata and following the external file
with the associated metadata, and also a standalone file containing
metadata + remarks all together.
Original llvm-svn: 367148
Revert llvm-svn: 367151
This has a fix for gcc builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367155 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support to the yaml remark parser to be able to parse remarks
directly from the metadata.
This supports parsing separate metadata and following the external file
with the associated metadata, and also a standalone file containing
metadata + remarks all together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367148 91177308-0d34-0410-b5e6-96231b3b80d8
This allows every serializer format to implement metaSerializer() and
return the corresponding meta serializer.
Original llvm-svn: 366946
Reverted llvm-svn: 367004
This fixes the unit tests on Windows bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367078 91177308-0d34-0410-b5e6-96231b3b80d8
This allows every serializer format to implement metaSerializer() and
return the corresponding meta serializer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366946 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce two new functions to create a serializer, and add support for
more combinations to the YAMLStrTabSerializer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366919 91177308-0d34-0410-b5e6-96231b3b80d8
Copying them is expensive. This allows the tables to be moved around at
lower cost, and allows a remarks::StringTable to be constructed from
a remarks::ParsedStringTable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366864 91177308-0d34-0410-b5e6-96231b3b80d8
This exposes better support to use a string table with a format through
an actual new remark::Format, called yaml-strtab.
This can now be used with -fsave-optimization-record=yaml-strtab.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366849 91177308-0d34-0410-b5e6-96231b3b80d8
Before, everything was based on some kind of type erased parser
implementation which container a lot of boilerplate code when multiple
formats were to be supported.
This simplifies it by:
* the remark now owns its arguments
* *always* returning an error from the implementation side
* working around the way the YAML parser reports errors: catch them through
callbacks and re-insert them in a proper llvm::Error
* add a CParser wrapper that is used when implementing the C API to
avoid cluttering the C++ API with useless state
* LLVMRemarkParserGetNext now returns an object that needs to be
released to avoid leaking resources
* add a new API to dispose of a remark entry: LLVMRemarkEntryDispose
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366217 91177308-0d34-0410-b5e6-96231b3b80d8
Without this fix gcc (7.4) complains with
../lib/Remarks/RemarkParser.cpp: In function 'std::unique_ptr<llvm::remarks::ParserImpl> formatToParserImpl(llvm::remarks::ParserFormat, llvm::StringRef)':
../lib/Remarks/RemarkParser.cpp:29:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
../lib/Remarks/RemarkParser.cpp: In function 'std::unique_ptr<llvm::remarks::ParserImpl> formatToParserImpl(llvm::remarks::ParserFormat, llvm::StringRef, const llvm::remarks::ParsedStringTable&)':
../lib/Remarks/RemarkParser.cpp:38:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
The Format enum currently only contains the value YAML which is indeed
already handled in the switches, but gcc complains anyway.
Adding a default case with an llvm_unreachable silences gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365118 91177308-0d34-0410-b5e6-96231b3b80d8
Make the parser require an explicit format.
This allows new formats to be easily added by following YAML as an
example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365102 91177308-0d34-0410-b5e6-96231b3b80d8
Separate the remark serialization to YAML from the LLVM Diagnostics.
This adds a new serialization abstraction: remarks::Serializer. It's
completely independent from lib/IR and it provides an easy way to
replace YAML by providing a new remarks::Serializer.
Differential Revision: https://reviews.llvm.org/D62632
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362160 91177308-0d34-0410-b5e6-96231b3b80d8
* Add support for uniquing strings in the remark streamer and emitting the string table in the remarks section.
* Add parsing support for the string table in the RemarkParser.
From this remark:
```
--- !Missed
Pass: inline
Name: NoDefinition
DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c',
Line: 7, Column: 3 }
Function: printArgsNoRet
Args:
- Callee: printf
- String: ' will not be inlined into '
- Caller: printArgsNoRet
DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c',
Line: 6, Column: 0 }
- String: ' because its definition is unavailable'
...
```
to:
```
--- !Missed
Pass: 0
Name: 1
DebugLoc: { File: 3, Line: 7, Column: 3 }
Function: 2
Args:
- Callee: 4
- String: 5
- Caller: 2
DebugLoc: { File: 3, Line: 6, Column: 0 }
- String: 6
...
```
And the string table in the .remarks/__remarks section containing:
```
inline\0NoDefinition\0printArgsNoRet\0
test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c\0printf\0
will not be inlined into \0 because its definition is unavailable\0
```
This is mostly supposed to be used for testing purposes, but it gives us
a 2x reduction in the remark size, and is an incremental change for the
updates to the remarks file format.
Differential Revision: https://reviews.llvm.org/D60227
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359050 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 6080a6fb1949a2bdf053245d6062c7bf58dae7a6 (r356532).
Clang does not accept this syntax, so reverting this until I can find something that works across all compilers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356533 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a Remark class that allows us to share code when working with
remarks.
The C API has been updated to reflect this. Instead of the parser
generating C structs, it's now using a C++ object that is used through
opaque pointers in C. This gives us much more flexibility on what
changes we can make to the internal state of the object and interacts
much better with scenarios where the library is used through dlopen.
* C API updates:
* move from C structs to opaque pointers and functions
* the remark type is now an enum instead of a string
* unit tests updates:
* use mostly the C++ API
* keep one test for the C API
* rename to YAMLRemarksParsingTest
* a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute.
* a new error message was added: "expected a remark tag."
* llvm-opt-report has been updated to use the C++ parser instead of the
C API
Differential Revision: https://reviews.llvm.org/D59049
Original llvm-svn: 356491
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356519 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a Remark class that allows us to share code when working with
remarks.
The C API has been updated to reflect this. Instead of the parser
generating C structs, it's now using a C++ object that is used through
opaque pointers in C. This gives us much more flexibility on what
changes we can make to the internal state of the object and interacts
much better with scenarios where the library is used through dlopen.
* C API updates:
* move from C structs to opaque pointers and functions
* the remark type is now an enum instead of a string
* unit tests updates:
* use mostly the C++ API
* keep one test for the C API
* rename to YAMLRemarksParsingTest
* a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute.
* a new error message was added: "expected a remark tag."
* llvm-opt-report has been updated to use the C++ parser instead of the
C API
Differential Revision: https://reviews.llvm.org/D59049
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356491 91177308-0d34-0410-b5e6-96231b3b80d8
