[pull] main from llvm:main #644
Merged
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
This reverts commit 16ab8c0. It appears this broke a couple of buildbots: 1. https://lab.llvm.org/buildbot/#/builders/193/builds/11847 2. https://lab.llvm.org/buildbot/#/builders/161/builds/8736 Reverting for now so I have a chance to investigate.
Include Unit-stride, Strided, Mask store.
…tVectorToLLVM.cpp (NFC)
…n SuperVectorize.cpp (NFC)
…generic NULL (#165353) Fix a regression caused by 1ffff05. OpenCL/SPIRV generic address space doesn't cover constant address space. --------- Co-authored-by: Alexey Bader <[email protected]>
…st unsupported (#165408) 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
…65669) Fix missed `return` when folding splat ConstantOp, it could work well probably because of good compatibility of `foldExtractStridedSliceNonSplatConstant`.
Cherry-picks this fix from the Apple LLDB fork. Ever since we upstreamed #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.
#165702) 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.
This adds G_SBFX/G_UBFX to the list of instructions that do not generate poison, to allowing freeze to be hoisted above one.
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.
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.
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 <[email protected]>
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.
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.
) 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") ```
…63727) 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.
) We were setting these bits inverted. Not sure how this bug actually manifests, I just noticed when working on #165707. I suspect these types just aren't very frequently used.
…163730) LLVM requires Python >=3.8 and in Python 3.0 urllib2 was renamed to urllib. https://docs.python.org/3/whatsnew/3.0.html#library-changes
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)
…ord.py (#163744) LLVM requires Python >= 3.8. itervalues was unused so I have removed it.
Fixes 35e1a2f itervalues is in fact used in opt-viewer.py.
…PointType (#165707) Similar motivation to #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.
…ew.py (#163747) All these modules got new names or were moved around in Python 3.0: https://docs.python.org/3/whatsnew/3.0.html#library-changes LLVM requires Python >= 3.8 so we don't need to try Python2 naming.
…AG_APPLE_property (#165409) Depends on: * #165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.
…165425) 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.
…alable vectors. (#165437)
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 <[email protected]>
"How To Release LLVM To The Public" [1] mentions to add the release:reviewed label once a bug has been reviewed, but looking at the label [2] it seems this hasn't been followed for quite a long time, so I propose we remove it. [1] https://llvm.org/docs/HowToReleaseLLVM.html#triaging-bug-reports-for-releases [2] https://github.com/llvm/llvm-project/issues?q=label%3Arelease%3Areviewed
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 ```
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.
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
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 <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )