forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[pull] main from llvm:main #152
Merged
Merged
Conversation
This file contains 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
We were using the type of the loop back edge count to represent the store size. This failed for small loop counts (e.g. in the added test, the loop count was an i2). Use the index type instead. Fixes PR52104. Differential Revision: https://reviews.llvm.org/D111401
This is failing on Arm and AArch64 Linux buildbots since the time it was comitted. https://lab.llvm.org/buildbot/#/builders/96/builds/12628 Differential Revision: https://reviews.llvm.org/D107585
Now that PR52104 is fixed.
Add pass that convert abstract result to function argument. This pass is needed before the conversion to LLVM IR. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D111146 Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Due to reported failures in a local build. FAIL: Something is wrong in the test framework. Converting character sets: Invalid argument. (was enabled in https://reviews.llvm.org/D111138)
…ction patterns This patch adds further support for vectorisation of loops that involve selecting an integer value based on a previous comparison. Consider the following C++ loop: int r = a; for (int i = 0; i < n; i++) { if (src[i] > 3) { r = b; } src[i] += 2; } We should be able to vectorise this loop because all we are doing is selecting between two states - 'a' and 'b' - both of which are loop invariant. This just involves building a vector of values that contain either 'a' or 'b', where the final reduced value will be 'b' if any lane contains 'b'. The IR generated by clang typically looks like this: %phi = phi i32 [ %a, %entry ], [ %phi.update, %for.body ] ... %pred = icmp ugt i32 %val, i32 3 %phi.update = select i1 %pred, i32 %b, i32 %phi We already detect min/max patterns, which also involve a select + cmp. However, with the min/max patterns we are selecting loaded values (and hence loop variant) in the loop. In addition we only support certain cmp predicates. This patch adds a new pattern matching function (isSelectCmpPattern) and new RecurKind enums - SelectICmp & SelectFCmp. We only support selecting values that are integer and loop invariant, however we can support any kind of compare - integer or float. Tests have been added here: Transforms/LoopVectorize/AArch64/sve-select-cmp.ll Transforms/LoopVectorize/select-cmp-predicated.ll Transforms/LoopVectorize/select-cmp.ll Differential Revision: https://reviews.llvm.org/D108136
AAPCS requires i1 argument to be zero-extended to 8-bits by the caller. Emit a new AArch64ISD::ASSERT_ZEXT_BOOL hint (or AssertZExt for GlobalISel) to enable some optimization opportunities. In particular, when the argument is forwarded to the callee, we can avoid zero-extension and use it as-is. Differential Revision: https://reviews.llvm.org/D107160
As for 128-bit floating points on PowerPC, compiler should have three machine modes: - IFmode, always IBM extended double - KFmode, always IEEE 754R 128-bit floating point - TFmode, matches the semantics for long double This commit adds support for IF mode with its complex variant, IC mode. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D109950
TestInferiorAssert.py test_inferior_asserting_disassemble passes after upgrading LLDB AArch64/Linux buildbot to Ubuntu Focal.
Combine m_read_sp and m_write_sp into a single m_io_sp. In all currently existing code paths, they are pointing to the same object anyway. Differential Revision: https://reviews.llvm.org/D111396
I believe this is a more natural behavior, and it also matches what gdb does. Differential Revision: https://reviews.llvm.org/D111399
…l types The lowering for EXTRACT_SUBVECTOR should not be called during type legalization, only as part of lowering, hence return SDValue() when called on illegal types. This also adds missing tests for extracting fixed types from illegal scalable types. Differential Revision: https://reviews.llvm.org/D111412
…RFEncodingAndBitSize The current code just prints to the System's 'error log' which is usually stderr (+ some other log backend). Printing to stderr however just interferes with LLDB's console UI, so when this code is triggered during for example command completion it just breaks the LLDB console interface until the next redraw. Instead just use the normal LLDB log which is by default hidden and is what users usually attach to bug reports. The only known bug that triggers this is https://bugs.llvm.org/show_bug.cgi?id=46775 Reviewed By: labath Differential Revision: https://reviews.llvm.org/D111149
This adds support for parsing DW_AT_calling_convention in the DWARF parser. The generic DWARF parsing code already support extracting this attribute from A DIE and TypeSystemClang already offers a parameter to add a calling convention to a function type (as the PDB parser supports calling convention parsing), so this patch just converts the DWARF enum value to the Clang enum value and adds a few tests. There are two tests in this patch.: * A unit test for the added DWARF parsing code that should run on all platforms. * An API tests that covers the whole expression evaluation machinery by trying to call functions with non-standard calling conventions. The specific subtests are target specific as some calling conventions only work on e.g. win32 (or, if they work on other platforms they only really have observable differences on a specific target). The tests are also highly compiler-specific, so if GCC or Clang tell us that they don't support a specific calling convention then we just skip the test. Note that some calling conventions are supported by Clang but aren't implemented in LLVM (e.g. `pascal`), so there we just test that if this ever gets implemented in LLVM that LLDB works too. There are also some more tricky/obscure conventions that are left out such as the different swift* conventions, some planned Obj-C conventions (`Preserve*`), AAPCS* conventions (as the DWARF->Clang conversion is ambiguous for AAPCS and APPCS-VFP) and conventions only used for OpenCL etc. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D108629
This patch adds a new abstract class for frontend actions: `PrescanAndSemaDebugAction`. It's almost identical to `PrescanAndSemaAction`, but in the presence of semantic errors it does not skip the corresponding `ExecuteAction` specialisation. Instead, it runs it as if there were no semantic errors. This class is for developer actions only (i.e. front-end driver options). The new behaviour does not affect the return code from `flang-new -fc1` when the input file is semantically incorrect. The return code is inferred from the number of driver diagnostics generated in `CompilerInstance::ExecuteAction` and this patch does not change that. More specifically, the semantic errors are still reported and hence the driver is able to correctly report that the compilation has failed (with a non-zero return code). This new base class is meant for debug actions only and `DebugDumpAllAction` is updated to demonstrate the new behaviour. With this change, `flang-new -fc1 -fdebug-dump-all` dumps the parse tree and symbols for all input files, regardless of whether any semantic errors were found. This patch addresses https://bugs.llvm.org/show_bug.cgi?id=52097. Differential Revision: https://reviews.llvm.org/D111308
Update .clang-tidy file with the value used in fir-dev. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: rovka Differential Revision: https://reviews.llvm.org/D111525 Co-authored-by: Valentin Clement <clementval@gmail.com>
Rewrite the register reading/writing tests to use explicit qRegisterInfo packets rather than relying on ARM registers being hardcoded in LLDB. While at it, use x86_64 for tests -- since it was easier for me to get the register lists from that architecture. Differential Revision: https://reviews.llvm.org/D111496
…eak undef I noticed that we had this case in our internal testsuite but couldn't find it in LLD's tests. This adds that case. Differential Revision: https://reviews.llvm.org/D110716
…:ParseSingleMember D68422 introduced `ParsedDWARFTypeAttributes` which encapsulated attribute parsing and storage into its own small struct. This patch is doing the same for the member type attribute parsing. One utility class is parsing normal member attributes and the other is parsing the dedicated Objective-C property attributes. Right now the patch just makes the `ParseSingleMember` function a bit shorter, but the bigger benefit is that we can now split up the function into Objective-C property parsing and parsing of normal members (struct/class members and Objective-C ivars). The only shared code between those two parsing logic is the normal member attribute parsing. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D111494
Clean up InitFIR.h file. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D111539 Co-authored-by: Valentin Clement <clementval@gmail.com>
…ault_accessibility parameter
… or(pshufb,pshufb) fold (PR52122) The select(pshufb,pshufb) -> or(pshufb,pshufb) fold uses getConstVector to create the refreshed pshufb masks, which treats all negative indices as undef. PR52122 shows that if we were selecting an element that the PSHUFB has set to zero we must set it back to 0x80 when we recreate the PSHUFB mask and not just leave it as SM_SentinelZero
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )