Since instrumentation could be used on libraries we need to use fPIC,
not fPIE flag.

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

basic block section cases

MachineBlockPlacement pass sets an alignment attribute to the loop
header MBB and this attribute will lead to an alignment directive during
emitting asm. In the case of the basic block section, the alignment
directive is put before the section label, and thus the alignment is set
to the predecessor of the loop header, which is not what we expect and
increases the code size (both inserting nop and set section alignment).

Reviewed By: rahmanl

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

The following functions are used in the unittest, to access
invalid data detected by the Reader during the debug information
analysis:

- getDebugTags
- getWarningOffsets
- getInvalidLocations
- getInvalidCoverages
- getInvalidRanges
- getLinesZero

Just return a reference to the container with the information.

Reviewed By: dblaikie

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

For a local linkage GlobalObject in a non-prevailing COMDAT, it remains defined while its
leader has been made available_externally. This violates the COMDAT rule that
its members must be retained or discarded as a unit.

To fix this, update the regular LTO change D34803 to track local linkage
GlobalValues, and port the code to ThinLTO (GlobalAliases are not handled.)

This fixes two problems.

(a) `__cxx_global_var_init` in a non-prevailing COMDAT group used to
linger around (unreferenced, hence benign), and is now correctly discarded.
```
int foo();
inline int v = foo();
```

(b) Fix https://github.com/llvm/llvm-project/issues/58215:
as a size optimization, we place private `__profd_` in a COMDAT with a
`__profc_` key. When FuncImport.cpp makes `__profc_` available_externally due to
a non-prevailing COMDAT, `__profd_` incorrectly remains private. This change
makes the `__profd_` available_externally.

```
cat > c.h <<'eof'
extern void bar();
inline __attribute__((noinline)) void foo() {}
eof
cat > m1.cc <<'eof'
#include "c.h"
int main() {
  bar();
  foo();
}
eof
cat > m2.cc <<'eof'
#include "c.h"
__attribute__((noinline)) void bar() {
  foo();
}
eof

clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto -fuse-ld=lld -o t_gen
rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw

clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto=thin -fuse-ld=lld -o t_gen
rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw
```

If a GlobalAlias references a GlobalValue which is just changed to
available_externally, change the GlobalAlias as well (e.g. C5/D5 comdats due to
cc1 -mconstructor-aliases). The GlobalAlias may be referenced by other
available_externally functions, so it cannot easily be removed.

Depends on D137441: we use available_externally to mark a GlobalAlias in a
non-prevailing COMDAT, similar to how we handle GlobalVariable/Function.
GlobalAlias may refer to a ConstantExpr, not changing GlobalAlias to
GlobalVariable gives flexibility for future extensions (the use case is niche.
For simplicity we don't handle it yet). In addition, available_externally
GlobalAlias is the most straightforward implementation and retains the aliasee
information to help optimizers.

See windows-vftable.ll: Windows vftable uses an alias pointing to a
private constant where the alias is the COMDAT leader. The COMDAT use case
is skeptical and ThinLTO does not discard the alias in the non-prevailing COMDAT.
This patch retains the behavior.

See new tests ctor-dtor-alias2.ll: depending on whether the complete object
destructor emitted, when ctor/dtor aliases are used, we may see D0/D2 COMDATs in
one TU and D0/D1/D2 in a D5 COMDAT in another TU.
Allow such a mix-and-match with `if (GO->getComdat()->getName() == GO->getName()) NonPrevailingComdats.insert(GO->getComdat());`

GlobalAlias handling in ThinLTO is still weird, but this patch should hopefully
improve the situation for at least all cases I can think of.

Reviewed By: tejohnson

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

This reverts commit 89016354.

This change broke the following example and we need to check `if (GO->getComdat()->getName() == GO->getName())`
before `NonPrevailingComdats.insert(GO->getComdat());`
Revert for clarify.

```
// a.cc
template <typename T>
struct A final { virtual ~A() {} };
extern "C" void aa() { A<int> a; }
// b.cc
template <typename T>
struct A final { virtual ~A() {} };
template struct A<int>;
extern "C" void bb(A<int> *a) { delete a; }

clang -c -fpic -O0 -flto=thin a.cc && ld.lld -shared a.o b.o
```

This file can't use C99-style comments.

Integer-to-float conversion was handled in constant evaluator with
default rounding mode. This change fixes the behavior and the conversion
is made using rounding mode stored in ImplicitCastExpr node.

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

This patch fixes some of the V_ADD/SUB_U64_PSEUDO not getting converted to their sdwa form.
We still get below patterns in generated code:
v_and_b32_e32 v0, 0xff, v0
v_add_co_u32_e32 v0, vcc, v1, v0
v_addc_co_u32_e64 v1, s[0:1], 0, 0, vcc

and,
v_and_b32_e32 v2, 0xff, v2
v_add_co_u32_e32 v0, vcc, v0, v2
v_addc_co_u32_e32 v1, vcc, 0, v1, vcc

1st and 2nd instructions of both above examples should have been folded into sdwa add with BYTE_0 src operand.

The reason being the pseudo instruction is broken down into VOP3 instruction pair of V_ADD_CO_U32_e64 and V_ADDC_U32_e64.
The sdwa pass attempts lowering them to their VOP2 form before converting them into sdwa instructions. However V_ADDC_U32_e64
cannot be shrunk to it's VOP2 form if it has non-reg src1 operand.
This change attempts to fix that problem by only shrinking V_ADD_CO_U32_e64 instruction.

Reviewed By: arsenm

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

Reviewed By: MaskRay

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

In D135552 the #else is added, which causes build error when
building openmp on LoongArch. This patch fixed the error:
      "Unknown or unsupported architecture"

Reviewed By: SixWeining, MaskRay

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

Add ptrace interceptor support for LoongArch, `ptrace.cpp` has been
tested and passed.

Reviewed By: SixWeining

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

This reverts commit a6f621b8.

We suspect that this patch might be the culprit that is causing
every llvm executable to be sigkill'd immediately on Apple Silicon
machines. Notably, the only other cache file with CMAKE_POSITION_INDEPENDENT_CODE
is Apple's and they have it off.

Building Firefox with -O0 on arm64 mac recently hit the
"FIXME: thunk range overrun" error on multiple occasions.

Doubling or tripling slop was not sufficient in some cases, so
quadruple it.

Reviewed By: #lld-macho, int3

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

Type legalization will want to turn (srl X, Y) into RISCVISD::SRLW,
which will prevent us from using a BEXT instruction.

This is similar to what we do for (i32 (and (srl X, Y), 1)).

This change exposes the sin library function for HLSL,
excluding long, int, and long long doubles.
Sin is supported for all scalar, vector, and matrix types.

Long and long long double support is missing in this patch because those types
don't exist in HLSL. Int is missing because the sin function only works on floating type arguments.

The full documentation of the HLSL sin function is available here:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-sin

Reviewed By: python3kgae

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

Don't emit deprecated v8-style FP compares & branches when targeting v9
processors.

For now, always use %fcc0, because currently the allocator requires allocatable
registers to also be spillable, which isn't the case with v9 FCC registers.

The work to enable allocation over the entire FCC register file will be done in
a future patch.

Fixes bug #17834

Reviewed By: arsenm

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

Do not emit deprecated v8-style branches when targeting a v9 processor.

As a side effect, this also fixes the emission of useless ba's when doing
conditional branches on 64-bit integer values.

Reviewed By: arsenm

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

This is a followup to D138154 and should resolve build issues on Windows.

Reviewed By: aartbik

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

Specifically:
```
*** Bad machine code: MBB has unexpected successors which are not branch targets, fallthrough, EHPads, or inlineasm_br targets. ***
- function:    atomicrmw_umax_i8_acquire
- basic block: %bb.3  (0x1b90bd8)

*** Bad machine code: Non-terminator instruction after the first terminator ***
- function:    atomicrmw_umax_i8_acquire
- basic block: %bb.3  (0x1b90bd8)
- instruction: DBAR 1792
```

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

The member in the specialization is intentionally unused on 32-bit
targets.

When expanding a PseudoCALL, the corresponding flags (e.g. nomerge)
need to be passed to the new instruction.

This patch also adds test for the nomerge attribute.

The `nomerge` attribute was added during `LowerCall`, but was lost
during expand PseudoCALL. Now add it back.

Reviewed By: SixWeining

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

In particular, this silences warnings from [-Wsign-compare].

This is a revised version of D137735, which got reverted due to a sign-comparison warning on LLVM's Windows buildbot (which was not on MLIR's Windows buildbot).  Differences vs the previous differential:

* `vectorToMemref` now uses `detail::checkOverflowCast` to silence the warning that caused the the previous differential to get reverted.
* `MEMREF_GET_USIZE` now uses `detail::checkOverflowCast` rather than `static_cast`
* `ASSERT_USIZE_EQ` added to abbreviate another common idiom, and to ensure that we use `detail::safelyEQ` everywhere (to silence a few other warnings)
* A couple for-loops now use `index_type` for the induction variable, since their upper bound uses that typedef too. (Namely `_mlir_ciface_getSparseTensorReaderDimSizes` and `_mlir_ciface_outSparseTensorWriterNext`)

Depends on D138149

Reviewed By: aartbik

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

A scalar which exceeds 4 bytes should be returned via a stack slot,
on an AVRTiny device.

Reviewed By: aykevl

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

Depends On D138149

Reviewed By: aartbik

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

Different platforms use different signedness for `StridedMemRefType::sizes` and `std::vector::size_type`, and this has been causing a lot of portability issues re [-Wsign-compare] warnings.  These new functions ensure that we need never worry about those signedness warnings ever again.

Also merging CheckedMul.h into ArithmeticUtils.h

Reviewed By: aartbik

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

Removing an unnecessary import, and renaming some macros to match the style used elsewhere.

Reviewed By: aartbik, bixia

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

Reviewed By: aartbik

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

Commit e1b88c8a changed the name of the clang resource directory so that
it was "lib/clang/<MajorVersion>" but missed the place in the LLDB standalone
build where we search for the resource directory.  That was still looking for
<Major>.<Minor>.<Patch>.  The standalone lldb bot has been failing since this
commit.

When a process gets restarted TypeSystem objects associated with it
may get deleted, and any CompilerType objects holding on to a
reference to that type system are a use-after-free in waiting. Because
of the SBAPI, we don't have tight control over where CompilerTypes go
and when they are used. This is particularly a problem in the Swift
plugin, where the scratch TypeSystem can be restarted while the
process is still running. The Swift plugin has a lock to prevent
abuse, but where there's a lock there can be bugs.

This patch changes CompilerType to store a std::weak_ptr<TypeSystem>.
Most of the std::weak_ptr<TypeSystem>* uglyness is hidden by
introducing a wrapper class CompilerType::WrappedTypeSystem that has a
dyn_cast_or_null() method. The only sites that need to know about the
weak pointer implementation detail are the ones that deal with
creating TypeSystems.

rdar://101505232

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

We were crashing trying to convert a GlobalDecl from a
CXXConstructorDecl.  Instead of trying to do that conversion, just pass
down the original GlobalDecl.

I think we could actually compute the correct constructor/destructor
kind from the context, given the way Microsoft mangling works, but it's
simpler to just pass through the correct constructor/destructor kind.

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

This clarifies the intention of code that uses the helper.

Suggested by @Ayal during review of D136068, thanks!

Suggested by @Ayal during review of D136068, thanks!