On Darwin, we do not want to show the BuildId appended at the end of stack
frames in Sanitizers. The BuildId/UUID can be seen by using the
print_module_map=1 sanitizer option.

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

rdar://108324403

This patch adds 'llvm-strings' to Fuchsia clang build.

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

Reviewed By: aartbik

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

This patch skips both `test_completion_target_create_from_root_dir`
introduced in `e8966125` and  `target-label.test` introduced in `1e82b201

`
since I don't have a windows machine to try to accomodate the filesystem
path style differences for these tests to pass.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

This reverts commit fffa05a2.

This seems to cause hwasan tests to run in environments it didn't run in before.

Fix debug printing, making it easier to compare two debug logs side by side:
- `BinaryFunction::addRelocation`: print function name instead of `this` ptr,
- `DataAggregator::doTrace`: remove duplicated function name.

Reviewed By: #bolt, maksfb

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

This fixes a regression introduced by 27f27d15 that results in a
NameError: (name 'self' is not defined) when using crashlog with the -c
option.

rdar://110007391

Don't bother calling ocml. This stops setting the
appropriate fast math flags, and requires this junk
for passing to a private pointer.

Addresses the issue found by:
https://lab.llvm.org/buildbot/#/builders/30/builds/35968

CUDA-12 no longer supports 32-bit compilation.

Tests agnostic to 32/64 compilation mode are switched to use nvptx64.
Tests that do care about it have 32-bit ptxas compilation disabled with cuda-12+.

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

64666d46 incorrectly removed REQUIRES.
2 RUN lines do need x86-registered-target.

Also introduce __builtin_ldexpf16.

AMDGPU has native instructions and target intrinsics for this, but
these really should be subject to legalization and generic
optimizations. This will enable legalization of f16->f32 on targets
without f16 support.

Implement a somewhat horrible inline expansion for targets without
libcall support. This could be better if we could introduce control
flow (GlobalISel version not yet implemented). Support for strictfp
legalization is less complete but works for the simple cases.

This simplifies the usage of `__less` by making the class not depend on the types compared, but instead the `operator()`. We can't remove the template completely because we explicitly instantiate `std::__sort` with `__less<T>`.

Reviewed By: ldionne, #libc

Spies: arichardson, EricWF, libcxx-commits, mgrang

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

-f{constexpr,macro,template}-backtrace-limit=, -fspell-checking-limit=, -ftemplate-depth=

Parametrize SampleProfileInference and SampleProfileLoaderBaseImpl by function
type (Function/MachineFunction) instead of block type
(BasicBlock/MachineBasicBlock). Move out specializations to appropriate
locations.

This change makes it possible to use GraphTraits instead of a custom TypeMap and
make SampleProfileInference not dependent on LLVM types, paving the way for
generalizing SampleProfileInference interfaces to BOLT IR types
(BinaryFunction/BinaryBasicBlock) in stale profile matching (D144500).

Reviewed By: hoy

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

Back in 2020 [1], we went very close to enabling Filesystem on MSVC
by disabling int128_t, but decided to wait because MSVC support
for int128_t was supposed to come shortly after. Since it's not
there yet, I propose turning off int128_t support by default on MSVC.
This will make <filesystem> available by default on MSVC, and most
importantly will open the possibility for changing
LIBCXX_ENABLE_FILESYSTEM to mean "the system doesn't have support
for a filesystem" instead of simply "don't build the std::filesystem
library", which is what I'm really after with this change.

In a way, this is a resurection of D91139.

[1]: https://reviews.llvm.org/D91139#2429595

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

This requires Zbkb.

Reviewed By: reames

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

Instead of guarding header tests using #ifdefs inside the tests,
use Lit markup to mark all the tests as unsupported. This is simpler
but also provides better feedback about which tests are being run
when running the test suite.

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

This avoids checking the size of the sequence repeatedly for each
special case. Especially on RV32 where none of the special cases
apply.

Reviewed By: reames

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

findFile returns null if we've already seen the file, make that clearer.

Reviewed By: mstorsjo

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

This is dead as of: D145341

Reviewed By: nikic

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

There are some new cases if the division is `exact`:
    1: If `TZ(LHS) == TZ(RHS)` then the result is always Odd
    2: If `TZ(LHS) > TZ(RHS)` then the `TZ(LHS)-TZ(RHS)` bits of the
       result are zero.
Proofs: https://alive2.llvm.org/ce/z/3rAZqF

As well, return zero in known poison cases to be consistent rather
than just working about the bits we are changing.

Reviewed By: nikic

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

It seems consistent to always return zero for known poison rather than
varying the value. We do the same elsewhere.

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

Chronically misspelled 'denominator' as 'denuminator' and a few other
cases.

On the logic side, no longer require `RHS` to be strictly positive in
`sdiv`. This in turn means we need to handle a possible zero `denom`
in the APInt division.

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

As pointed out in D149968 vselect predicate patterns could do with a one-use
check to prevent multiple operations being created. This updates the
EitherVSelectOrPassthruPatFrags pattern frags used in creating predicates
min/max.

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

Close https://github.com/llvm/llvm-project/issues/63084

Unlike AArch32, RISC-V defines PT_RISCV_ATTRIBUTES to include the
SHT_RISCV_ATTRIBUTES section. There is no real-world use case yet.

We place PT_RISCV_ATTRIBUTES after PT_GNU_STACK, similar to PT_ARM_EXIDX. GNU ld
places PT_RISCV_ATTRIBUTES earlier, but the placement should not matter.

Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/71

Reviewed By: asb

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

LLDB's logging infrastructure supports prepending log messages with the
name of the file and function that generates the log (see help log
enable). Therefore it's unnecessary to include the current __FUNCTION__
in the log message itself. This patch removes __FUNCTION__ from log
messages in the Host library.

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

The future patch will carry additional info there.

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

This patch implements the enhancement proposed by
https://github.com/llvm/llvm-project/issues/59312.

Suppose we have following code

   v0 = load %addr
   br %LoadBB

LoadBB:
   v1 = load %addr
   ...

PredBB:
   ...
   br %cond, label %LoadBB, label %SuccBB

SuccBB:
   v2 = load %addr
   ...

Instruction v1 in LoadBB is partially redundant, edge (PredBB, LoadBB) is a
critical edge. SuccBB is another successor of PredBB, it contains another load
v2 which is identical to v1. Current GVN splits the critical edge
(PredBB, LoadBB) and inserts a new load in it. A better method is move the load
of v2 into PredBB, then v1 can be changed to a PHI instruction.

If there are two or more similar predecessors, like the test case in the bug
entry, current GVN simply gives up because otherwise it needs to split multiple
critical edges. But we can move all loads in successor blocks into predecessors.

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

In https://reviews.llvm.org/D147812 I introduced the class
`BalancedPartitioning` and it seemed to trigger a warning in flang

```
C:\Users\buildbot-worker\minipc-ryzen-win\flang-x86_64-windows\llvm-project\llvm\include\llvm/Support/BalancedPartitioning.h(89): warning C4305: 'initializing': truncation from 'double' to 'float'
```

For good measure, I converted all double literals to floats. This should
be a NFC.