To enable the eventual migration of everything to the NewPM.
Reviewers: RKSimon, phoebewang, paperchalice, arsenm, topperc
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/165084
[DAG] Fold mismatched widened avg idioms to narrow form (fixes half of
[llvm#147946](https://github.com/llvm/llvm-project/issues/147946))
1. `trunc(avgceilu(sext(x), sext(y))) -> avgceils(x, y)`
2. `trunc(avgceils(zext(x), zext(y))) -> avgceilu(x, y)`
When inputs are sign-extended, unsigned and signed averaging operations
produce identical results after truncation, allowing us to use the
semantically correct narrow operation.
alive2: https://alive2.llvm.org/ce/z/ZRbfHT
Failing on macOS Clang-15 and Clang-17 bots with:
```
07:26:20 ======================================================================
07:26:20 FAIL: test_frame_var (TestFrameVarDILGlobalVariableLookup.TestFrameVarDILGlobalVariableLookup)
07:26:20 ----------------------------------------------------------------------
07:26:20 Traceback (most recent call last):
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 156, in wrapper
07:26:20 return func(*args, **kwargs)
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py", line 48, in test_frame_var
07:26:20 self.expect_var_path("ExtStruct::static_inline", value="16")
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2599, in expect_var_path
07:26:20 value_check.check_value(self, eval_result, str(eval_result))
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 302, in check_value
07:26:20 test_base.assertSuccess(val.GetError())
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2607, in assertSuccess
07:26:20 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
07:26:20 AssertionError: '<user expression 0>:1:1: use of undeclared identifier 'ExtStruct::static_inline'
07:26:20 1 | ExtStruct::static_inline
07:26:20 | ^' is not success
```
I suspect Clang-17 (and earlier) used DWARFv4 on macOS by default. So we
would use the Apple accelerator tables, which didn't index `ExtStruct`
(based on what I observed locally). We already XFAIL this test for
DWARFv4, hence XFAIL it also for older Clang versions.
Test fails on the DWARFv2 and DWARFv5 macOS bot with:
```
07:00:39 FAIL: test_frame_var (TestFrameVarDILGlobalVariableLookup.TestFrameVarDILGlobalVariableLookup)
07:00:39 ----------------------------------------------------------------------
07:00:39 Traceback (most recent call last):
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 156, in wrapper
07:00:39 return func(*args, **kwargs)
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py", line 48, in test_frame_var
07:00:39 self.expect_var_path("ExtStruct::static_inline", value="16")
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2599, in expect_var_path
07:00:39 value_check.check_value(self, eval_result, str(eval_result))
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 302, in check_value
07:00:39 test_base.assertSuccess(val.GetError())
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2607, in assertSuccess
07:00:39 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
07:00:39 AssertionError: '<user expression 0>:1:1: use of undeclared identifier 'ExtStruct::static_inline'
07:00:39 1 | ExtStruct::static_inline
07:00:39 | ^' is not success
07:00:39 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/lldb-build/bin/clang
```
Possibly something to do with accelerator table differences between the versions.
Prior to https://github.com/llvm/llvm-project/pull/164998, recent LLDB
versions would fail to parse synthesized property setters correctly. The
only way this failure would manifest is an error to the console:
```
error: main.o [0x00000000000000cd]: invalid Objective-C method DW_TAG_subprogram (DW_TAG_subprogram), please file a bug and attach the file at the start of this error message
```
There weren't any Objective-C tests that failed when the original regression (https://github.com/llvm/llvm-project/pull/100355) landed. This patch adds a test that explicitly checks that the type of the setter is sensible.
This test fails without https://github.com/llvm/llvm-project/pull/164998
and passes with it.
I decided not to check for the absence of the console error because that kind of test would be fragile to the removal of (or any changes to) the error message.
SPIR-V spec requires that any calls to external functions are preceded
by declarations of those external functions. To simplify the
implementation, we sort functions in the serializer using a stronger
condition: any functions declarations are moved before any functions
definitions - this ensures that external functions are always declared
before being used.
Currently the target test will fail with:
```
error: line 12: Initializer type must match the data type
%var2 = OpVariable %_ptr_Uniform_float Uniform %var1
```
When passed:
```mlir
spirv.module Logical GLSL450 requires #spirv.vce<v1.0, [Shader], []> {
spirv.GlobalVariable @var1 : !spirv.ptr<f32, Uniform>
spirv.GlobalVariable @var2 initializer(@var1) bind(1, 0) : !spirv.ptr<f32, Uniform>
}
```
The problem is that we try to initialize `f32` pointer with `f32`
pointer, but the validator fails because it expects `var1` to be `f32`,
not a pointer to `f32`. `spirv.GlobalVariable` only allows pointer type,
so in the current design we cannot initialize one `spirv.GlobalVariable`
with another.
So, for now we disallow initialization of one global variable with
another. In the future we may want to re-work global variables if we
want to support that.
The "t" flag is used to mark the builtin signature as meaningless.
This is done on several builtins taking pointers since otherwise HIP
code would not compile
during compilation for the host (even if the builtin is only used in
device code, compilation would fail).
The builtins changed by this patch are not affected by this issue, so
they do not need the "t" flag in the first place.
This patch adds a few more mbarrier intrinsics,
completing support for all the mbarrier variants
up to Blackwell architecture.
* Docs are updated in NVPTXUsage.rst.
* lit tests are added for all the variants.
* lit tests are verified with PTXAS from CUDA-12.8 toolkit.
Signed-off-by: Durgadoss R <durgadossr@nvidia.com>
This extends the `ptradd x, ptrtoint(y) - ptrtoint(x)` to `y`
InstCombine fold to support ptrtoaddr. In the case where x and y have
the same underlying object, this is handled by InstSimplify already. If
the underlying object may differ, the replacement can only be performed
if provenance does not matter.
For pointers with non-address bits we need to be careful here, because
the pattern will return a pointer with the non-address bits of x and the
address bits of y. As such, uses in ptrtoaddr are safe to replace, but
uses in ptrtoint are not. Whether uses in icmp are safe to replace
depends on the outcome of the pending discussion on icmp semantics (I'll
adjust this in https://github.com/llvm/llvm-project/pull/163936 if/when
that lands).
Favour a `cttz`-indexed table lookup over an indirect jump table when
the default switch case is reachable, by branching non-power-of-two
inputs to the default case.
Proofs: https://alive2.llvm.org/ce/z/HeRAtf.
In the past we used to only mark variables artificial that were
`isImplicit`. We would also omit the location information if the
variable's parent was implicit. Since
https://github.com/llvm/llvm-project/pull/100355 we made the logic to
mark variables as artificial the same as determining whether to omit its
location or not. This was to support binding variable declarations,
which we would like to have line information for (and don't want to mark
artificial as they are explicitly named in source).
However, this doesn't quite do the expected for parameters of
Objective-C synthesised property accessors. An Objective-C setter will
have an explicit parameter, which is the ivar to write to. However,
because the parent (i.e., the synthesised method) is artificial, we now
mark that parameter artificial. This is example debug-info for such an
accessor:
```
0x00000118: DW_TAG_subprogram
DW_AT_low_pc (0x0000000000000044)
DW_AT_high_pc (0x0000000000000078)
DW_AT_frame_base (DW_OP_reg29 W29)
DW_AT_object_pointer (0x00000128)
DW_AT_specification (0x00000068 "-[Foo setFooProp:]")
0x00000128: DW_TAG_formal_parameter
DW_AT_location (DW_OP_fbreg -8)
DW_AT_name ("self")
DW_AT_type (0x00000186 "Foo *")
DW_AT_artificial (true)
0x00000131: DW_TAG_formal_parameter
DW_AT_location (DW_OP_breg31 WSP+16)
DW_AT_name ("_cmd")
DW_AT_type (0x0000018b "SEL")
DW_AT_artificial (true)
0x0000013a: DW_TAG_formal_parameter
DW_AT_location (DW_OP_breg31 WSP+8)
DW_AT_name ("fooProp")
DW_AT_type (0x000000aa "id")
DW_AT_artificial (true)
```
Note how the `fooProp` parameter is marked artificial, although it
technically is an explicitly passed parameter. We want to treat the
synthesised method like any other, where explicitly passed parameters
aren't artificial. But we do want to omit the file/line info because it
doesn't exist in the source.
This patch prevents such parameters from being marked artificial. We
could probably generalise this to any kind of synthesised method, not
just Objective-C. But I'm currently not aware of such synthesised
functions, so made it Objective-C specific for now for testability.
*Motivator*
Marking such parameters artificial makes LLDB fail to parse the ObjC
method and emit an error such as:
```
error: Foo.o [0x00000000000009d7]: invalid Objective-C method DW_TAG_subprogram (DW_TAG_subprogram), please file a bug and attach the file at the start of this error message
```
rdar://163063569
This commit adds a new RadixTree to `SpecialCaseList` for handling
substring matches. Previously, `SpecialCaseList` only supported prefix
and suffix matching. With this change, patterns that have neither
prefixes nor suffixes can now be efficiently filtered.
According to SpecialCaseListBM:
Lookup benchmarks (significant improvements):
```
OVERALL_GEOMEAN -0.7809
```
Lookup `*test*` like benchmarks (huge improvements):
```
OVERALL_GEOMEAN -0.9947
```
https://gist.github.com/vitalybuka/ee7f681b448eb18974386ab35e2d4d27
This patch folds "std" into the std::hash specialization so that the
template mentions std::hash. std::hash is much easier to recognize
than std and hash separated by a couple of lines.
This patch achieves the "Rule of Zero" in DGNode by removing the
copy/move constructors and copy/move assignment operators.
Note that the code being deleted does a couple of unusual things that
are most likely oversight:
- The copy constructor with "explicit" is highly unusual. This means
that we allow "DGNode<N, E> A(B);" but disallow
"DGNode<N, E> A = B;".
- The move assignment operator with const r-value reference is also
unusual, especially given that the move constructor is correctly
implemented.
The map returned by collectStridedAccess is used to replace strides with
their versioned values. This does not work for Undef/Poison, which don't
have use-lists. Don't try to version them, as versioning won't be useful in
practice.
Fixes https://github.com/llvm/llvm-project/issues/162922.
Avoids adding alternative libcall impls for the same libcall.
I'm not sure if the default names exist or not, or are just not
preferred. compiler-rt appears to define aliases for all of these,
so I'm not sure why we bother distinguishing these in the first place.
The argument_type and result_type type aliases in std::hash are
deprecated in C++17 and removed in C++20. This patch aligns two
specializations of ours with the C++ standard.
