- Refactor SetTheory code to use const pointers when possible.
- Use auto for variables initialized using dyn_cast<>.
- Use range based for loops and early continue.
Substitutions can be added in a couple different ways; they can be added
via the calling python scripts by adding entries to the
config.substitutions dictionary, or via DEFINE lines in the scripts
themselves.
The substitution strings passed to Python's re classes are interpreted
so that backslashes expand to escape sequences, and literal backslashes
need to be escaped.
On Unix, the script defined substitutions don't (usually, so far)
contain backslashes - but on Windows, they often do, due to paths
containing backslashes. This lead to a Windows specific escaping of
backslashes before doing Python re substitutions - since
7c9eab8fef0ed79a5911d21eb97b6b0fa9d39f82. There's nothing inherently
Windows specific about this though - any intended literal backslashes in
the substitution strings need to be escaped; this is how the Python re
API works.
The DEFINE lines were added later, and in order to cope with
backslashes, escaping of backslashes was added in the SubstDirective
class in TestRunner, applying to DEFINE lines in the tests only.
The fact that the escaping right before passing to the Python re API was
done conditionally on Windows led to two inconsistencies:
- DEFINE lines in the tests that contain backslashes got double
backslashes on Windows. (This was visible as a FIXME in
llvm/utils/lit/tests/Inputs/shtest-define/value-escaped.txt.)
- Script provided substitutions containing backslashes did not work on
Unix, but they did work on Windows.
By removing the escaping from SubstDirective and escaping it
unconditionally in the processLine function, before feeding the
substitutions to Python's re classes, we should have consistent
behaviour across platforms, and get rid of the FIXME in the lit test.
This fixes issues with substitutions containing backslashes on Unix
platforms, as encountered in PR #86649.
This reverts commit 6476a1d6865fc3a4c0fa3e436174a9a99a6ffedb.
d3fb41dddc11 relanded in 9bb555688caf6a.
...amended to incorporate changes from the reland.
Rework `IntrinsicEmitter::EmitIntrinsicToBuiltinMap` for improved
peformance as well as refactor the code.
Performance:
- Current generated code does a linear search on the TargetPrefix,
followed by a binary search on the builtin names for that
target's builtins.
- Improve the performance of this code in 2 ways:
(a) Use binary search on the target prefix to lookup the builtin
table for the target.
(b) Improve the (common) case of when all builtins for a target
share a common prefix. Check this common prefix first, and
then do the binary search in the builtin table using the builtin
name with the common prefix removed. This should help
both data size (by creating a smaller static string table) and
runtime (by reducing the cost of binary search on smaller
strings).
Refactor:
- Use range based for loops for iterating over maps.
- Use formatv() and C++ raw string literals to simplify the emission
code.
- Change the generated `getIntrinsicForClangBuiltin` and
`getIntrinsicForMSBuiltin` to take a `StringRef` instead of
`const char *` for the prefix.
LLVMType is both too broad and too narrow for defining DXIL operations, in
different ways. It's too broad in the sense that we don't need the full set of
MVTs - the set of types DXIL operations work on is much smaller. It's too
narrow in the sense that it's difficult to use it for the various fixed
structure types in DXIL, like `%dx.types.Handle` or `%dx.Types.ResRet.f32`.
Replace the usage of LLVMType in DXIL.td with DXILOpParamType, a simple class
that we can define an enum of types from. Further, use this to replace the
"ParameterKind" enum in DXILABI.h that has nothing to do with DXIL's ABI.
Pull Request: https://github.com/llvm/llvm-project/pull/104247
This adds a check that all ExtensionWithMArch which are marked as
implied features for an architecture are also present in the list of
default features. It doesn't make sense to have something mandatory but
not on by default.
There were a number of existing cases that violated this rule, and some
changes to which features are mandatory (indicated by the Implies
field).
This resulted in a bug where if a feature was marked as `Implies` but
was not added to `DefaultExt`, then for `-march=base_arch+nofeat` the
Driver would consider `feat` to have never been added and therefore
would do nothing to disable it (no `-target-feature -feat` would be
added, but the backend would enable the feature by default because of
`Implies`). See
clang/test/Driver/aarch64-negative-modifiers-for-default-features.c.
Note that the processor definitions do not respect the architecture
DefaultExts. These apply only when specifying `-march=<some architecture
version>`. So when a feature is moved from `Implies` to `DefaultExts` on
the Architecture definition, the feature needs to be added to all
processor definitions (that are based on that architecture) in order to
preserve the existing behaviour. I have checked the TRMs for many cases
(see specific commit messages) but in other cases I have just kept the
current behaviour and not tried to fix it.
When a test case inside of a gtest suite fails, we report a failure
which causes the entire `ninja check-lldb` invocation to fail, even if
the outer test case is marked as XFAIL - each test case result is
reported as its own lit test run. This PR updates lit so it checks
whether each test case's parent test suite is XFAIL before setting the
status to FAIL.
This is especially problematic because the failing tests can't manually
be marked as XFAIL, due to
https://github.com/llvm/llvm-project/issues/102264.
Fixes https://github.com/llvm/llvm-project/issues/102265
### Repro instructions
1. Modify any gtest test case to generate a failure.
2. Mark the outer lit test with XFAIL using either `--xfail-tests` flag
or `LIT_XFAIL` env var.
3. Run the tests
4. Observe the lit test is XFAIL as expected, but the failed child test
cases show up as separate failures.
Co-authored-by: kendal <kendal@thebrowser.company>
CodeGenIntrinsic changes:
- Use `const` Record pointers, and `StringRef` when possible.
- Default initialize several fields with their definition instead of in
the constructor.
- Simplify various string checks in the constructor using StringRef
starts_with()/ends_with() functions.
- Eliminate first argument to `setDefaultProperties` and use `TheDef`
class member instead.
IntrinsicEmitter changes:
- Emit `namespace llvm::Intrinsic` instead of nested namespaces.
- End generated comments with a .
- Use range based for loops, and early continue within loops.
- Emit `static constexpr` instead of `static const` for arrays.
- Change `compareFnAttributes` to use std::tie() to compare intrinsic
attributes and return a default value when all attributes are equal.
STLExtras:
- Add std::replace wrapper which takes a range.
I'm planning to add a getSignedConstant to SelectionDAG and use it for
EmitInteger in SelectionDAGISel which already uses int64_t.
getSignedConstant will assert that the constant has the correct number
of significant bits for the VT.
This patch ensures that tablegen emits constants in this form.
This script linkifies (i.e. makes clickable in the terminal) text that appears
to be a pull request or issue reference (e.g. #12345 or PR12345) or a
40-character commit hash (e.g. abc123). You can configure git to automatically
send the output of commands that pipe their output through a pager, such as
`git log` and `git show`, through this script by running this command from
within your LLVM checkout:
git config core.pager 'llvm/utils/git/linkify | pager'
The pager command is run from the root of the repository even if the git
command is run from a subdirectory, so the relative path should always work.
It requires OSC 8 support in the terminal. For a list of compatible terminals,
see https://github.com/Alhadis/OSC8-Adoption
Reviewers: MaskRay
Reviewed By: MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/103496
When using the lit internal shell with the command:
```
LIT_USE_INTERNAL_SHELL=1 ninja check-compiler-rt
```
The follow error is encountered:
```
File "TestRunner.py", line 770, in _executeShCmd
inproc_builtin = inproc_builtins.get(args[0], None)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: unhashable type: 'GlobItem'
```
This error is in a compiler-rt file:
```
TestCases/Linux/long-object-path.cpp
```
This error occurs because `args[0]` is of type `GlobItem`, which is not
hashable, leading to a `TypeError` when it is passed in
`inproc_builtins.get()`. To resolve this issue, I have updated the
implementation to ensure that `args[0]` is hashable before it is used in
`inproc_builtins`.
fixes: #102389
[link to
RFC](https://discourse.llvm.org/t/rfc-enabling-the-lit-internal-shell-by-default/80179)
This patch separates the lit tests that check for the functionality of
lit's built-in cat command into its own test file and folder. This is a
prerequisite for https://github.com/llvm/llvm-project/pull/101530.
...because it is too noisy to be useful right now, and its architecture
is terrible, so it can't act a starting point of future development.
The main problem with this checker is that it tries to do (or at least
fake) path-sensitive analysis without actually using the established
path-sensitive analysis engine.
Instead of actually tracking the symbolic values and the known
constraints on them, this checker blindly gropes the AST and uses
heuristics like "this variable was seen in a comparison operator
expression that is not a loop condition, so it's probably not too large"
(which was improved in a separate commit to at least ignore comparison
operators that appear after the actual `malloc()` call).
This might have been acceptable in 2011 (when this checker was added),
but since then we developed a significantly better standard approach for
analysis and this old relic doesn't deserve to remain in the codebase.
Needless to say, this primitive approach causes lots of false positives
(and presumably false negatives as well), which ensures that this alpha
checker won't be missed by the users.
Moreover, the goals of this checker would be questionable even if it had
a perfect implementation. It's very aggressive to assume that the
argument of malloc can overflow by default (unless the checker sees a
bounds check); and this produces too many false positives -- perhaps
even for an optin checker. It may be possible to eventually create a
useful (and properly path-sensitive) optin checker for these kinds of
suspicious code, but this is a very low priority goal.
Also note that we already have `alpha.security.TaintedAlloc` which
provides more practical heuristics for detecting somewhat similar
"argument of malloc may be too large" vulnerabilities.
This script helps the release managers merge backport PR's.
It does the following things:
* Validate the PR, checks approval, target branch and many other things.
* Rebases the PR
* Checkout the PR locally
* Pushes the PR to the release branch
* Deletes the local branch
I have found the script very helpful to merge the PR's.
Without this patch, the constructor arguments come from
SmallVectorImpl, not ArrayRef. This patch switches them to ArrayRef
so that we can construct SmallVector with a single argument.
Note that LLVM Programmer’s Manual prefers ArrayRef to SmallVectorImpl
for flexibility.
When working on very busy systems, check-offload frequently fails many
tests with this diagnostic:
```
clang: error: cannot determine amdgcn architecture: /tmp/llvm/build/bin/amdgpu-arch: Child timed out: ; consider passing it via '-march'
```
This patch accepts the environment variable
`CLANG_TOOLCHAIN_PROGRAM_TIMEOUT` to set the timeout. It also increases
the timeout from 10 to 60 seconds.
Without this, the doc string is put in a single line. These
scripts have multi-line docstrings, so this makes their --help
output look much nicer.
Otherwise, no behavior change.
Updating `llvm/test/CodeGen/AMDGPU/GlobalISel/extractelement.ll` with
`update_llc_test_checks.py` ended with several kernels with no checks.
Llc's output contained the line ".amdgpu_hsa_kernel <funcname>" after
the ".type <funcname>,@function" entry which was not considered by the
regexp.
