so that they get an error on non-x86 targets.
Follow-up to D151590.

As a workaround for https://github.com/llvm/llvm-project/issues/63270, we don't
report an error for -msse4.2.

ARM stores the Thumb state in the least significant bit of the
function pointers. When compiling for ARM or Thumb, as all
instructions are at least 16-bit aligned, ignore the LSB when
computing the prefix hash location, so we can support both
pure Thumb and mixed ARM/Thumb binaries.

Fixes #62936

Reviewed By: MaskRay, simon_tatham

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

so that they get an error on other targets. This change uses let statements to
apply `Flags = [TargetSpecific]` to options (mostly -m*) without specifying `Flags`.
Follow-up to D151590.

For some options, e.g. -mdefault-build-attributes (D31813), -mbranch-likely
(D38168), -mfpu=/-mabi= (6890b9b7), a warning
seems desired in at least certain cases. This is not the best practice, but this
change works around them by not applying `Flags = [TargetSpecific]`.

Some m_x86_Features_Group options are popular. We make them TargetSpecific in a
future patch.

(
For Intel CPU errata -malign-branch= family options, we also drop the unneeded
NotXarchOption flag (was confuslingly named DriverOption). This flag reports an
error if the option is used with -Xarch_*. This error reporting does not seem
correct/useful.
)

Implements parts of P1614R2. Removed `operator!=` from:
- `weekday`
- `weekday_indexed`
- `weekday_last`
- `month_weekday`
- `month_weekday_last`
- `year_month_weekday`
- `year_month_weekday_last`

Note these operators were added and removed in C++20.

Reviewed By: #libc, Mordante

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

This patch fixes:

  llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:3214:12: error: unused
  variable 'TSFlags' [-Werror,-Wunused-variable]

This isn't needed after D152050.

Reviewed By: reames

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

This was used to know if we need to insert a dummy operand during
MCInstLowering. We can use the operand info from MCInstrDesc to
figure this out without needing a separate flag.

I'll remove the tablegen bits if there is consensus this is a good
idea.

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

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

`ctpop(X) eq/ne 1` is checking if X is a non-zero power of 2. Power of
2 check including zero is `(X & (X-1)) eq/ne 0` and unfortunately
there is no good pattern for checking a power of 2 while excluding
zero. So, when lowering `ctpop(X) eq/ne 1`, explicitly check
`IsKnownNeverZero(X)` to maybe be able to optimize out the extra zero
check.

We need this explicitly as DAGCombiner does not re-analyze provable
setcc nodes, and the middle-end never finds it beneficially to broaden
`ctpop(X) eq/ne 1` -> `ctpop(X) ule/ugt 1` (power of 2 including
zero).

Reviewed By: RKSimon

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

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

D106948 and commit 9c31e126 removed the last
user, respectively.

This patch allows the client of a `WatchedLiteralsSolver` to specify a
computation limit on the use of the solver. After the limit is exhausted, the
SAT solver times out.

Fixes issues #60265.

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

Follow up to 133c3eaa

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

Reviewers: mevler

Reviewed-By: mevler

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

Consider the following pattern `binOp (select cond, x, c0), c1`.
Where `c0` and `c1` are constants.
We can transform it to `select cond, binOp(x, c1), binOp(c0, c1)`.

If `binOp(c0, c1)` ends up being `0` or `-1` we can turn the select into
a more profitable sequence.

This document is based on the RFC posted to discourse:
https://discourse.llvm.org/t/rfc-defining-undefined-behavior-in-libc/

Reviewed By: sivachandra, lntue

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

This patch adds the reentrent qsort entrypoint, qsort_r. This is done by
extending the qsort functionality and moving it to a shared utility
header. For this reason the qsort_r tests focus mostly on the places
where it differs from qsort, since they share the same sorting code.

Reviewed By: sivachandra, lntue

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

Breaks all sanitizers bootstrap bots:
https://lab.llvm.org/buildbot/#/waterfall?tags=sanitizer

This reverts commit cf79773a.

This patch adds parser support for the force modifier on the collapse clause
introduced in OpenACC 3.3.
Lowering will currently hit a TODO as the MLIR representation of the acc.loop
might need some update.

Reviewed By: kiranchandramohan

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

Match like [[#T2]] does not include leading zeroes.

In lite mode (default for X86), BOLT optimizes and relocates functions
with profile. The rest of the code is preserved, but if it references
relocated code such references have to be updated. The update is handled
by scanExternalRefs() function. Note that we cannot solely rely on
relocations written by the linker, as not all code references are
exposed to the linker. Additionally, the linker can modify certain
instructions and relocations will no longer match the code.

With this change, start using symbolic disassembler for scanning code
for references in scanExternalRefs(). Unlike the previous approach, the
symbolizer properly detects and creates references for instructions with
multiple/ambiguous symbolic operands and handles cases where a
relocation doesn't match any operand. See test cases for examples.

Reviewed By: Amir

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

NextOnly tells getNextRef to only check the next node in the chain, and
stop iterating. The loop didn't stop though when the next link pointed
back to the beginning of the circular list.

Recommit this one right now, because it fixes a latent bug.

Currently the expression parser prints a mostly useless generic error before printing the compiler error:

  (lldb) p 1+x)
  error: expression failed to parse:
  error: <user expression 18>:1:3: use of undeclared identifier 'x'
  1+x)
     ^

This is distracting and as far as I can tell only exists to work
around the fact that the first "error: " is unconditionally injected
by CommandReturnObject. The solution is not very elegant, but the
result looks much better.

(Partially addresses rdar://110492710)

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

No idea what I was thinking when I suggested vadd.vi.

Reviewed By: reames, frasercrmck, fakepaper56

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

Windows and Unix use different epochs: 1970-01-01 00:00:00.000000000 and
1969-12-31 16:00:00.000000000 respectively.

This patch fixes a minor issue in AMDGPUToROCDL to add gfx11 support in MLIR

Reviewed By: krzysz00

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

vslideup has a vector overlap constraint that vmv.v.v doesn't.
vmv.v.v is also a simpler instruction so may have better
throughput and/or latency in some CPUs.

This is an alternative to D152298, D152368, and D152496.

Reviewed By: luke, reames

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

Static archives can contain multiple files with the same file name, in
which case the timestamp is used to disambiguate. Because timestamps are
expressed in seconds since epoch timestamp collisions are far from
impossible. Furthermore, to facilitate reproducible builds, the static
linker can be told to emit no timestamps at all.

dsymutil already detects timestamp mismatches between the debug map and
the object files. However, it does not handle timestamp collisions
within the debug maps (STABS). Currently, we arbitrarily pick the first
debug map entry and ignore the rest. This is incorrect: if a symbol
exists in multiple object files, the linker might not have picked the
one from the first object file. This also results in missing symbol
warnings for all the symbols not defined in the first object file.

Given that in this scenario, dsymutil does not have enough information
to disambiguate, it should print a single informative warning and skip
the ambiguous debug map objects.

rdar://110374836

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

The current argument types are currently switched around for ftruncate
and truncate. Currently passes tests because the internal definitions
inside the __llvm_libc namespace are fine.

Reviewed By: michaelrj, thesamesam, sivachandra

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

This is an extension and only adds the functions that are a considered a
but when called and ignoring the result.

Drive-by sort all nodiscard extensions in the documentation.

Reviewed By: #libc, philnik

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

Reviewed By: #bolt, maksfb

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

Implemented parts of P1614R2:
- Added `operator==` to `file_status`

Reviewed By: #libc, Mordante

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

Addresses post-commit feedback from D152236.

Reviewed By: asb, dtcxzyw

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

Implements parts of P1614R2
- Removed `operator!=` from `scoped_allocator_adaptor`

Reviewed By: #libc, Mordante

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

Implements parts of P1614R2:
- Removed `operator!=` from `functional`

Reviewed By: #libc, Mordante

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

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544

Currently, `retainedNodes` tracks function-local variables and labels.
To support function-local import, types and static variables (which are globals
in LLVM IR), subsequent patches use the same field. So this patch makes
preliminary refactoring of the code tracking local entities to apply future
functional changes lucidly and cleanly.

No functional changes intended.

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



Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

The separation here doesn't make much sense. I think it's a
leftover from the creation of the MC layer that has been
replicated to new targets.

By merging them we can avoid passing the AsmPrinter to the
MCInstLowering functions. We can make them member functions instead.

I think we can still do more integration of lowerSymbolOperand
and lowerRISCVVMachineInstrToMCInst, but I wanted to get feedback
on the direction first.

Reviewed By: asb, barannikov88

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

We recently fixed a bug in "sparsifying" such reductions, since
it incorrectly changed this into reductions over stored elements
only , which only works for add/sub/or/xor. However, we still want
to be able to "sparsify" the reductions even in the general case,
and this is a first step by rewriting them into a custom reduction
that feeds in the implicit zeros. NOTE HOWEVER, that in the long run
we want to do this better and feed in any implicit zero only ONCE
for efficiency.

Reviewed By: Peiming

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