merge main into amd-staging #404
Merged
+2,458
−379
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…property accessors artificial (llvm#164998) 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 llvm#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
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.
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 llvm#163936 if/when that lands).
…#164996) If they aren't const. Fixes llvm#164985
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>
STAR-MC3 is an Armv8.1m CPU. Technical specificationa available at: https://www.armchina.com/download/Documents/TRM?infoId=240
…er_atomic_{{add|fadd|fmin|fmax}} (llvm#164824)
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.
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.
emitDummyPtr() doesn't like to be called with DiscardResult set, so check this first. Fixes llvm#164979
…164956) 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.
We can't read from non-block pointers anyway. Fixes llvm#165061
Prior to llvm#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 (llvm#100355) landed. This patch adds a test that explicitly checks that the type of the setter is sensible. This test fails without llvm#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.
Varies by host but I think it's useful to give some expectation.
Post cleanup for llvm#164534. Not all attributes are stripped, some of them may affect debug info.
…F 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.
…g versions
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.
We can't save the result in a non-block pointer. Fixes llvm#165076
…DWARF versions on macOS On Linux we would use the manual DWARF index and the failing test assertion (see `c40b6904751da529a0436faf72d5d63d35484689`) would still pass.
Collaborator
Author
ranapratap55
approved these changes
Oct 27, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.