This reverts commit befa8cf0.

Apparently this breaks some libc++ builds with an apparent assertion,
 so I'm looking into that .

getPointerAlignment and ConstantPoolSDNode::getAlign only consider
the alignment of the object. If we already have a non-zero offset
into the offset that may have reduced the alignment.

Since the base pointer will become an LUI with the old offset, we
need to be sure the new offset fits in the alignment of the address
that will be used to create the LUI immediate.

I'm not sure it is possible to have a non-zero offset in the
GlobalAddressSDNode or ConstantPoolSDNode at this point today so this
may only be a theoretical bug.

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

This fixes test/DebugInfo/Generic/accel-table-hash-collisions.ll and
cross-cu-inlining.ll when the default triple is riscv. llvm-dwarfdump
--apple-names does not resolve R_RISCV_{ADD,SUB}32 in .apple_names .apple_types
and having ADD/SUB will cause decoding failure `Atom[0]: Error extracting the
value`.

isAssumeLikeIntrinsic() is a superset of isLifetimeStartOrEnd().

Reviewed By: aartbik, wrengr

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

Add DXIL operation for thread/group id operations.

ID  Name	                     Description
93  ThreadId	                 reads the thread ID
94  GroupId	                  reads the group ID (SV_GroupID)
95  ThreadIdInGroup	          reads the thread ID within the group (SV_GroupThreadID)
96  FlattenedThreadIdInGroup	 provides a flattened index for a given thread within a given group (SV_GroupIndex)

Also add llvm intrinsic which map to these intrinsics to DXIL operation.

Reviewed By: beanz

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

This updates the status for another 8 DRs.

Fuchsia has split overloaded nanosleep(0) for yielding to its own
dedicated syscall, so valid zero deadlines would just return.

Patch By: gevalentino

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

Before merging two instructions together, GISel does some sanity checks
that the folding is legal. However that check was missing that the
source of the pattern may be convergent. When the destination location
is in a different basic block, the folding is invalid.

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

Fuchsia already uses libunwind, but it does so implicitly via libc++.
This change makes the unwinder choice explicit.

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

Precommit tests exercising the future folding of memchr and strchr calls
in equality expressions with the first function argument.

Add an emitter for the memrchr common extension and simplify the strrchr
call handler to use it. This enables transforming calls with the empty
string to the test C ? S : 0.

Reviewed By: nikic

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

This review is extracted from D96035.

This patch adds possibility to keep not only DwarfStringPoolEntry, but also
pointer to it. The DwarfStringPoolEntryRef keeps reference to the string map entry.
String map keeps string data and corresponding DwarfStringPoolEntry
info. Not all string map entries may be included into the result,
and then not all string entries should have DwarfStringPoolEntry
info. Currently StringMap keeps DwarfStringPoolEntry for all entries.
It leads to extra memory usage. This patch allows to keep
DwarfStringPoolEntry info only for entries which really need it.

[reland] : make msan happy.

Reviewed By: JDevlieghere

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

There exists some description of the flag from Microsoft, but not sure if
there's more to it. We ignore the flag for now until we find out more about it.

https://docs.microsoft.com/en-us/cpp/build/reference/kernel-create-kernel-mode-binary?view=msvc-170

Reviewed By: thieta, hans

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

This also changes the space of the returned lexmin for IntegerPolyhedrons;
the symbols in the poly now correspond to symbols in the result rather than dims.

Reviewed By: Groverkss

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

[MLIR][Presburger] Simplex: refactor (symbolic)lex to support specifying multiple varKinds as symbols

This is also required to support lexmin for relations.

Reviewed By: Groverkss

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

Previous implementation splits value ranges around threads. Because of
very different performance of testing functions over different ranges,
CPU utilization were poor. Current implementation split test range
over small pieces and threads take the pieces when they finish with
previous. Therefore the CPU load is constant during testing.

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

ET_EXEC and ET_DYN files may contain non-SHF_ALLOC relocation sections
(e.g. ld --emit-relocs). Match GNU objdump by dumping them.

* Remove Object/dynamic-reloc.test. Replace it with a -r RUN line in dynamic-relocs.test
* Update relocations-in-nonreloc.test to set sh_link/sh_info. GNU
  objdump seems to ignore a SHT_REL/SHT_RELA section not linking to SHT_SYMTAB.
  The test did not test what it intended to test.

Fix https://github.com/llvm/llvm-project/issues/41246

Reviewed By: jhenderson

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

This patch gives basic parsing and semantic support for
"parallel masked taskloop simd" construct introduced in
OpenMP 5.1 (section 2.16.10)

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

This reverts commit 2750985a.
This has caused Windows buildbot unhappy :(

This adds a missing test for 0ecbedc0


Signed-off-by: Jun Zhang <jun@junz.org>

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

Reviewed By: nicolasvasilache

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

One motivation to add support for these types are the LD1Q/ST1Q
instructions in SME, for which we have defined a number of load/store
intrinsics which at the moment still take a `<vscale x 16 x i1>` predicate
regardless of their element type.

This patch adds basic support for the nxv1i1 type such that it can be passed/returned
from functions, as well as some basic support to support some existing tests that
result in a nxv1i1 type. It also adds support for splats.

Other operations (e.g. insert/extract subvector, logical ops, etc) will be
supported in follow-up patches.

Reviewed By: paulwalker-arm, efriedma

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

This function is well-defined for an instruction that doesn't access
memory (and thus trivially doesn't alias anything in the AST), so
drop the assert. We can end up with a readnone call here if we
originally created a MemoryDef for an indirect call, which was
later replaced with a direct readnone call.

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

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

Better fix to be added by Haojian later!

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

Nowadays, we do not allow pointers in multiplies, and adds can only
have a single pointer, which is also guaranteed to be last by
complexity sorting. As such, we can somewhat simplify the treatment
of pointer types.

LoopSimplify only requires that the loop predecessor has a single
successor and is safe to hoist into -- it doesn't necessarily have
to be an unconditional BranchInst.

Adjust LoopDeletion to assert conditions closer to what it actually
needs for correctness, namely a single successor and a
side-effect-free terminator (as the terminator is getting dropped).

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

D124637 improved filtering of method expressions, but not method
definitions. With this change, clangd will now filter ObjC method
definition completions based on their entire selector instead of
only the first selector fragment.

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

This reverts commit d4d47e57.

This fixes the lldb crash that was observed by ensuring that our
friend-'template contains reference to' TreeTransform properly handles a
TemplateDecl.

Signed one bit values can only be -1 or 0, not positive. The code
was interpreting the 1 as -1 and intersecting with a full range
rather than an empty one.

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

As described in aapcs64 (https://github.com/ARM-software/abi-aa/blob/2022Q1/aapcs64/aapcs64.rst#scalable-vector-registers)
AAVPCS is used only when registers z0-z7 take an SVE argument. This fixes the case where floats occupy the lower bits
of registers z0-z7 but SVE arguments in registers greater than z7 cause a function to use AAVPCS where it should use AAPCS.

Moving SVE function deduction from AArch64RegisterInfo::hasSVEArgsOrReturn to AArch64TargetLowering::LowerFormalArguments
where physical register lowering is more accurate fixes this.

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

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

The CGProfilePass needs to be run during FullLTO compilation at link
time to emit the .llvm.call-graph-profile section to the compiled LTO
object file. Currently, it is being run only during the initial
LTO-prelink compilation stage (to produce the bitcode files to be
consumed by the linker) and so the section is not produced.

ThinLTO is not affected because:
- For ThinLTO-prelink compilation the CGProfilePass pass is not run
  because ThinLTO-prelink passes are added via
  buildThinLTOPreLinkDefaultPipeline. Normal and FullLTO-prelink
  passes are both added via buildPerModuleDefaultPipeline which uses
  the LTOPreLink parameter to customize its behavior for the
  FullLTO-prelink pass differences.
- ThinLTO backend compilation phase adds the CGProfilePass (see:
  buildModuleOptimizationPipeline).

Adjust when the pass is run so that the .llvm.call-graph-profile
section is produced correctly for FullLTO.

Fixes #56185 (https://github.com/llvm/llvm-project/issues/56185)

Remove the CreateNeg() method from IRBuilderFolder and base it on
CreateSub(0, V) instead, which will call FoldNoWrapBinaryOp().

May not be NFC if InstSimplifyFolder is used.

Drop the IRBuilderFolder method entirely and base this on
CreateXor(V, -1) instead, so this will now go through FoldBinOp.

May not be NFC if the InstSimplifyBuilder is used.

At the moment, the same VPlan can be used code generation of both the
main vector and epilogue vector loop. This can lead to wrong results, if
the plan is optimized based on the VF of the main vector loop and then
re-used for the epilogue loop.

One example where this is problematic is if the scalar loops need to
execute at least one iteration, e.g. due to interleave groups.

To prevent mis-compiles in the short-term, disable optimizing exit
conditions for VPlans when using epilogue vectorization. The proper fix
is to avoid re-using the same plan for both loops, which will require
support for cloning plans first.

Fixes #56319.