Skip to content
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 25 commits into from
Oct 11, 2021
Merged

[pull] main from llvm:main #152

merged 25 commits into from
Oct 11, 2021

Conversation

pull[bot]
Copy link

@pull pull bot commented Oct 11, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

legrosbuffle and others added 25 commits October 11, 2021 09:39
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
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>
… 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
@pull pull bot added the ⤵️ pull label Oct 11, 2021
@pull pull bot merged commit ad16c6e into MaxMood96:main Oct 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.