## Purpose
Export a small number of private LLVM symbols so that unit tests can
still build/run when LLVM is built as a Windows DLL or a shared library
with default hidden symbol visibility.
## Background
The effort to build LLVM as a WIndows DLL is tracked in #109483.
Additional context is provided in [this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307).
Some LLVM unit tests use internal/private symbols that are not part of
LLVM's public interface. When building LLVM as a DLL or shared library
with default hidden symbol visibility, the symbols are not available
when the unit test links against the DLL or shared library.
This problem can be solved in one of two ways:
1. Export the private symbols from the DLL.
2. Link the unit tests against the intermediate static libraries instead
of the final LLVM DLL.
This PR applies option 1. Based on the discussion of option 2 in
#145448, this option is preferable.
## Overview
* Adds a new `LLVM_ABI_FOR_TEST` export macro, which is currently just
an alias for `LLVM_ABI`.
* Annotates the sub-set of symbols under `llvm/lib` that are required to
get unit tests building using the new macro.
Firstly fix FileCheck printing string variables
double-escaped (first regex, then C-style).
This is confusing because it is not clear if the printed
value is the literal value or exactly how it is escaped, without
looking at FileCheck's source code.
Secondly, only escape when doing so makes it easier to read the value
(when the string contains tabs, newlines or non-printable characters).
When the variable value is escaped, make a note of it in the output too,
in order to avoid confusion.
The common case that is motivating this change is variables that contain
windows style paths with backslashes. These were printed as
`"C:\\\\Program Files\\\\MyApp\\\\file.txt"`.
Now prefer to print them as `"C:\Program Files\MyApp\file.txt"`.
Printing the value literally also makes it easier to search for
variables in the output, since the user can just copy-paste it.
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
We can use *Set::insert_range to collapse:
for (auto Elem : Range)
Set.insert(E);
down to:
Set.insert_range(Range);
In some cases, we can further fold that into the set declaration.
Since `raw_string_ostream` doesn't own the string buffer, it is
desirable (in terms of memory safety) for users to directly reference
the string buffer rather than use `raw_string_ostream::str()`.
Work towards TODO item to remove `raw_string_ostream::str()`.
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
70 under llvm/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
Reland #82595 with fixes of build failures related to colored output.
See https://lab.llvm.org/buildbot/#/builders/139/builds/60549
Use `%ProtectFileCheckOutput` to avoid colored output.
Original commit message below.
In `Pattern::parseVariable`, for global variables (those starting with '$')
and for pseudo variables (those starting with '@') the first character is
consumed before actual variable name parsing. If the name is empty, it
leads to out-of-bound access to the corresponding `StringRef`.
This patch adds an if statement against the case described.
In `Pattern::parseVariable`, for global variables (those starting with
'$') and for pseudo variables (those starting with '@') the first
character is consumed before actual variable name parsing. If the name
is empty, it leads to out-of-bound access to the corresponding
`StringRef`.
This patch adds an if statement against the case described.
Fixes#70221
Fix a bug in FileCheck that corrects the error message when multiple
prefixes are provided
through --check-prefixes and one of them is a PREFIX-NOT.
Earlier, only the first of the provided prefixes was displayed as the
erroneous prefix, while the
actual error might be on the prefix that occurred at the end of the
prefix list in the input file.
Now, the right NOT prefix is shown in the error message.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
FileCheck currently compiles a regular expression of the form
`Prefix1|Prefix2|...` and uses it to find the next prefix in the input.
If we had a fast regex implementation, this would be a useful thing to
do, as the regex implementation would be able to match multiple prefixes
more efficiently than a naive approach. However, with our actual regex
implementation, finding the prefixes basically becomes O(InputLen *
RegexLen * LargeConstantFactor), which is a lot worse than a simple
string search.
Replace the regex with StringRef::find(), and keeping track of the next
position of each prefix. There are various ways this could be improved
on, but it's already significantly faster that the previous approach.
For me, this improves check-llvm time from 138.5s to 132.5s, so by
around 4-5%.
For vector-interleaved-load-i16-stride-7.ll in particular, test time
drops from 5s to 2.5s.
For `{{regex}}` we don't really need a capturing group, and only add it
to properly handle cases like `{{foo|bar}}`. This is problematic,
because the use of capturing groups makes our regex implementation
slower (we have to go through the "dissect" stage, which can have
quadratic complexity).
Unfortunately, our regex implementation does not support non-capturing
groups like `(?:regex)`. So instead, avoid adding the group entirely if
the regex doesn't contain any alternations.
This causes a slight difference in escaping behavior, where previously
it was possible to write `{{{{}}` and get the same behavior as
`{{\{\{}}`. This will no longer work. I don't think this is a problem,
especially as we recently taught update_analyze_test_checks.py to emit
`{{\{\{}}`, so this shouldn't get introduced in any new tests.
For CodeGen/X86/vector-interleaved-store-i16-stride-7.ll (our slowest
X86 test) this drops FileCheck time from 6s to 5s (the remainder is
spent in a different regex issue). I expect similar speedups in other
tests using a lot of `{{}}`.
getWildcardRegex() guarantees that only valid hex numbers are matched by
FileCheck numeric expressions. This commit therefore only asserts the
lack of parsing failure in valueFromStringRepr().
Depends On D154430
Reviewed By: arichardson
Differential Revision: https://reviews.llvm.org/D154431
Use APInt to represent numeric variables and expressions, therefore
removing overflow concerns. Only remains underflow when the format of an
expression is unsigned (incl. hex values) but the result is negative.
Note that this can only happen when substituting an expression, not when
capturing since the regex used to capture unsigned value will not include
minus sign, hence all the code removal for match propagation testing.
This is what this patch implement.
Reviewed By: arichardson
Differential Revision: https://reviews.llvm.org/D150880
Use an APInt getter as the only interface to getting the value out of an
ExpressionValue. This paves the way to switch ExpressionValue to handle
any integer without causing too big of a patch.
Reviewed By: arichardson
Differential Revision: https://reviews.llvm.org/D154429
Use APInt internally to store values represented by ExpressionValue.
This will allow to support any integer values in FileCheck numeric
expression in a subsequent commit.
Reviewed By: arichardson
Differential Revision: https://reviews.llvm.org/D154428
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
Function valueFromStringRepr() throws an error on missing 0x prefix when
parsing a number string into a value. However, getWildcardRegex() already
ensures that only text with the 0x prefix will match and be parsed,
making that error throwing code dead code. This commit turn the code
into an assert and remove the unit tests exercising that test
accordingly.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D150797
Don't touch FileCheck.cpp:698 StringSwitch<Optional<binop_eval_t>>(FuncName).
MSVC and older GCC may report errors:
error C2664: 'llvm::StringSwitch<std::optional<llvm::binop_eval_t>,T> &llvm::StringSwitch<T,T>::Case(llvm::StringLiteral,T)': cannot convert argument 2 from 'overloaded-function' to 'T'
with
[
T=std::optional<llvm::binop_eval_t>
]
llvm/lib/FileCheck/FileCheck.cpp:699:44: error: no matching function for call to ‘llvm::StringSwitch<std::optional<llvm::Expected<llvm::ExpressionValue> (*)(const llvm::ExpressionValue&, const llvm::ExpressionValue&)> >::Case(const char [4], <unresolved overloaded function type>)’
.Case("add", operator+)
^
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
EXPENSIVE_CHECKS enables _GLIBCXX_DEBUG, which makes std::sort
check that the compare function is implemented correctly.
To do this it calls it with the first item as both sides.
Which trips the assert here because we think they're
2 capture ranges that overlap, when it's just the same range twice.
Check up front for the two sides being the same item
(same address, not just ==).
Reviewed By: kazu
Differential Revision: https://reviews.llvm.org/D130282
Change FileCheck to accept patterns like "[[[var...]]" and treat the
excess open brackets at the start as literals.
This makes the patterns for matching assembler output with literal
brackets much cleaner. For example an AMDGPU pattern that used to be
written like:
buffer_store_dwordx2 v{{\[}}[[LO]]:[[HI]]{{\]}}
can now be:
buffer_store_dwordx2 v[[[LO]]:[[HI]]]
(Even before this patch the final close bracket did not need to be
wrapped in {{}}, but people tended to do it anyway for symmetry.)
This does not introduce any ambiguity since "[[" was always followed by
an identifier or '@' or '#', so "[[[" was always an error.
I've included a few test updates in this patch just for illustration and
testing. There are a couple of hundred tests that could be updated as a
follow up, mostly in test/CodeGen/.
Differential Revision: https://reviews.llvm.org/D117117
Change-Id: Ia6bc6f65cb69734821c911f54a43fe1c673bcca7
If MatchRegexp is an invalid regex, an error message will be printed
using SourceManager::PrintMessage via AddRegExToRegEx.
PrintMessage relies on the input being a StringRef into a string managed
by SourceManager. At the moment, a StringRef to a std::string
allocated in the caller of AddRegExToRegEx is passed. If the regex is
invalid, this StringRef is passed to PrintMessage, where it will crash,
because it does not point to a string managed via SourceMgr.
This patch fixes the crash by turning MatchRegexp into a StringRef If
we use MatchStr, we directly use that StringRef, which points into a
string from SourceMgr. Otherwise, MatchRegexp gets assigned
Format.getWildcardRegex(), which returns a std::string. To extend the
lifetime, assign it to a std::string variable WildcardRegexp and assign
MatchRegexp to a stringref to WildcardRegexp. WildcardRegexp should
always be valid, so we should never have to print an error message
via the SoureMgr I think.
Fixes PR49319.
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D109050
