Instead of creating a copy of the vector, we should just pass a
reference along. The only method that calls this Ctor also holds onto a
non-mutable reference to the vector of strings so a copy should be
unnecessary.

- Remove usages of the non-existent `ignore-forks` field, conditions in
jobs already exist to prevent the jobs from running in forks.
- Don't use variables in the `printf` format string. Use `printf
"..%s.." "$foo"`. ([SC2059](https://www.shellcheck.net/wiki/SC2059))
- Double quote variable expansion to prevent globbing and word
splitting. ([SC2086](https://www.shellcheck.net/wiki/SC2086))
- Prefer `[ p ] || [ q ]` as `[ p -o q ]` is not well defined.
([SC2166](https://www.shellcheck.net/wiki/SC2166))
- Consider `{ cmd1; cmd2; } >> file` instead of individual redirects.
([SC2129](https://www.shellcheck.net/wiki/SC2129))
- Use `$(...)` notation instead of legacy notation `...`.
([SC2006](https://www.shellcheck.net/wiki/SC2006))
- Use `./*glob*` or `-- *glob*` so names with dashes won't become
options. ([SC2035](https://www.shellcheck.net/wiki/SC2035))
- Refactor JavaScript code in certain workflows.
- Change workflow variable substitution style of some wor...

This "bug" was probably not noticed because it doesn't affect any integer
type we currently support. It requires integers with more than 2x the
size of `unsigned long long`. However, with such types, the algorithm
used to break down the large integer into groups of size `unsigned long long`
didn't work because we rotated in the wrong direction.

For example, the 256 bit number (1 << 255) would yield the wrong answer
when used with the algorithm before this patch.

In particular, note that the current rotation happens to work for 128 bit
integers because it just swaps the halves in this case.

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


Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

Adopt the new markup overload, introduced in 77d10325, in the ARM
backend. This commit completes the migration and removes the old
overload.

Summary:
This patch improves the implementation of the standard `rand()` function
by implementing it in terms of the xorshift64star pRNG as described in
https://en.wikipedia.org/wiki/Xorshift#xorshift*. This is a good,
general purpose random number generator that is sufficient for most
applications that do not require an extremely long period. This patch
also correctly initializes the seed to be `1` as described by the
standard. We also increase the `RAND_MAX` value to be `INT_MAX` as the
standard only specifies that it can be larger than 32768.

This commit removes an optimization that skips the initialization of the
reduction struct if the number of threads in a team is 1. This
optimization
caused a bug with Hidden Helper Threads. When the task group is
initially
initialized by the master thread but a Hidden Helper Thread executes a
target
nowait region, it requires the reduction struct initialization to
properly
accumulate the data.

This commit also adds a LIT test for issue #57522 to ensure that the
issue is
properly addressed and that the optimization removal does not introduce
any
regressions.

Fixes: #57522

- Check `MakePointer*` load/store attribute values.
- Support coop matrix types in `MatrixTimesScalar` verification.
- Add test cases for all the remaining ops that accept coop matrix types.
- Split NV and KHR tests.

This patch fixes:

  llvm/lib/Target/AMDGPU/AMDGPU.h:297:18: error: private field 'TM' is
  not used [-Werror,-Wunused-private-field]

This addresses issues introduced by efe4a548

AutoFDO profile has no leading 0x in hex dumps.

Reviewed By: #bolt, rafauler

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

Add const qualifier to avoid warning "_cast from 'const char *' to 'char*' drops const qualifier [-Werror,-Wcast-qual]_"

This will allow enable LLVM_ENABLE_WERROR when build with clang-cl on Windows.
This is imported from https://github.com/openbsd/src/commit/b81763002452802e4f7304ea60f121253bd94

Also removed the gcc change for the cast-qual warning which is not needed with const qualifier added.

This patch is to add the support of declaring a Cray pointer in a
module.

Propagate "branch_weights" metadata whe turning a select into a
conditional branch in tryToUnfoldSelectInCurrBB

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

This patch ports the AMDGPURewriteUndefForPHI pass to the new pass
manager. With this, the pass is supported under both the legacy and the
new pass managers.

---------

Co-authored-by: Jun Wang <jun.wang7@amd.com>

It's weird that we're specifying this in both the dxil and the LLVM IR
way, but if we are we should at least be consistent about it.

These tests are still relatively flaky on certain buildbots and on some
developer machines. This patch hopefully reduces the noise produced by
these tests in those environments by setting the retry count to 2 so
that they will hopefully flaky pass rather than just fail while I
perform more investigation.

https://reviews.llvm.org/D158130

https://reviews.llvm.org/D158131

We want the !fpmath metadata to be attached to the sqrt intrinsic to
make it to the backend lowering. Emit an available_externally
definition which uses the builtin, which emits the !fpmath.

Fixes #64264

https://reviews.llvm.org/D156743

Make codegen emit correctly rounded sqrt by default.

Emit the fast but only kind of fast expansion in AMDGPUCodeGenPrepare
based on !fpmath, like the fdiv case. Hack around visitation ordering
problems from AMDGPUCodeGenPrepare using forward iteration instead of
a well behaved combiner.

https://reviews.llvm.org/D158129

This will reduce the number of notifications created when a pull request
label is added. Each team will only get a notification when their team's
label is added and not when other teams' labels are added.

This loop is wrong, most of targets are not defined yet.
Also if we build with LLVM_ENABLE_RUNTIMES, these deps
are irrelevant.

Previously, annotations were only emitted for function definitions. With
this change annotations are also emitted for declarations. Also, emitting
function annotations is now deferred until the end so that the most
up to date declaration is used which will have any inherited annotations.

Differential Revision: https://reviews.llvm.org/D156172/new/

This cleans up a unnecessary code that changes zero size allocation to
avoid the following error message

'cuMemAlloc(&ptr, sizeBytes)' failed with 'CUDA_ERROR_INVALID_VALUE'

Summary:
We currently call the GPU routine to terminate the current thread in
three separate locations .This should be wrapped into a helper function
to simplify the implementation.

Fix for an issue where clang was not adding the address space according
to the data layout, instead was using the default which resulted in a
crash at times. The fix includes changes to the cases of
LargeCapMemAlloc and CGroupMemAlloc where we are setting the AddrSpace
according to the DataLayout.

It's needed by compiler-rt/test/profile/instrprof-gc-sections.c, which
became active after 2344a72d.

The FileIndex values returned from GetFileInformationByHandle are
considered stable and uniquely identifying a file, as long as the
handle is open. When handles are closed, there are no guarantees
for their stability or uniqueness. On some file systems (such as
NTFS), the indices are documented to be stable even across handles.
But with some file systems, in particular network mounts, file
indices can be reused very soon after handles are closed.

When such file indices are used for LLVM's UniqueID, files are
considered duplicates as soon as the filesystem driver happens to
have used the same file index for the handle used to inspect the
file. This caused widespread, non-obvious (seemingly random)
breakage. This can happen e.g. if running on a directory that is
shared via Remote Desktop or VirtualBox.

To avoid the issue, use a hash of the canonicalized path for the
file as unique identifier, instead of using FileIndex.

This fixes https://github.com/llvm/llvm-project/issues/61401 and
https://github.com/llvm/llvm-project/issues/22079.

Performance wise, this adds (usually) one extra call to
GetFinalPathNameByHandleW for each call to getStatus(). A test
cases such as running clang-scan-deps becomes around 1% slower
by this, which is considered tolerable.

Change the equivalent() function to use getUniqueID instead of
checking individual file_status fields. The
equivalent(Twine,Twine,bool& result) function calls status() on
each path successively, without keeping the file handles open,
which also is prone to such false positives. This also gets rid
of checks of other superfluous fields in the
equivalent(file_status, file_status) function - the unique ID of
a file should be enough (that is what is done for Unix anyway).

This comes with one known caveat: For hardlinks, each name for
the file now gets a different UniqueID, and equivalent() considers
them different. While that's not ideal, occasional false negatives
for equivalent() is usually that fatal (the cases where we strictly
do need to deduplicate files with different path names are quite
rare) compared to the issues caused by false positives for
equivalent() (where we'd deduplicate and omit totally distinct files).

The FileIndex is documented to be stable on NTFS though, so ideally
we could maybe have used it in the majority of cases. That would
require a heuristic for whether we can rely on FileIndex or not.
We considered using the existing function is_local_internal for that;
however that caused an unacceptable performance regression
(clang-scan-deps became 38% slower in one test, even more than that
in another test).

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

This patch fixes:

  llvm/lib/Target/AMDGPU/SIISelLowering.cpp:2493:33: error: unused
  variable 'UserSGPRInfo' [-Werror,-Wunused-variable]

The safe mode is in-between the hardened and the debug modes, extending
the checks contained in the hardened mode with certain checks that are
relatively cheap and prevent common sources of errors but aren't
security-critical. Thus, the safe mode trades off some performance for
a wider set of checks, but unlike the debug mode, it can still be used
in production.

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

Also, we removed CMP0076 exception sometime back but did not adjust the
build rules. The adjustment in the build rules is also done in this
patch.

This reverts commit 54c1a9b2.
It breaks a few llvm bots.

Splits the cleanup block lowered from AsyncToAsyncRuntime.

The incentive of this change is to clarify the CFG branched by
`async.coro.suspend`.

The `async.coro.suspend` op branches into 3 blocks, depending on the
state of the coroutine:
1) suspend
2) resume
3) cleanup

The behavior before this change is that after the coroutine is resumed
and completed, it will jump to a shared cleanup block for destroying the
states of coroutines. The CFG looks like the following,

Entry block
        |                    \
   resume             |
        |                    |
            Cleanup
                   |
                End

This CFG can potentially be problematic, because the `Cleanup` block is
a shared block and it is not dominated by `resume`. For instance, if
some pass wants to add some specific cleanup mechanism to resume, it can
be confused and add them to the shared `Cleanup`, which leads to the
"operand not dominate its use" error because of the existence of the
other "Entry->cleanup" path.

After this change, the CFG will look like the following,

The overall structure of the lowered CFG can be the following,

  Entry (calling async.coro.suspend)
       |                    \
  Resume           Destroy (duplicate of Cleanup)
       |                     |
  Cleanup             |
       |                    /
     End (ends the corontine)

In this case, the Cleanup block tied to the Resume block will be
isolated from the other path and it is strictly dominated by "Resume".