If the last step in an FP add reduction allows reassociation and doesn't care
about -0.0, then we are free to recognize that computation as a reduction
that may reorder the intermediate steps.

This is requested directly by PR42705:
https://bugs.llvm.org/show_bug.cgi?id=42705
and solves PR42947 (if horizontal math instructions are actually faster than
the alternative):
https://bugs.llvm.org/show_bug.cgi?id=42947

Differential Revision: https://reviews.llvm.org/D66236

llvm-svn: 368995

This patch slightly changes the API in the attempt to simplify resource buffer
queries. It is done in preparation for a patch that will enable support for
macro fusion.

llvm-svn: 368994

Some uses of getArgumentAliasingToReturnedPointer and
isIntrinsicReturningPointerAliasingArgumentWithoutCapturing require the
calls/intrinsics to preserve the nullness of the argument.

For alias analysis, the nullness property does not really come into
play.

This patch explicitly sets it to true. In D61669, the alias analysis
uses will be switched to not require preserving nullness.

Reviewers: nlopes, efriedma, hfinkel, sanjoy, aqjune, jdoerfert

Reviewed By: jdoerfert

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D64150

llvm-svn: 368993

llvm-svn: 368992

llvm-svn: 368991

The implementation in libc++ takes O(1) compile time, ours was O(n).

llvm-svn: 368990

llvm-svn: 368989

Stack loads and stores were already working, but direct stores were not. This
adds the patterns for them, same as predicate loads.

Differential Revision: https://reviews.llvm.org/D66213

llvm-svn: 368988

This patch changes the location of the frame-record (FP, LR) to the 
bottom of the callee-saved area. According to the AAPCS the location of
the frame-record within the stackframe is unspecified (section 5.2.3 The 
Frame Pointer), so the compiler should be free to choose a different
location.

The reason for changing the location of the frame-record is to prepare
the frame for allocating an SVE area below the callee-saves. This way the 
compiler can use the VL-scaled addressing modes to directly access SVE 
objects from the frame-pointer.

            :                :   
        | stack |        | stack |
        |  args |        |  args |
        +-------+        +-------+
        |  x30  |        |  x19  |
        |  x29  |        |  x20  |
  FP -> |- - - -|        |  x21  |
        |  x19  |   ==>  |  x22  |
        |  x20  |        |- - - -|
        |  x21  |        |  x30  |
        |  x22  |        |  x29  |
        +-------+        +-------+ <- FP
        |///////|        |///////|         // realignment gap 
        |- - - -|        |- - - -|
        |spills/|        |spills/|
        | locals|        | locals|
  SP -> +-------+        +-------+ <- SP

Things to point out:
- The algorithm to find a paired register should be prevented from
  accidentally pairing some callee-saved register with LR that is not 
  FP, since they should always be paired together when the frame
  has a frame-record.
- For Darwin platforms the location of the frame-record is unchanged,
  since the unwind encoding does not allow for encoding this position
  dynamically and other tools currently depend on the former layout. 

Reviewers: efriedma, rovka, rengolin, thegameg, greened, t.p.northover

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D65653

llvm-svn: 368987

This patch adds a ptrmask intrinsic which allows masking out bits of a
pointer that must be zero when accessing it, because of ABI alignment
requirements or a restriction of the meaningful bits of a pointer
through the data layout.

This avoids doing a ptrtoint/inttoptr round trip in some cases (e.g. tagged
pointers) and allows us to not lose information about the underlying
object.

Reviewers: nlopes, efriedma, hfinkel, sanjoy, jdoerfert, aqjune

Reviewed by: sanjoy, jdoerfert

Differential Revision: https://reviews.llvm.org/D59065

llvm-svn: 368986

This reverts commit cad8356d.

To unbreak Windows bots

llvm-svn: 368985

llvm-svn: 368984

Like rLLD354040.

Previously, for unrecognized relocation types, in -no-pie/-pie mode, we got something like:

  foo.o: unrecognized relocation ...

In -shared mode:

  error: can't create dynamic relocation ... against symbol: yyy in readonly segment

Delete the default case from AArch64::getRelExpr and add the error there.

Reviewed By: grimar

Differential Revision: https://reviews.llvm.org/D66277

llvm-svn: 368983

add-symbol

Reviewers: Maskray, rupprecht

Differential Revision: https://reviews.llvm.org/D65891

llvm-svn: 368982

This adds patterns for selecting trunc instructions from full vectors to i1's
vectors.

Differential Revision: https://reviews.llvm.org/D66201

llvm-svn: 368981

This is more of a temporary fix, long term, we should convert AnalyzerOptions.def
into the universally beloved (*coughs*) TableGen format, where they can more
easily be separated into developer-only, alpha, and user-facing configs.

Differential Revision: https://reviews.llvm.org/D66261

llvm-svn: 368980

Differential Revision: https://reviews.llvm.org/D60281

llvm-svn: 368979

llvm-svn: 368978

Summary:
In case the function was called with a desired read size *and* the file
was not an "mmap()" candidate, the function was falling back to a
"pread()", but it was failing to check the result of that system call.
This meant that the function would return "success" even though the read
operation failed, and it returned a buffer full of uninitialized memory.

Reviewers: rnk, dblaikie

Subscribers: kristina, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66224

llvm-svn: 368977

Just a refactoring and a tidy up.

Differential Revision: https://reviews.llvm.org/D64564

llvm-svn: 368976

Summary:
When building with modules we currently fail randomly to build LLDB's modules and get error messages like below:
```
In file included from <module-includes>:1:
In file included from llvm-project/llvm/include/llvm/IR/Argument.h:18:
llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found
    #include "llvm/IR/Attributes.inc"
             ^~~~~~~~~~~~~~~~~~~~~~~~
...
In file included from llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp:9:
llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.h:12:10: fatal error: could not build module 'lldb_Wrapper'
```

The reason for this is that our source files can include Clang headers which in turn include files like Attributes.inc which
are generated by intrinsics_gen. However, it seems Clang can't express this dependency in its CMake code, so intrinsics_gen
is actually not guaranteed to be built before we start parsing LLDB source files and Clang headers. Clang worked around this
by letting all libraries depend on intrinsics_gen, which at least lets their builds pass.

As I haven't figured out how to solve these dependencies properly and I want to get the LLDB+Modules build green,
I suggest we copy Clang's hack until we figure out how to get Clang's dependencies right.

Reviewers: sgraenitz, aprantl, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: mgorny, javed.absar, kristof.beyls, mgrang, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D66208

llvm-svn: 368975

Summary:
Currently, llvm-readobj mistakenly decodes section type as section attribute.

This patch fixes the bug and affected tests.

Reviewers: JDevlieghere, jhenderson, rupprecht, alexshap, echristo

Reviewed By: jhenderson, rupprecht, alexshap, echristo

Subscribers: javed.absar, rupprecht, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66075

llvm-svn: 368974

assume_safety implies that loads under "if's" can be safely executed
speculatively (unguarded, unmasked). However this assumption holds only for the
original user "if's", not those introduced by the compiler, such as the
fold-tail "if" that guards us from loading beyond the original loop trip-count.
Currently the combination of fold-tail and assume-safety pragmas results in
ignoring the fold-tail predicate that guards the loads, generating unmasked
loads. This patch fixes this behavior.

Differential Revision: https://reviews.llvm.org/D66106

Reviewers: Ayal, hsaito, fhahn
llvm-svn: 368973

[X86] Add isel pattern to match VZEXT_MOVL and a v2i64 scalar_to_vector bitcasted from x86mmx to MOVQ2DQ.

We already had the pattern for just the scalar to vector and bitcast,
but not the case where we wanted zeroes in the high half of the xmm.

llvm-svn: 368972

This pattern will narrow the load so we should make sure its not
volatile.

llvm-svn: 368971

New pragma "vectorize_predicate(enable)" now implies "vectorize(enable)",
and it is ignored when vectorization is disabled with e.g.
"vectorize(disable) vectorize_predicate(enable)".

Differential Revision: https://reviews.llvm.org/D65776

llvm-svn: 368970

llvm-svn: 368969

fp_to_sint is turned into X86cvttp2si during isel preprocessing.
The other redundant isel patterns were removed previously, but I
missed this one because its in the MMX td file.

llvm-svn: 368968

The default legalization can take care of this.

llvm-svn: 368967

The generic legalization handles this in the same way so just use
that.

llvm-svn: 368966

llvm-svn: 368965

Like rLLD354040.

Previously, for unrecognized relocation types, in -no-pie mode:

  foo.o: unrecognized reloc 256

In -pie/-shared mode:

  error: can't create dynamic relocation R_PPC_xxx against symbol: yyy in readonly segment

llvm-svn: 368964

Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41905

Reviewers: jhenderson, rupprecht, grimar

Reviewed By: jhenderson, grimar

Subscribers: RKSimon, MaskRay, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D62462

llvm-svn: 368963

I updated the signature to conform to the LLDB coding style but
accidentally forgot to update the function body.

llvm-svn: 368962

Summary: This avoids maintaining the same options in two different places.

Reviewers: jhenderson, alexshap, rupprecht, MaskRay

Reviewed By: jhenderson, rupprecht, MaskRay

Subscribers: MaskRay, wolfgangp, jakehehrlich, abrachet, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D65991

llvm-svn: 368961

Now that LLVM moved to C++14, `COMPILER_RT_HAS_STD_CXX11_FLAG` should
become `COMPILER_RT_HAS_STD_CXX14_FLAG`.

I ran into this issue when replacing llvm::make_unique with
std::make_unique in an X-ray unit test. We are correctly passing
`-std=c++14`, but this got overwritten further down the invocation by
the compiler-rt flags. Given that this unit test is using LLVM headers,
this is bound to break sooner than later, regardless of my change.

Differential revision: https://reviews.llvm.org/D66271

llvm-svn: 368960

This fixes a few warnings emitted when compiling with -Wdocumentation.

llvm-svn: 368959

The change in r368681 contains a (probably unintentional) behavioral change for
rewrite rules with a single matcher. Previously, the single matcher would not
need to be bound (`joinCaseMatchers` returned it directly), even though a final
DynTypeMatcher was created and bound by `buildMatcher`. With the new change, a
single matcher will be bound, in addition to the final binding (which is now in
`buildMatchers`, but happens roughly at the same point in the overall flow).

This patch simply duplicates the "final matcher" trick: it creates an extra
DynTypedMatcher for each rewrite rule case matcher, and unconditionally makes it
bindable. This is probably not the right long-term fix, but it does allow
existing code to continue to work with this interface.

Subscribers: cfe-commits, gribozavr, ymandel

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66273

llvm-svn: 368958

Remove the @return to fix the warning: '@returns' command used in a
comment that is attached to a function returning void [-Wdocumentation]

llvm-svn: 368957

If the width is 256 bits, then we must have AVX so the else here
was unnecessary. Once that's removed then the >= 256 bit code is
identical to the 128 bit code with a different VT so combine them.

llvm-svn: 368956