It is caused by regenerate captured var value when processing the
has_device_addr, the captured var value has been generated in
GenerateOpenMPCapturedVars and passed as Arg in generateInfoForCapture.
The fix just use Arg instead regenerated just same as is_device_ptr

This was trying to add segments beyond the new and use,
so skip additional segments.

This would hit (S < E && "Cannot create empty or backwards segment").

This test is broken due to the flaky encoding of top-level JSON key 'memory'
When I run locally (linux) the test passed. However, it failed the build bot: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/48111/
I will find a way to repro before I can actually fix this issue correctly.

https://reviews.llvm.org/D137455

This allows for bitcast conversion to roundtrip.

Fixes: https://github.com/llvm/llvm-project/issues/58801

Reviewed By: antiagainst, Hardcode84, mravishankar

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

This is for case when native target like X86 is not in LLVM_TARGETS_TO_BUILD.
Right now LLVM_DEFAULT_TARGET_TRIPLE is set to LLVM_HOST_TRIPLE even when native target is not enabled,
As a result, many lit tests will fail because default_triple is set for lit test but not enabled when build LLVM.

Reviewed By: smeenai

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

This reverts commit 7acfe362.
This reverts commit 5f87a892.
This reverts commit 6875ac69.

Some operations need to generate multiple operations when implementing
the tiling interface. Here is a sound example in IREE, see
https://github.com/iree-org/iree/pull/10905 for more details.

Reviewed By: mravishankar

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

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

We should always move jump tables when requested. Previously,
we were not moving jump tables of non-simple functions in relocation
mode. That caused a bug detailed in the attached test case: in PIC
jump tables, we force jump tables to be moved, but if they are not
moved because the function is not simple, we could incorrectly update
original entries in .rodata, corrupting it under special circumstances
(see testcase).

Reviewed By: #bolt, maksfb

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

Fix placement of ifdefs in hugify.cpp after D129107 landed.

same line. Cases such as those in the associated lit tests, can now be
supported.

This adds a 'Count' field to TargetRegionEntryInfo to differentiate
regions with the same source position.

The OffloadEntriesInfoManager routines are updated to maintain a count of
regions seen at a location. The registration of regions proceeds that same as
before, but now the next available count is always determined and used in the
offload entry.

Fixes: https://github.com/llvm/llvm-project/issues/52707

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

The defining Op may live in an unlinked block so its parent Op may be
null. Only assert it when the parent Op is not null.

Reviewed By: mravishankar

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

Reviewed By: antiagainst

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

This truncation can be unexpected and break program behavior.
Dedicated emulation passes should be used instead.

Also rename pass options to "emulate-lt-32-bit-scalar-types".

Fixes: https://github.com/llvm/llvm-project/issues/57917

Reviewed By: antiagainst

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

Additional SCEV verification highlighted a case where the cached loop
dispositions where incorrect after simplifying a phi node in IndVars.
Fix it by invalidating the phi before replacing it.

Fixes #58750

The 32-bit floating-point atomic add instructions on AMDGPUs does not support a
"flat" or "generic" address space. So, if the address space cannot be determined
statically, the AMDGPU backend will fall back to a CAS loop (which does support
"flat" addressing). Instead, this patch emits runtime address-space checks to
allow native FP atomic add instructions for global and LDS memory (and non-atomic
FP add instructions for private/scratch memory).

In order to do that, this patch introduces a new interface function
`emitExpandAtomicRMW`. It is expected to be called when a common atomic expand
doesn't work for a specific target, such as the case we discussed here.

Reviewed By: arsenm

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

Yes, the portable macro is still the only way to do this.

Trivial simplification for CPU2017/503.bwaves resulting in 3.89%
speed-up on icelake.

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

Fixes warning: format specifies type 'unsigned long' but the argument
has type 'lldb::addr_t' (aka 'unsigned long long') [-Wformat]

Added arith::FastMathAttr and ArithFastMathInterface support for Math dialect
floating point operations.

This change-set creates ArithCommon conversion utils that currently
provide classes and methods to aid with arith::FastMathAttr conversion
into LLVM::FastmathFlags. These utils are used in ArithToLLVM and
MathToLLVM convertors, but may eventually be used by other converters
that need to convert fast math attributes.

Since Math dialect operations use arith::FastMathAttr, MathOps.td now
has to include enum and attributes definitions from Arith dialect.
To minimize the amount of TD code included from Arith dialect,
I moved FastMathAttr definition into ArithBase.td.

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

Only add the option processing and store the result. No attributes are
added to FIR yet.

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

Only add the option processing and store the result. No attributes are
added to FIR yet.

Clang only forwards -mreassociate
if (AssociativeMath && !SignedZeros && !TrappingMath)

Flang doesn't have -f[no-]trapping-math, so this part of the condition
has been omitted. !TrappingMath is the default.

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

Only add the option processing and store the result. No attributes are
added to FIR yet.

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

Only add the option processing and store the result. No attributes are
added to FIR yet.

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

Only add the option processing and store the result. No attributes are
added to FIR yet.

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

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

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

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

Now we state that backward compatibility is not guaranteed in the document.

Reviewed By: JonChesterfield, dreachem

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

The neutral element got minf/maxf should be respectively +inf and -inf.

Bug reported by @Hardcode84.

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

Update https://reviews.llvm.org/rGc14df228ff3c to check the host versus
the target thereby allowing XFAIL to be used in case the issue is
resolved in the future.

This adds a `PassManager.add` method which adds pipeline elements to the
pass manager. This allows for progressively building up a pipeline from
python without string manipulation.

Reviewed By: mehdi_amini

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

This removes a lot of boilerplate.

Reviewed By: ldionne, #libc, EricWF

Spies: EricWF, libcxx-commits

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

Compound statements can appear in default arguments
but should not be visited in ImmediateCallVisitor as they are
not subexpressions

For a min and max reduction idioms, the identity (i.e. neutral) element
should be datatype's highest and lowest possible values respectively.
Current implementation in IVDescriptors incorrectly returns -Inf for FMin
reduction and +Inf for FMax reduction. This patch fixes this bug which
was causing incorrect reduction computation results in loops vectorized
by LV.

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

These checks can be re-used with other potential transforms
such as a load of a subvector-insert.