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

This patch makes use of the HLFIR box produced for hlfir.declare
in place of the FIR box (the memref of hlfir.declare) when possible.

This makes the representation a little bit more clear, because
all accesses are made via a single box.
This reduces the life range of the original box, because the new
temporary box produced by embox/rebox is used from now.
Apparently, this works around some issues in the current HLFIR codegen,
for example, look at the LIT tests changes around fir.array_coor
produced by hlfir.designate codegen - using the FIR box for fir.array_coor
might result in using incorrect lbounds.
Apparently, this change enables more intrinsics simplifications
because the SimplifyIntrinsicsPass looks for explicit embox/rebox
in findBoxDef() to decide whether to apply the optimization.
This change also provides better association of the base addresses
referenced by OpenACC clauses with the corresponding boxes
that might be used explicit...

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

We were using some convoluted logic here to check if the result of a
`bool` returning function was false, causing MSVC to give a warning
about "'>': unsafe use of type 'bool' in operation". This just removes
the greater-than comparison of the bool against zero.

Add support for the `low_mem_addressing_bits` and
`high_mem_addressing_bits` keys in the stop reply packet,
in addition to the existing `addressing_bits`.  Same
behavior as in the qHostInfo packet.

Clean up AddressableBits so we don't need to check if
any values have been set in the object before using it
to potentially update the Process address masks.

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

This change fixes a case where there was a potential integer overflow
when multiplying two 32-bit values and assigning the result to a 64-bit
value.

The potential overflow has been present since https://reviews.llvm.org/D132455
was re-landed. The initial version of the patch defined MaxBucketSize and
NumberOfBuckets as size_t (which I guess would still be a problem for some
targets). When the patch was re-landed they were defined as uint32_t, making
the calculation of ExtHashMask subject to overflow.

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

This reverts commit e26c24b8.

These temporaries are only used in the callee, and their memory can be
reused after the call is complete.

rdar://58552124

Link: https://github.com/llvm/llvm-project/issues/38157
Link: https://github.com/llvm/llvm-project/issues/41896
Link: https://github.com/llvm/llvm-project/issues/43598
Link: https://github.com/ClangBuiltLinux/linux/issues/39
Link: https://reviews.llvm.org/rGfafc6e4fdf3673dcf557d6c8ae0c0a4bb3184402

Reviewed By: rjmccall

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

Lower the bind clause to the corresponding attribute

Depends on D158120

Reviewed By: razvanlupusoru

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

Reviewed By: razvanlupusoru

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

bot

I noticed that `-reorder-functions=exec-count` doesn't work as expected due to
a bug in the comparison function (which isn't symmetric). It is questionable
whether anyone would want to ever use the sorting method (as sorting by say
density is much better in all cases) but it is probably better to fix the bug.

Reviewed By: Amir

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

getUBSanFunctionTypeHash.

getUBSanFunctionTypeHash checks if a Type is a FunctionNoPrototype
by calling isa<FunctionNoProtoType>(). This does not work correctly when
the Type is wrapped in a sugar type such as an AttributedType. This
patch fixes this by using isFunctionNoProtoType() function which removes
sugar and returns the expected result.

The added test is a sanity check that the compiler no longer crashes
during compilation. It also compares the hash with and without the
function attribute for both FunctionNoProtoType and FunctionProtoType.
The hash remains the same for FunctionNoProtoType even with the addition
of an attribute.

rdar://113144087

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

This applies the fix as suggested by Gelbpunkt in https://github.com/llvm/llvm-project/issues/64730,

Thanks to Florian Mayer for pointing out that my earlier patch D151262
had caused this regression.

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

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

Fixed static analyzer concern about null value
dereference. getStmtForDiagnostics() can return
null. Ensure statement exists before dereference
in PathDiagnosticLocation::createBegin().

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

This patch improves the reduction tiling for linalg to support multiple
reduction dimensions.

Reviewed By: mravishankar

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

Alphabetical order, less whitespace
removed some verbose comments for readability
(which are preserved in the history if ever needed)

Reviewed By: Peiming

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

There's a large amount of commonality in the riscv upgrader, make that
clearer.  And check for a riscv prefix before diving in.

Reviewed  By: nikic

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

[SampleProfile] Potential use after move in SampleProfileLoader::promoteMergeNotInlinedContextSamples

SampleProfileLoader::promoteMergeNotInlinedContextSample adds
certain uninlined functions to the sample profile map (unordered_map, which is
previously read from a profile file). This action may cause the map to
be rehashed, invalidating all pointers to FunctionSamples used by many
members of SampleProfileLoader, while the existing code did nothing to
guard against that. This bug is theoretical since adding a few
new functions to a large profile usually won't trigger a rehash, or even
if there's a rehash std::unordered_map tries its best to expand its
capacity in-place.

This bug will trigger if the container type of sample profile map is
changed to llvm::DenseMap or other implementation, such as in D147740,
for SampleProfReader's performance reason.

Reviewed By: wenlei

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

This reorders the pass declarations and definitions in a
consistent order and makes the layout a bit more clear.
Also makes the "minipipeline" sparsification-and-bufferization
available through the command line for individual testing.

Reviewed By: Peiming

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

This keeps the definitions closer together.
Also removed some verbose comments for readability.

Reviewed By: Peiming

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

Older python versions (e.g. 3.8) don't accept `tuple[...]` etc. in type hints.

When emitting assembly we don't particularly want the binary DXIL
embedded in the output. This was mostly there for testing purposes, so
we update those tests to run the test directly using `opt` and
restrict the -dxil-embed and -dxil-globals passes to running normally
only in the case where we're trying to emit a DXContainer.

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

Not all declare clause have an exit operation attach to them and
therefore no dealloc function generated. Attach
the pre/post deallocation attribute only for the clauses that have
an exit operation.

Reviewed By: razvanlupusoru

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

Lowering was missing to generate the pre/post alloc/dealloc
functions for the acc declare variables. This patch adds the generation.
These functions have the descriptor as their unique argument.

Reviewed By: razvanlupusoru

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

The pipeline state data captured in the PSV0 section of the DXContainer
file encodes signature elements which are read by the runtime to map
inputs and outputs from the GPU program.

This change adds support for generating and parsing signature elements
with testing driven through the ObjectYAML tooling.

Reviewed By: bogner

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

Initially landed as 8c567e64, and
reverted in 4d800633.

../llvm/include/llvm/BinaryFormat/DXContainerConstants.def
../llvm/test/ObjectYAML/DXContainer/PSVv1-amplification.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv1-compute.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv1-domain.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv1-geometry.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv1-vertex.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-amplification.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-compute.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-domain.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-geometry.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-vertex.yaml

The TestEvents.py test I added for ShadowListeners fails on Windows.
Since there's no reason to believe the ShadowListeners feature has
different behavior from the other event-based tests here, I copied
the skips & expected_flakey's from the other tests in that file to
this one.

This commit starts enabling vector distruction over multiple
dimensions. It requires delinearize the lane ID to match the
expected rank. shape_cast and transfer_read now can properly
handle multiple dimensions.

Reviewed By: hanchung

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

This reverts commit 8c567e64.

The pipeline state data captured in the PSV0 section of the DXContainer
file encodes signature elements which are read by the runtime to map
inputs and outputs from the GPU program.

This change adds support for generating and parsing signature elements
with testing driven through the ObjectYAML tooling.

Reviewed By: bogner

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

Before refactoring this code, all arm64 were set to use the 32bit allocator. This patch reverts back that behavior for DriverKit.

Because we target DriverKit as the target OS, rather than a specific platform, reverting back to the previous behavior is preferred to fix a failure we are seeing on embedded platforms.
Though it may be more correct in the future to match the allocator to the platform being used.

rdar://113649286

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

Lower clauses to the routine info op.

Reviewed By: razvanlupusoru

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

Machine function splitting will become available for AArch64; since MFS
is no longer X86-only, the tests for generic behavior should live
somewhere other than tests/CodeGen/X86.

MFS implementation doesn't vary much across platforms, and most tests
should be identical between X86 and AArch64 besides instruction
selection, so the tests can live together in tests/CodeGen/Generic.

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

The wrong suffix was applied

Reviewed By: razvanlupusoru

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

We are able to fuse the pack op only if inner tiles are not tiled or
they are fully used. Otherwise, it could generate a sequence of
non-trivial ops.

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

Fixes #63795.

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

Drop unnecessary flags and metadata, add contract flags that should be
necessary.