These functions were local to SemaDeclAttr.cpp, but these functions are
useful in general (for instance, for statement or type attribute
processing). This refactoring is in advance of beginning to tablegen
diagnostic checks for statement attributes the way we already do for
declaration attributes.

There is one functional change in here as a drive-by. The
external_source_symbol attribute had one of its diagnostic checks
inside of an assert, which was corrected.

LSR prefers to schedule iv increments just before the latch.  The recent 80511565 broadened this to moving increments in the original IR.  This pointed out a robustness problem with the CGP transform.

When we have a use of an induction increment outside of the loop (we canonicalize away from this form, but it happens e.g. unanalyzeable loops) we'd avoid performing the uadd/usub transform.  Interestingly, all of these involve moving the increment closer to it's operands, so there's no concern about dominating all uses.  We can handle that case cheaply, resulting in a more robust transform.

This allows the caller to distinguish between a parse error or an
unmatched keyword. It fixes the redundant error that was emitted by the
caller when the generated parser would fail.

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

Instead of storing an array of LoopOpt attributes, which were just
wrapping std::pair<enum, int> anyway, we can have an attribute storing
a sorted ArrayRef<std::pair<enum, int>> as a single unit. This improves
here the textual format and the general API. Note that we're limiting
the options to fit into an int64_t by design, but this isn't a new
constraint.

Building the LoopOptions attribute is likely worth a specific builder
for efficient reason, that'll be the subject of a future patch.

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

There is no centralized store of information related to secondary
allocations. Moreover the allocations themselves become inaccessible
when the allocation is freed in order to implement UAF detection,
so we can't store information there to be used in case of UAF
anyway.

Therefore our storage location for tracking stack traces of secondary
allocations is a ring buffer. The ring buffer is copied to the process
creating the crash dump when a fault occurs.

The ring buffer is also used to store stack traces for primary
deallocations. Stack traces for primary allocations continue to be
stored inline.

In order to support the scenario where an access to the ring buffer
is interrupted by a concurrently occurring crash, the ring buffer is
accessed in a lock-free manner.

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

For <2 x s32>, we can use G_DUPLANE32, but with a <4 x s32> source. To make it
work, we can just widen the original source with a concat_vectors.

Doing this allows <2 x float> indexed fmul instruction selection patterns to
fire, which gives a nice 0.3% code size saving on Bullet with -Os.

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

If every element is extracted from a G_BUILD_VECTOR, pass through the source
registers. This is different to the extract(build_vector) combine because this
one tolerates multiple users as long as they're exhaustive.

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

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

Refactor and add comments to explain where the magic numbers come from
in terms of the instruction cache line size. NFC.

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

This patch implements DBG_VALUE_LIST handling to the LiveDebugValues pass. This
is a substantial change, and makes a few fundamental changes to the existing
logic.

We still use the basic model of a VarLocMap that is indexed by a LocIndex, with
a VarLocSet (a CoalescingBitVector underneath) giving us efficient lookups of
existing variable locations for a given location type. The main change is that
the VarLocMap may contain a given VarLoc multiple times (once for each unique
location operand), so that a VarLoc can be looked up from any of the registers
that it uses. This means that each VarLoc has multiple corresponding LocIndexes;
to allow us to iterate through the set of VarLocs (previously we would iterate
through the VarLocSet), we now also maintain a single entry in the VarLocMap
that contains every VarLoc exactly once.

The VarLoc class itself is also changed; this change is much simpler,
refactoring out location-specific members into a MachineLocation class and
adding a vector of these locations.

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

After 5419b671 (which is `[SimplifyCFG] Update FoldTwoEntryPHINode to handle and/or of select and binop equally`), this uninitialized value is detected by msan.

This test currently fails to compile when using a MinGW toolchain as setenv is not defined. This function is a POSIX function Windows does not implement.

This patch enables the setenv macro used in the unit test for all of Windows, making the test compile and run successfully.

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

In -fno-exceptions -fno-asynchronous-unwind-tables -g0 mode,
GCC does not emit `.cfi_*` directives.

```
% diff <(gcc -fno-asynchronous-unwind-tables -dM -E a.c) <(gcc -dM -E a.c)
130a131
> #define __GCC_HAVE_DWARF2_CFI_ASM 1
```

This macro is useful because code can decide whether inline asm should include `.cfi_*` directives.
`.cfi_*` directives without `.cfi_startproc` can cause assembler errors
(integrated assembler: `this directive must appear between .cfi_startproc and .cfi_endproc directives`).

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

Update the crashlog script for changes to the JSON schema.

rdar://75122914

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

This variable is used to reducing the likelihood of hitting module cache
issues in CI where different branches can potentially run on the same
machine.

Use lit's with_system_environment function to propagate environment
variables to the tests. Include the usual suspects, as well as the
variables already explicitly forwarded.

llvm-jitlink and llvm-jitlink-executor make use of APIs that are
part of the socket and nsl libraries on SunOS systems (Solaris and
Illumos). Make sure they get linked.

Ran into this in Rust CI when cross-compiling LLVM 12 to these
targets.

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

LLVM is recommending to use SmallVector (that is, omitting the N), in the
absence of a well-motivated choice for the number of inlined elements N.

However, this doesn't work well with XL compiler on AIX since some header(s)
aren't properly picked up with it. We need to take a further look into the real
issue underneath and fix it in a later patch.

But currently we'd like to use this patch to unblock the build compiler issue
first.

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

I've left mask registers to a future patch as we'll need
to convert them to full vectors, shuffle, and then truncate.

Reviewed By: frasercrmck

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

GNU ld does not give SHF_GNU_RETAIN GC root semantics for ELFOSABI_NONE.
(https://sourceware.org/pipermail/binutils/2021-March/115581.html)

This allows GNU ld to interpret SHF_GNU_RETAIN and avoids a gold quirk
https://sourceware.org/bugzilla/show_bug.cgi?id=27490

Because ELFObjectWriter is in an anonymous namespace, I have to place
`markGnuAbi` in the parent MCObjectWriter.

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

AMDGPU target tries to handle the SGPR and VGPR spills in a
custom pass before the actual frame lowering pass. Once they
are handled and the respective frames are eliminated in the
custom pass, certain uses of them still remain. For instance,
the DBG_VALUE instructions inserted by the allocator alongside
the spill instruction will use the corresponding frame index.
They become dead later during PEI and causes a crash while trying to
replace the frame indices. We should possibly avoid this custom pass.
For now, replacing such dead references with null register value.

Reviewed By: arsenm, scott.linder

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

All extractvalues of the same value at the same index will map to
the same register, so even if one specific extractvalue only has
one use, we should not mark it as a trivial kill, as there may be
more extractvalues later.

Fixes https://bugs.llvm.org/show_bug.cgi?id=49467.

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

The LiveDebugValues and LiveDebugVariables implementations for handling
DBG_VALUE_LIST instructions can be simplified significantly if they do not have
to deal with any duplicated operands, such as a DBG_VALUE_LIST that uses the
same register multiple times in its expression. This patch adds a function,
replaceArg, that can be used to simplify a DIExpression in the case of
duplicated operands.

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

I've included tests that require type legalization to split the
vector. The i64 version of these scalarizes on RV32 due to type
legalization visiting the result before the vector type. So we
have to abort our custom expansion to avoid creating target
specific nodes with an illegal type. Then type legalization ends
up scalarizing. We might be able to fix this by doing custom
splitting for large vectors in our handler to get down to a legal
type.

Reviewed By: frasercrmck

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

This reverts commit f1b69059.

[clang] unbreak Index/preamble-reparse-changed-module.m with LLVM_APPEND_VC_REV=NO after 46d4d1fe

See discussion starting at https://reviews.llvm.org/D96816#2572431 .
The same thing is happening with 46d4d1fe.

[RISCV] Don't modify the SEW immediate on the V extension pseudo instructions after inserting VSETVLI.

Previously we set the value to -1, but the SEW information could
be useful for scheduling.

Reviewed By: frasercrmck, rogfer01

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

The default fixed vector expansion uses sra+xor+add since it can't
see that smax is legal due to our custom handling. So we select
smax(X, sub(0, X)) manually.

Scalable vectors are able to use the smax expansion automatically
for most cases. It crashes in one case because getConstant can't build a
SPLAT_VECTOR for nxvXi64 when i64 scalars aren't legal. So
we manually emit a SPLAT_VECTOR_I64 for that case.

Reviewed By: frasercrmck

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

[RISCV] Make the hasStdExtM() check in RISCVInstrInfo::getVLENFactoredAmount emit a diagnostic rather than an assert.

As far as I know we're not enforcing the StdExtM must be enabled
to use the V extension. If we use an assert here and hit this
code in a release build we'll silently emit an invalid instruction.

By using a diagnostic we report the error to the user in release
builds. I think there may still be a later fatal error from
the code emitter though.

Reviewed By: frasercrmck

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

This patch updates the various IR passes to correctly handle dbg.values with a
DIArgList location. This patch does not actually allow DIArgLists to be produced
by salvageDebugInfo, and it does not affect any pass after codegen-prepare.
Other than that, it should cover every IR pass.

Most of the changes simply extend code that operated on a single debug value to
operate on the list of debug values in the style of any_of, all_of, for_each,
etc. Instances of setOperand(0, ...) have been replaced with with
replaceVariableLocationOp, which takes the value that is being replaced as an
additional argument. In places where this value isn't readily available, we have
to track the old value through to the point where it gets replaced.

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

This is another step towards parity between existing select
transforms and min/max intrinsics (D98152)..

The existing 'not' folds around select are complicated, so
it's likely that we will need to enhance this, but this
should be a safe step.

We used to trigger assertion when transforming c-tor with unparsed
default argument. Now we ignore such constructors for this purpose.

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

In case a char-literal of type int (C/ObjectiveC) corresponds to a
format specifier with the %hh length modifier, don't treat the literal
as of type char for issuing diagnostics, as otherwise this results in:

printf("%hhd", 'e');
warning: format specifies type 'char' but the argument has type 'char'.

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

SUMMARY:

n the patch https://reviews.llvm.org/D87451 "add new option -mignore-xcoff-visibility"
we did as "The option -mignore-xcoff-visibility has no effect on visibility attribute when compile with -emit-llvm option to generated LLVM IR."

in these patch we let -mignore-xcoff-visibility effect on generating IR too. the new feature only work on AIX OS

Reviewer: Jason Liu,

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

For clang this change is NFC cleanup, because clang
never calls atomic functions from runtime library.

Basically, pause is good in spin-loops waiting for something.
Atomic CAS loops do not wait for anything,
each CAS failure means some other thread progressed.

Performance experiments show that the pause only causes unnecessary slowdown
on CPUs with slow pause instruction, no difference on CPUs with fast pause
instruction, removal of the pause gives lesser binary size which is good.

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

This patch refactors include-module.f90:
  * rename the test file as use-module.f90 to better highlight which
  driver feature is being tested
  * move tests for diagnostics to use-module-error.f90 (it tests that
  `-J/-module-dir` can only be used once)
  * make sure that `f18` is tested when `FLANG_BUILD_NEW_DRIVER` is
  set to `Off`
  * add tests for when all module files are successfully discovered and
  loaded

With this patch, there should be a clear separation into 3 scenarios in
use-module.f90:
  * Everything is OK
  * One module file wasn't found (missing include path for
  basictestingmoduletwo.mod)
  * Two module files are found, but the test requires
  `basictestingmoduleone.mod` from both `Inputs` and `Inputs/module-dir`.
  Only the latter is found.

Reviewed By: tskeith

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