This mostly copies cases that already exist in ValueTracking, although
it skips the more complex ones. Those can be filled in as needed.

Reviewed By: RKSimon

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

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

This is done by allowing speculation of `udiv` if we can prove the
denominator is non-zero.

https://alive2.llvm.org/ce/z/VNCt_q

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

Reviewed By: pengfei

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

This comes up when adding two `bool` types in C/C++
```
    bool foo(bool a, bool b) {
        return a + b;
    }
    ...
    ->
    define i1 @foo(i1 %a, i1 %b) {
        %conv = zext i1 %a to i32
        %conv3.neg = sext i1 %b to i32
        %tobool4 = icmp ne i32 %conv, %conv3.neg
        ret i1 %tobool4
}
```

Proof: https://alive2.llvm.org/ce/z/HffWAN

Reviewed By: nikic

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

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

This patch partly reverts the change that was made in 5f1ba3a5
regarding the clock selection on Apple platforms. It turns out that
gettimeofday() is marked as obsolete by POSIX and clock_gettime() is
recommended instead. Since both are equivalent for our purposes,
prefer using clock_gettime() even on Apple platforms.

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

When debugserver is attaching to a process, it first task_for_pid()'s
and then ptrace(PT_ATTACHEXC)'s.  When that ptrace() fails to complete,
we are in a semi-attached state that we need to give up from, and
our error reporting isn't ideal -- we can even claim that the process
is already being debugged (by ourselves).

Differential Revision: https://reviews.llvm.org/D155037
rdar://101152233

Consistency with how we tend to name `ModuleAnalysisManager` parameters.

Co-authored-by: pscoro

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

In SPIR-V, the capabilities for storage and compute are separate.
We have good handling of the storage side in general via MemRef
type conversion and various `memref` dialect ops.

Once the value was loaded properly, if the compute capability is
supported directly, we don't need to emulate like the storage side
with int32. However, we do need to make sure casting ops are
properly inserted to chain the flow to go back to the original
bitwidth.

Right now that is done in the each individual pattern directly,
which put lots of pressure that shouldn't be on the patterns and
causes duplication and trickiness w.r.t. capability check and such.

Instead, we should handle such casting within the SPIR-V conversion
framework using `addSourceMaterialization`, where we can check with
the target environment to make sure the corresponding compute
capability is allowed and then we can materialize and SPIR-V casting
op.

Along the way, we can drop all the duplicated cast materialization
registration in various places.

Reviewed By: kuhar

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

Reviewed By: kuhar

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

Add lowering support for reduction with the add operator
on complex type.

Reviewed By: razvanlupusoru

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

To check the uniqueness of buildids, we held on to a StringRef of the build id string pushed into the vector. If the number of build ids were large enough to trigger a realloc in the vector then these references where invalidated resulting in a use-after free. This was exposed in downstream usage.

Reviewed By: tejohnson

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

There's no caller to `promoteIndirectCalls` that would pass a nullptr
`ModuleAnalysisManager`, so passing it by reference does away with a
bunch of nullptr tests, and also removes the need for a "OwnedORE".

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

This was broken by 56ac9d46.
There were some changes made to fix it in
a20d57e8, but that did not quite
fix everything.

Reviewed By: nemanjai

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

If I understand it correctly, the TODO is intended to catch cases
when we may need to create a temporary array for polymorphic entities
resulting from a vector subscription, i.e. when the final expression
type of hlfir.elemental_addr is polymorphic. The TODO check was done
very early, so it kicked in for cases where the it should not have.
For example,
```
type t
  integer n
end type
class(t), pointer :: p(:)
... p(vector_of_indices)%n
```

Such designators are supported by FIR lowering and can be currently
supported by HLFIR, but the TODO prevented this. I just moved the TODO
check later in the lowering pipeline.

I also updated the comment trying to describe my understanding of how
the correct mold entity can be computed for the elemental operation
producing HLFIR expression of polymorphic type.

This change provides 34 new passes in my nag testing.

Reviewed By: tblah

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

Reviewed By: Craig Topper

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

Reviewed By: ldionne, #libc

Spies: arichardson, mgrang, krytarowski, libcxx-commits, h-vetinari

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

Add support for the `.neqv.` reduction operator for
Flang/OpenACC lowering.

Depends on D154900

Reviewed By: razvanlupusoru

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

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

Fix a miscompilation crash where swiftself on x20 gets corrupted due
to incorrect save/restore at prologue/epilogue.

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

Add support for the `.eqv.` reduction operator for
Flang/OpenACC lowering.

Depends on D154898

Reviewed By: razvanlupusoru

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

Add support for the `.or.` reduction operator for
Flang/OpenACC lowering.

Depends on D154896

Reviewed By: razvanlupusoru

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

We were checking that the encoding within our internal list of
registers was even. This worked today because X0 happens to have
an even value in that enum. This can break if any registers are
added before X0.

The correct check is to make sure it has an even offset from X0.

Reviewed By: asb

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

Our downstream needs to give different scheduling for min/max from
other reductions.

Reviewed By: michaelmaitland

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

We've completed the transition from SVN to Git, and the listed projects
are not included in the repository.

This wasn't causing any bots to fail, so is just minor cleanup.

Add support for the `.and.` reduction operator
in Flang/OpenACC lowering.

Depends on D154888

Reviewed By: razvanlupusoru

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

The return type of the recipe must match the array slice provided by
the user. This patch enhance the recipe creation to take into account
the constant slices.

Depends on D154657

Reviewed By: razvanlupusoru

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

Similiar to D154259 for private recipe, this patch makes use of the same code
for the init region of the firstprivate recipe and populate the copy region for
trivial types and arrays.

Reviewed By: razvanlupusoru

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

This patch adds initial support for the `AAAddressSpace` abstract
attributor interface to deduce and query address space information for a
pointer. We simply query the underlying objects that a pointer can point
to and find a common address space if they exist. This is the minimal
support for the interface, we currently manifest changes on loads and
stores. Additionally we should use the target transform information to
deduce if an address space transformation is a no-op for the target
machine when calculating compatibility.

Reviewed By: jdoerfert

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

Ideally BTFParserTest.cpp should test both little-endian and big-endian, but I
push this commit to fix the immediate issue for now.

Currently, there are no tests to confirm without a doubt the constructor of latch is really constexpr and explicit.
I think this would be an addition that it would not harm to have. In another revision, I was asked to add tests for an almost identical case which made me consider adding this test for the latch class too.

Reviewed By: #libc, philnik

Spies: philnik, libcxx-commits, kristof.beyls

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

If I read the standard correctly, the public constructor of "barrier" should be marked as "constexpr explicit".
I see some of the internal classes used by the barrier header are correctly marked but I think, if I'm not mistaken, the standard would like the public class to have the correct definition as well.

Because the implementation that llvm uses by default is not constexpr friendly at this time, this revision will focus on only marking it as explicit.

Reviewed By: #libc, philnik, Mordante

Spies: philnik, Mordante, libcxx-commits

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

replaceCongruentIVs analysis is based on ScalarEvolution; this makes
comparing different PHIs and performing the replacement straightforward.
However, it can have some side-effects: it isn't aware whether an
induction variable is in canonical form, so it can perform replacements
which obscure the meaning of the IR.

In test22 in widen-loop-comp.ll, the resulting loop can't be analyzed by
ScalarEvolution at all.

My attempted solution is to restrict the transform: don't try to replace
induction variables using PHI nodes that don't represent simple
induction variables.

I'm not sure if this is the best solution; suggestions welcome.

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

This patch adds support for vectorized reduction of maximum/minimum
intrinsics which are under the appropriate reduction kind.

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