This reverts commit 76940577.

This causes Transforms/LoopUnroll/ARM/multi-blocks.ll to fail.

ValueTracking should allow for value ranges that may satisfy
llvm.assume, instead of restricting the ranges only to values that
will always satisfy the condition.

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

Alive2 agrees:
https://alive2.llvm.org/ce/z/NbBaeT (self)
https://alive2.llvm.org/ce/z/iEaig4 (zext)
https://alive2.llvm.org/ce/z/meGb3y (sext)

We already handle `vector_reduce_and(<n x i1>)`,
so let's just combine into the already-handled pattern
and let the existing fold do the rest.

[InstCombine] `vector_reduce_umin(?ext(<n x i1>))` --> `?ext(vector_reduce_and(<n x i1>))` (PR51259)

Alive2 agrees:
https://alive2.llvm.org/ce/z/XxUScW (self)
https://alive2.llvm.org/ce/z/3usTF- (zext)
https://alive2.llvm.org/ce/z/GVxwQz (sext)

We already handle `vector_reduce_and(<n x i1>)`,
so let's just combine into the already-handled pattern
and let the existing fold do the rest.

This aligns the multiple exit costing with all the other cost decisions.  Note that UnrollAndJam, which is the only other caller of the original home of this code, unconditionally bails out of multiple exit loops.

The new -mtargetos= option is a replacement for the existing, OS-specific options
like -miphoneos-version-min=. This allows us to introduce support for new darwin OSes
easier as they won't require the use of a new option. The older options will be
deprecated and the use of the new option will be encouraged instead.

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

Split from D100299.

Reviewed By: jankratochvil

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

This set is only used for contains checks, so there is no need to
use std::set.

Comparing the runtime of the sqrt functions from LLVM libc with the system libc:
|function       |perf - LLVM libc          |perf - MSVCRT
|sqrtf - Windows|44.05 sec (44051715500 ns)| 417.84 sec (417843359900 ns) = 6.96 mins

|function       |perf - LLVM libc          |perf - glibc
|sqrtf - Linux  |30.48 sec (30479458632 ns)|43.72 sec (43716901527 ns)

By running the differential test:
|function       |diff
|sqrtf - Windows|0 differing results
|sqrtf - Linux  |0 differing results

Reviewed By: sivachandra

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

Rather than find + insert. Also use range based for loop.

Reviewed By: mehdi_amini

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

This file uses neither unordered_map nor unordered_set.

It is marked as preserved in NewPM, but not LegacyPM.

In some environments this test could fail if start.S has its own DWARF
CompileUnit or similar are included before the DWARF CompileUnit for the
file.

This change makes the test independent of the index of the compile unit,
instead checking the filename.

Reviewed By: herhut, jankratochvil

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

Alive2 agrees:
https://alive2.llvm.org/ce/z/PDansB (self)
https://alive2.llvm.org/ce/z/55D-Xc (zext)
https://alive2.llvm.org/ce/z/LxG3-r (sext)

We already handle `vector_reduce_and(<n x i1>)`,
so let's just combine into the already-handled pattern
and let the existing fold do the rest.

Agreed on llvm-dev in May 2021

https://bugs.llvm.org/show_bug.cgi?id=50993 was effectively fixed in
https://reviews.llvm.org/D106727. This patch adds a regression
test specifically for the use case reported in 50993.

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

This reverts commit ce1c59de.

The .cpp file uses SIGNAL_POLLING_UNSUPPORTED to guard the call
to sigaction, so use it in the .h file too. (LLVM also calls
sigaction without a guard on non-Windows.)

No behavior change.

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

Another attempt at changing this default, now that tooling has greater
support for DWARF 5.

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

The option to not preserve LCSSA is in fact not tested at all in upstream.  I was tempted to just remove the code entirely, but realized I didn't need to for my actual goal.

Dummy procedures can be defined as subprograms with explicit
interfaces, e.g.

  subroutine subr(dummy)
    interface
      subroutine dummy(x)
        real :: x
      end subroutine
    end interface
    ! ...
  end subroutine

but the symbol table had no means of marking such symbols as dummy
arguments, so predicates like IsDummy(dummy) would fail.  Add an
isDummy_ flag to SubprogramNameDetails, analogous to the corresponding
flag in EntityDetails, and set/test it as needed.

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

When we build with split dwarf in single mode the .o files that contain both "normal" debug sections and dwo sections, along with relocaiton sections for "normal" debug sections.
When we create DWARF context in DWARFObjInMemory we process relocations and store them in the map for .debug_info, etc section.
For DWO Context we also do it for non dwo dwarf sections. Which I believe is not necessary. This leads to a lot of memory being wasted. We observed 70GB extra memory being used.

I went with context sensitive approach, flag is passed in. I am not sure if it's always safe not to process relocations for regular debug sections if Obj contains .dwo sections.
If it is alternatvie might be just to scan, in constructor, sections and if there are .dwo sections not to process regular debug ones.

Reviewed By: dblaikie

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

Add new pass LowerRefTypesIntPtrConv to generate trap
instruction for an inttoptr and ptrtoint of a reference type instead
of erroring, since calling these instructions on non-integral pointers
has been since allowed (see ac81cb7e).

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

This patch updates VPInterleaveRecipe::print to print the actual defined
VPValues for load groups and the store VPValue operands for store
groups.

The IR references may become outdated while transforming the VPlan and
the defined and stored VPValues always are up-to-date.

Reviewed By: Ayal

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

We had a [bad bug](https://github.com/llvm/circt/commit/69655864ee38167016506e9dae2eb1eb43dc3ba5) over in CIRCT
caused by accidentally passing around PatternRewriter
by value.  There is no reason to support copy/assignment
of the pattern rewriter, so disable it.

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

For i1 element type, `xor` and `add` are interchangeable
(https://alive2.llvm.org/ce/z/e77hhQ), so we should treat it just like
an `add` reduction and consistently transform them both:
https://alive2.llvm.org/ce/z/MjCm5W (self)
https://alive2.llvm.org/ce/z/kgqF4M (skipped zext)
https://alive2.llvm.org/ce/z/pgy3HP (skipped sext)

Though, let's emit the IR that is similar to the one we produce for
`vector_reduce_add(<n x i1>)`.

See https://bugs.llvm.org/show_bug.cgi?id=51259

This is mostly intended to be used to find which file contains a miscompile.

Reviewed By: hans

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

This optimizes out the mask when the result of a bitmask is interpreted as an i8
or i16 value. Resolves PR50507.

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

The result expression for the analysis of a Component is not (longer)
valid in the expression traversal framework used by IsSimplyContiguousHelper
now that it has a tri-state result.  Fix so that any result of
analyzing the component symbol is required to be true, not just
present.

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

Currently, OR1K architecture put the program counter at offset 0x128 of
the current `or1k_thread_state_t`. However, the PC is restored after
updating the thread pointer in `r3`, which causes the PC to be fetched
incorrectly.

This patch swaps the order of restoration of `r9` and `r3`, such that
the PC is restored to `r9` using the current thread state.

Patch by Oi Chee Cheung!

Reviewed By: whitequark, compnerd

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

In some cases, when the execution path of the diagnostic
goes back and forth, arrows can overlap and create a mess.
Dimming arrows that are not relevant at the moment, solves this issue.
They are still visible, but don't draw too much attention.

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