When FakeStack GC from altstack, it may see default stack on lower
addressed and incorectly disard all frames.

Fixes bug exposed by D153536.

Reviewed By: kstoimenov

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

It is surprising for the user that only some fields were honored.

Also make the FrozenRewritePatternSet a shared_ptr<const T>.

Fixes #64543

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

This reverts commit 9ef6cffb.

This was an attempt to fix the bot for a commit I reverted since.
It isn't necessary anymore.

In llvm alias analysis is off by default now.
This patch enable alias analysis on RISCV target during code generation by default,
and this makes more chances for improving performance.
Modified related test cases.

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

This renaming started with the native ODS support for properties, this is completing it.

A mass automated textual rename seems safe for most codebases.
Drop also the ods prefix to keep the accessors the same as they were before
this change:
 properties.odsOperandSegmentSizes
reverts back to:
 properties.operandSegementSizes

The ODS prefix was creating divergence between all the places and make it harder to
be consistent.

Reviewed By: jpienaar

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

This reverts commit 490dae26.

Bot is broken, seems like there is a problem of ambiguity in the parser.

This reverts commit 4434bc55.

It does not make sense to introduce more passes to fix a parsing issue.
More importantly: it didn't fix the test!

 commit c1803d53 (HEAD -> main, origin/main, origin/HEAD)
Author: Changpeng Fang <changpeng.fang@amd.com>
Date:   Wed Aug 9 17:49:14 2023 -0700

    [FunctionAttrs] Unconditionally perform argument attribute inference in the first function-attrs pass

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

The details in the radar don't seem all that relevant.

Broke some bots

This reverts commit 2b5b2bfe.

[FunctionAttrs] Unconditionally perform argument attribute inference in the first function-attrs pass

Summary:
  Argument attributes like NoAlias and ReadOnly could affect memoryssa and thus earlyCSE in the function simplification pipeline.
https://reviews.llvm.org/D145210 adjusted PostOrderFunctionAttrs placement and caused the argument attributes not referred for the use
in the pipeline. This work (initiated by @nikic) unconditionally performs argument attribute inference in the first function-attrs pass.

Reviewers:
  aeubanks and nikic

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

User errors should use reportError. reportError allows us to continue parsing
the file and collect more diagnostics.

MC/ELF/leb128-err.s is adapted from MC/RISCV/riscv64-64b-pcrel.s

Some GPU backends (SPIR-V) lower memrefs to bare pointers, so for dynamically sized/strided memrefs it will fail.
This pass extracts sizes and strides via `memref.extract_strrided_metadata` outside `gpu.launch` body and do index/offset calculation explicitly and then reconstructs memrefs via `memref.reinterpret_cast`.

`memref.reinterpret_cast` then lowered via https://reviews.llvm.org/D155011

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

The surrounding comment has more than enough context to describe the problem.

StreamFile subclasses Stream (from lldbUtility) and is backed by a File
(from lldbHost). It does not depend on anything from lldbCore or any of its
sibling libraries, so I think it makes sense for this to live in
lldbHost instead.

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

lldbUtility seems like a more suitable place for StreamBuffer.

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

Coroutine co_yield/co_await/co_return are implemented by a serious of
synthesized CXXMemberExpr which have no lexical right-side parenthesis.

This fix uses the end loc of inner expr as the hypothetical RParenLoc of
CXXMemberExpr. For tools this might be an issue since the RParen token doesn't
exist (but has a valid location).

For future improvement, we might:
1. mark those inner (generated) exprs as implict (tools have chances to skip
   these nodes) (by @aaron.ballman)
2. borrow the idea from InitListExpr, there are two forms, one is for semantic,
   the other one is for syntactic, having these two split can make everything
   easier (by @hokein)

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

Reviewed By: aaron.ballman, hokein

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

Avoid both memory leaks and expensive dynamic allocations by using
SpecificBumpPtrAllocator for HNode types. It's expected they're not deallocated
until the `Input` class is destroyed, so deallocating all at once works well in
this case.

Reduces YAML profile pre-processing time in BOLT from
>   11.2067 (  3.2%)   1.6487 (  7.3%)  12.8554 (  3.5%)  12.8635 (  5.6%)  pre-process profile data
to
>   10.6613 (  3.1%)   1.6489 (  6.7%)  12.3102 (  3.3%)  12.3134 (  5.3%)  pre-process profile data

Reviewed By: dblaikie

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

After the library is linked and trivially inlined, the generic fma and
fmuladd intrinsics already handle these cases, and with precise flag
handling. This was requiring all fast math flags when we really just
need nsz for the fma(a, b, 0) case.

https://reviews.llvm.org/D156677

Suboptimal fix after 25bc999d. Ideally
this would go through a builder and use the proper alloca type instead
of using hardcoded mangled names.

Arg::print calls Option::print and Option::print calls itself
recursively. Add a flag so we can avoid seemingly random breaks in the
print output of an argument list.

No tests since this only affects debug output.

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

Readers can git-blame and find the necessary context if absolutely needed.
Otherwise, the presence of the link doesn't provide much value.

Moral of the story: don't emit `movi.2d #0` on any target affected by this.

This has been deprecated and should be removed now.

Reviewed By: #libc, Mordante

Spies: Mordante, libcxx-commits

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

This was trying to constant fold these calls, and also turn some of
them into a regular fmul/fdiv. There's no point to doing that, the
underlying library implementation should be using those in the first
place. Even when the library does use the rcp intrinsics, the backend
handles constant folding of those. This was also only performing the
folds under overly strict fast-evertyhing-is-required conditions.

The one possible plus this gained over linking in the library is if
you were using all fast math flags, it would propagate them to the new
instructions. We could address this in the library by adding more fast
math flags to the native implementations.

The constant fold case also had no test coverage.

https://reviews.llvm.org/D156676

This is no longer used as of 8e71d149.

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

https://reviews.llvm.org/D157498

In some (likely invalid edge cases anyway), it's not correct to
directly copy the stack pointer register.

This allows use with non-0 address space stacks. llvm_ptr_ty should
never be used. This could use some more percolation up through mlir,
but this is enough to fix existing tests.

https://reviews.llvm.org/D156666

https://reviews.llvm.org/D145791 added a new overload of encodeInstruction.
All in-tree targets have been migrated to use the new overload.

The radar in question has long since been closed, and the issue the README
documented appears to have been fixed (at least as of clang 16, if not
earlier):

https://clang.godbolt.org/z/7KT5nnoTo

Nvidia uses a 32-bit mask, but we store it in a common 64-bit integer to
provide it with a compatible ABI with the AMD implementaiton which may
use a 64-bit mask. Silence these warnings by explicitly casting to the
smaller value, we know this is always legal as the result will always
fit into the smaller value if it was generated on NVPTX.

Reviewed By: sivachandra

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

TSan reports the following race:

  Write of size 8 at 0x000107707ee8 by main thread:
    #0 lldb_private::ThreadedCommunication::StartReadThread(...) ThreadedCommunication.cpp:175
    #1 lldb_private::Process::SetSTDIOFileDescriptor(...) Process.cpp:4533
    #2 lldb_private::Platform::DebugProcess(...) Platform.cpp:1121
    #3 lldb_private::PlatformDarwin::DebugProcess(...) PlatformDarwin.cpp:711
    #4 lldb_private::Target::Launch(...) Target.cpp:3235
    #5 CommandObjectProcessLaunch::DoExecute(...) CommandObjectProcess.cpp:256
    #6 lldb_private::CommandObjectParsed::Execute(...) CommandObject.cpp:751
    #7 lldb_private::CommandInterpreter::HandleCommand(...) CommandInterpreter.cpp:2054

  Previous read of size 8 at 0x000107707ee8 by thread T5:
    #0 lldb_private::HostThread::IsJoinable(...) const HostThread.cpp:30
    #1 lldb_private::ThreadedCommunication::StopReadThread(...) ThreadedCommunication.cpp:192
    #2 lldb_private::Process::ShouldBroadcastEvent(...) Process.cpp:3420
    #3 lldb_private::Process::HandlePrivateEvent(...) Process.cpp:3728
    #4 lldb_private::Process::RunPrivateStateThread(...) Process.cpp:3914
    #5 std::__1::__function::__func<lldb_private::Process::StartPrivateStateThread(...) function.h:356
    #6 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(...) HostNativeThreadBase.cpp:62
    #7 lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(...) HostThreadMacOSX.mm:18

The problem is the lack of synchronization between starting and stopping
the read thread. This patch fixes that by protecting those operations
with a mutex.

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

The original commit, and the comments in the code already provide sufficient
context. But for posterity, there's a tiny bit more that might be useful if
someone is digging here in the future:

> This is related to <rdar://problem/10318439> Lower invokes into terminating
> machine instructions.
>
> The return value from a function call is live in to that function call's
> landing pad. The landing pad is shared with a later call, and the variable is
> undef on the first exceptional edge.
>
> Our computation of the last legal split point gets confused because the
> return value is live-out from the calling block, and live-in to the landing
> pad, but it is not live on the edge itself.
>
> Fixed in r147911 and r147912.

Remove another reference to the same radar.

This patch removes two log messages that were causing noisy output:
- when we have a zero sized symbol that gets removed in favor of something with a size or with debug info
- when an inlined function's address range has the same high and low pc, don't emit an error message as this is a common technique to indicate a function has been stripped or is no longer present.

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

This work introduces the `wgmma.mma_async` Op along PTX generation using `BasicPtxBuilderOpInterface`. The Op is designed to execute the matrix multiply-and-accumulate operation across a warpgroup (128 threads). It's important to note that this operation works for devices with the sm_90a capability.

The matrix multiply-and-accumulate operation can take one of the following forms. In both cases, matrix D is referred to as the accumulator:
	D = A * B + D 	: Result is added to the accumulator matrix D.
	D = A * B 		: The input from the accumulator matrix D is not utilized.

Reviewed By: nicolasvasilache

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

D58335 introduced FK_Data_6b for emitting R_RISCV_SET6/R_RISCV_SUB6 in
.eh_frame/.debug_frame.

This is no longer needed after commit
c8ed138c removed unneeded fixup kinds
for R_RISCV_{SET,ADD,SUB}* and getKindForSizeInBits.