Logs just helped someone on Discord debug an issue in a way that would
not have been possible just by stepping the Python script. It was that
LLDB could not find the lldb-server binary.
We do talk about logs elsewhere but I think it's fine to repeat
here since it's a lot of people's first experience with scripting.
With the C++23 explicit object parameter feature, it is no longer
sufficient to only check if a function is an instance method to
determine if it has an implicit this argument. That causes problems in
attributes that have parameter indexes.
We aren't currently deduplicating contexts that are identical or nearly
identical (differing inline frame information) when generating the
profile. When we have multiple identical contexts we end up
conservatively marking it as non-cold, even if some are much smaller in
terms of bytes allocated.
This was causing us to lose sight of a very large cold context, because
we had a small non-cold one that only differed in the inlining (which we
don't consider when matching as the inlining could change or be
incomplete at that point in compilation). Likely the smaller one was
from binary with much smaller usage and therefore not yet detected as
cold.
Deduplicate the alloc contexts for a function before applying the
profile, selecting the largest one, or conservatively selecting the
non-cold one if they are the same size.
This caused a minor difference to an existing test
(memprof_loop_unroll.ll), which now only gets one message for the
duplicate context instead of 2. While here, convert to the text version
of the profile.
Depends on:
* https://github.com/llvm/llvm-project/pull/165686
This patch ensures we make use of the `DW_AT_bit_size` on
`DW_TAG_base_type`s (which since
https://github.com/llvm/llvm-project/pull/164372 can exist on
`_BitInt`s) and adjusts `TypeSystemClang` to recognize `_BitInt`.
For DWARF from older versions of Clang that didn't emit a
`DW_AT_bit_size`, we would create `_BitInt`s using the byte-size. Not
sure we can do much better than that. But the situation beforehand
wasn't much better.
Before:
```
(lldb) v
(char) a = '\x01'
(unsigned char) b = '\x01'
(long) c = 2
(unsigned long) d = 2
```
After:
```
(lldb) v
(_BitInt(2)) a = 1
(unsigned _BitInt(2)) b = 1
(_BitInt(52)) c = 2
(unsigned _BitInt(52)) d = 2
```
Fixes https://github.com/llvm/llvm-project/issues/110273
This change refactors G2S TMA implementation to use pure TableGen based
expansion instead verbose ISel DAG expansion. In addition, it adds
proper arch predicates for TMA G2S.
All the test cases are validated locally with CUDA 13.0 toolkit.
This PR extends the `nvvm.mma` ops to support fp64 type.
The extension requires special handling of the return type for load ops
for fragment `a` and `b` since they return a scalar instead of a struct.
Some analysis/transformation, e.g., predicate info/ mem ssa, insert
instruction annotations as comments, referring to
https://github.com/llvm/llvm-project/pull/165249#discussion_r2466200672.
This PR makes UTC support checking these instruction annotations with an
extra UTC option `-check-inst-comments`.
E.g.,
Before:
```LLVM
; CHECK: [[Z_0:%.*]] = bitcast i1 [[Z]] to i1
```
After:
```LLVM
; CHECK-NEXT: ; branch predicate info { TrueEdge: 0 Comparison: [[Z]] = and i1 [[XZ]], [[YZ]] Edge: [label [[TMP0:%.*]],label %nope], RenamedOp: [[Z]] }
; CHECK-NEXT: [[Z_0:%.*]] = bitcast i1 [[Z]] to i1
```
This PR also regenerates all UTC-generated tests for PredicateInfo; No
MemSSA test is updated, as there are no UTC-generated tests designated
for `print<memoryssa>`.
Insertion of a single bit into a large integer is typically
canonicalized to "(X & ~(1 << ShAmt)) | (InsertBit << ShAmt)", which can
be simplified to modify the i32 block as a BTR followed by an
OR((i32)InsertBit << (ShAmt % 32).
We must ensure that the InsertBit is zero apart from the LSB so we can
cheaply truncate it to work with the i32 block like the simpler BT
patterns.
This patch updates the mbarrier.init/inval Ops
to use the AnyTypeOf[] construct for their
`addr` argument. This enables us to have a
single Op that can take a pointer in either
generic or shared memory space and generate the
right intrinsics during the lowering.
* Updated existing tests accordingly.
* Verified locally that there are no new regressions in `integration`
tests.
* TODO: Additional updates for the remaining mbarrier Ops are in
progress.
These will be refactored in subsequent patches.
Signed-off-by: Durgadoss R <durgadossr@nvidia.com>
Per Intel Architecture Instruction Set Extensions Programming Reference
rev. 59 (https://cdrdv2.intel.com/v1/dl/getContent/671368), Revision
History entry for revision -59, AMX-TRANSPOSE was removed
Add support for multiple return statements in switch statements. Cases
in switch statements don't have their own scopes but are distinct
regions nonetheless. Insert multiple return blocks for each case and
handle them in the cleanup code.
This test seems to have taken the lit documentation at its word:
https://llvm.org/docs/CommandGuide/lit.html#substitutions
"%t temporary file name unique to the test"
%t is in fact the **path** of a file. As suggested by the line below
that describing %basename_t.
This test (I assume) assumed it was just the filename itself and so left
a layout of:
```
$ tree tools/lld/test/
tools/lld/test/
├── CMakeFiles
├── ELF
│ └── Output
│ ├── aarch64-build-attributes.s.tmp
│ │ ├── pauth-bti-gcs.s
│ │ └── pauth-bti-pac.s
│ ├── aarch64-build-attributes.s.tmp.merged.o
│ ├── aarch64-build-attributes.s.tmp1.o
│ ├── aarch64-build-attributes.s.tmp2.o
│ └── aarch64-build-attributes.s.tmp3.o
├── Unit
│ └── lit.site.cfg.py
├── cmake_install.cmake
└── lit.site.cfg.py
```
Note how the 2 .s files are in the temp dir but the .o files are not.
This is fine, it works, but it's going to cost someone time to unpick
when this test actually does fail.
To fix this, remove %t from all the temp file names so they are created
in the temp dir, which is cleaned before each run.
New layout:
```
$ tree tools/lld/test/
tools/lld/test/
├── CMakeFiles
├── ELF
│ └── Output
│ └── aarch64-build-attributes.s.tmp
│ ├── 1.o
│ ├── 2.o
│ ├── 3.o
│ ├── merged.o
│ ├── pauth-bti-gcs.s
│ └── pauth-bti-pac.s
├── Unit
│ └── lit.site.cfg.py
├── cmake_install.cmake
└── lit.site.cfg.py
```
This patch adds register bank legalization support for G_FADD opcodes in
the AMDGPU GlobalISel pipeline.
Added new reg bank type UniInVgprS64.
This patch also adds a combine logic for ReadAnyLane + Trunc + AnyExt.
---------
Co-authored-by: Abhinav Garg <abhigarg@amd.com>
When a load or store accesses N bytes starting from a pointer P, and we want to
compute an offset pointer within these N bytes after P, we know that the
arithmetic to add the offset must be inbounds. This is for example relevant
when legalizing too-wide memory accesses, when lowering memcpy&Co., or when
optimizing "vector-load -> extractelement" into an offset load.
For SWDEV-516125.
Similar motivation to https://github.com/llvm/llvm-project/pull/165702.
It was unused in all callsites and inconsistent with other APIs like
`IsIntegerType` (which doesn't take a `count` parameter).
If we ever need a "how many elements does this type represent", we can
implement one with a new TypeSystem API that does exactly that.
Some callsites checked for `count == 1` previously, but I suspect what
they intended to do is check for whether it's a vector type or complex
type, before reading the FP register. I'm somewhat confident that's the
case because the `TypeSystemClang::GetTypeInfo` currently incorrectly
sets the integer and floating point bits for complex and vector types
(will fix separately). But some architectures might choose to pass
single-element vectors in scalar registers. I should probably changes
these to check the vector element size.
All the `count == 2 && is_complex` were redundant because `count == 2`
iff `is_complex == true`. So I just removed the count check there.
The majority of this is running 2to3 on it:
* print is a function in 3.x
* next(it) instead of it.next()
Then there was a use of "map(None, iterables..)"
which in Python 2 was a way of saying
"combine these iterables, and if one is shorter,
pad with None".
This no longer works in Python3, the equivalent
is zip_longest:
https://docs.python.org/3/library/itertools.html#itertools.zip_longest
fillvalue defaults to None but I made it explicit
since it may help someone debugging this script
in future.
(I doubt it has been used for a very long time)
We were setting these bits inverted. Not sure how this bug actually
manifests, I just noticed when working on
https://github.com/llvm/llvm-project/pull/165707. I suspect these types
just aren't very frequently used.
LLVM now requires Python >= 3.8, and ConfigParser was renamed to
configparser in 3.0:
https://docs.python.org/3/whatsnew/3.0.html#library-changes
A few places imported it under the Python2 name even for Python3, I have
swapped those to the Python3 name.
This was reported by https://pypi.org/project/vermin/ as the file having
incompatible versions. Since once import is 2.x and one is 3.x.
This patch makes `dwarfdump` show the `DW_AT_APPLE_property_name` of a
referenced `DW_TAG_APPLE_property` (similar to how we show the name of a
referenced `DW_AT_type`). Eventually we'll extend this to the DWARFv6
property tags too.
Before:
```
0x00000013: DW_TAG_APPLE_property
DW_AT_APPLE_property_name ("propertyName")
0x0000001b: DW_TAG_member
DW_AT_name ("_ivar")
DW_AT_APPLE_property (0x00000013)
```
After:
```
0x00000013: DW_TAG_APPLE_property
DW_AT_APPLE_property_name ("propertyName")
0x0000001b: DW_TAG_member
DW_AT_name ("_ivar")
DW_AT_APPLE_property (0x00000013 "propertyName")
```
In #165604, a test was skipped on Windows, because the native PDB plugin
didn't set sizes on symbols. While the test isn't compiled with debug
info, it's linked with `-gdwarf`, causing a PDB to be created on
Windows. This PDB will only contain the public symbols (written by the
linker) and section information. The symbols themselves don't have a
size, however the DIA SDK sets a size for them.
It seems like, for these data symbols, the size given from DIA is the
distance to the next symbol (or the section end).
This PR implements the naive approach for the native plugin. The main
difference is in function/code symbols. There, DIA searches for a
corresponding `S_GPROC32` which have a "code size" that is sometimes
slightly smaller than the difference to the next symbol.
If an instruction at the high end of the 32-bit address space branches
to one at the low end, then the branch can be within range for a B or BL
instruction, and doesn't need a veneer. `ARM::inBranchRange` was failing
to detect this because it calculated the offset as an int64_t, so that
the offset was a small value ± 2^32 instead of just the small value.
Fixes#165211.
Prior to this change, the data layout calculation would not account for
explicitly set `-mabi=elfv2` on `powerpc64-unknown-linux-gnu`, a target
that defaults to `elfv1`.
This is loosely inspired by the equivalent ARM / RISC-V code.
`make check-llvm` passes fine for me, though AFAICT all the tests
specify the data layout manually so there isn't really a test for this
and I am not really sure what the best way to go about adding one would
be.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
This PR preserves the InBounds flag (#162477) where possible in PTRADD-related
DAGCombines. We can't preserve them in all the cases that we could in the
analogous GISel change (#152495) because SDAG usually represents pointers as
integers, which means that pointer provenance is not preserved between PTRADD
operations (see the discussion at PR #162477 for more details). This PR marks
the places in the DAGCombiner where this is relevant explicitly.
For SWDEV-516125.
In ELF file, there is a possible extended header for those phnum, shnum,
and shstrndx larger than the maximum of 16 bits. This extended header
use section 0 to record these fields in 32 bits.
We implment this feature so that programs rely on
ELFFile::program_headers() can get the
correct number of segments. Also, the consumers don't have to check the
section 0 themselve, insteead, they can use the getPhNum() as an
alternative.
There were a couple of quirks with this parameter:
1. It wasn't being set consistently. E.g., vector types would be of
count `1` but complex types would be `2`. Hence, it wasn't clear what
count was referring to.
2. `count` was not being set if the input type was invalid, possibly
leaving the input reference uninitialized.
3. Only one callsite actually made use of `count`, and that in itself
seems like it could be improved (added a FIXME).
If we ever need a "how many elements does this type represent", we can
implement one with a new `TypeSystem` API that does exactly that.
Cherry-picks this fix from the Apple LLDB fork. Ever since we upstreamed
https://github.com/llvm/llvm-project/pull/164011, this test is failing
on our pre-DWARFv5 bots:
```
13:47:54 ======================================================================
13:47:54 FAIL: test_frame_var_after_stop_at_implementation_dsym (TestRealDefinition.TestRealDefinition)
13:47:54 Test that we can find the implementation for an objective C type
13:47:54 ----------------------------------------------------------------------
13:47:54 Traceback (most recent call last):
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1804, in test_method
13:47:54 return attrvalue(self)
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/objc/real-definition/TestRealDefinition.py", line 60, in test_frame_var_after_stop_at_implementation
13:47:54 self.expect(
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2416, in expect
13:47:54 self.runCmd(
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1006, in runCmd
13:47:54 self.assertTrue(self.res.Succeeded(), msg + output)
13:47:54 AssertionError: False is not true : Variable(s) displayed correctly
13:47:54 Error output:
13:47:54 error: <user expression 0>:1:12: "_hidden_ivar" is not a member of "(id) _bar"
13:47:54 1 | foo->_bar->_hidden_ivar
13:47:54 | ^
```
Original commit message:
For a while, tests were run with `target.prefer-dynamic-value`
overridden to `no-dynamic-values` – but the override was removed in
[D132382](https://reviews.llvm.org/D132382). At that time, tests that
failed were individually opted in to `no-dynamic-values`.
I don't recall specifics about `TestRealDefinition`, but it currently
fails with `no-dynamic-values`, and that is correct behavior. This
change removes the `no-dynamic-values` override.
Fix missed `return` when folding splat ConstantOp, it could work well
probably because of good compatibility of
`foldExtractStridedSliceNonSplatConstant`.
These tests are currently failing on some CI macOS instances due to an
issue with the system symbolizer.
This patch marks the tests unsupported on Darwin while we wait for all
CI machines to be updated to a newer OS.
rdar://160410051
