Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AutoBump] Merge with e99755d4 (Sep 16) (3) #417

Merged
merged 482 commits into from
Dec 13, 2024

Conversation

jorickert
Copy link

No description provided.

hnrklssn and others added 30 commits September 13, 2024 10:47
Adds a python script to automatically take output from a failed clang
-verify test and update the test case(s) to expect the new behaviour.
* To create custom ABIs plugin libraries need access to CoroShape.
* As a step in enabling plugin libraries, move Shape into its own header
* The header will eventually be moved into include/llvm/Transforms/Coroutines

See RFC for more info:
https://discourse.llvm.org/t/rfc-abi-objects-for-coroutines/81057
…izationRewrite` (llvm#108359)

The dialect conversion maintains a set of unresolved materializations
(`UnrealizedConversionCastOp`). Turn that set into a `DenseMap` that
maps from ops to `UnresolvedMaterializationRewrite *`. This improves
efficiency a bit, because an iteration over
`ConversionPatternRewriterImpl::rewrites` can be avoided.

Also delete some dead code.
This patch implements sandboxir::GlobalObject mirroring
llvm::GlobalObject.
This patch implements a new empty pass for the Bottom-up vectorizer and
creates a pass pipeline that includes it.
The SandboxVectorizer LLVM pass runs the Sandbox IR pass pipeline.
Summary:
We can include `stdint.h` just fine as long as we don't allow it to find
system headers, passing `-nostdlibinc` and `-nogpuinc` suppresses these
extra paths so we will just use the clang resource headers for
`stdint.h` and `stddef.h`.
Should not return the original phi vector instruction, need to return
actual vectorized value as a result.
…iple `ucmp`/`scmp` operands and a constant with `phi` of individual comparisons of original intrinsic's arguments (llvm#107769)

When we have a `phi` instruction with more than one of its incoming
values being a call to `ucmp` or `scmp`, which is then compared with an
integer constant, we can move the comparison through the `phi` into the
incoming basic blocks because we know that a comparison of `ucmp`/`scmp`
with a constant will be simplified by the next iteration of InstCombine.

There's a high chance that other similar patterns can be identified, in
which case they can be easily handled by the same code by moving the
check for "simplifiable" instructions into a lambda.
Inline VPBuilder::createICmp in the header, in line with the other
VPBuilder functions.
Create `eh-assembly.s` that contains EH tests and remove EH tests from
`basic-assembly.s`, given that it's easier to manage. (We can have many
different tests, including the legacy EH and the new exnref, and with
nesting for readability)
)

This is a follow-up to llvm#92289 that adds lowering of the new
`@llvm.experimental.vector.compress` intrinsic on x86 with AVX512
instructions. This intrinsic maps directly to `vpcompress`.
This patch implements sandboxir::GlobalIFunc mirroring
llvm::GlobalIFunc.
This patch adds support for a user-defined pass-pipeline that overrides
the default pipeline of the vectorizer.
This will commonly be used by lit tests.
This allows the clang driver to know which tool is meant to be executed,
which allows the clang driver to load the right clang config files, and
allows clang to find colocated sysroots.

This makes sure that doing `clang-scan-deps -- <tool> ...` looks up
things in the same way as if one just would execute `<tool> ...`, when
`<tool>` isn't an absolute or relative path.
Emit signpost intervals for progress events so that when users report an
operation takes a long time, we can investigate the issue with
Instruments.app.
…n libc warnings (llvm#108308)

For `snprintf(a, sizeof a, ...)`, the first two arguments form a safe
pattern if `a` is a constant array. In such a case, this commit will
suppress the warning.

(rdar://117182250)
This change adds a new HLSL 202y language mode. Currently HLSL 202y is
planned to add `auto` and `constexpr`.

This change updates extension diagnostics to state that lambadas are a
"clang HLSL" extension (since we have no planned release yet to include
them), and that `auto` is a HLSL 202y extension when used in earlier
language modes.

Note: This PR does temporarily work around some differences between HLSL
2021 and 202x in Clang by changing test cases to explicitly specify
202x. A subsequent PR will update 2021's language flags to match 202x.
Extend VPBuilder to allow creating VPDerivedIVRecipe, VPScalarCastRecipe
and VPScalarIVStepsRecipe.

Use them to simplify the code to create scalar IV steps slightly.
This is a quick fix to unbreak Bazel build. The right solution would
probably add vdso.cpp in the support library which includes circular
dependency and needs more restructuring.
llvmgnsyncbot and others added 24 commits September 16, 2024 18:01
…cs section of RISCVUsage.rst. NFC (llvm#108718)

These are no longer experimental after
051054e. I left the section because we
will be adding intrinsics for Zvkgs and Zvbc32e.
…llvm#107905)

That missing space was causing the whole sentence to be rendered
incorrectly in the resulting HTML.
…st (llvm#108524)

This extends the fix in llvm#106242
for other derived class types.
…#108852)

In the process of adding scalarization support for DirectX target
intrinsics I found that intrinsics that weren't marked with `IntrNoMem`
did not get removed by
`RecursivelyDeleteTriviallyDeadInstructionsPermissive`. So this change
is to make it more clear that our intrinsics don't have side effects.

I only added `IntrNoMem` to the intrinics in `IntrinsicsDirectX.td` I
was involved with. There a potentially a few other cases that might
warrant this attribute, but will need input on the others.
There is possibility of
static_tls_begin is set and static_tls_end is not yet

The test reproduces the case.
Stack trace looks like this:
* `MsanThread::Init`
* `SetThreadStackAndTls`
* `GetThreadStackAndTls`
* `GetThreadStackTopAndBottom`
* `pthread_getattr_np`
* `realloc`
* `__sanitizer_malloc_hook`
* TLS access
* `___interceptor___tls_get_addr`
* `DTLS_on_tls_get_addr`

The issue is that `SetThreadStackAndTls` implementation
stores `tls_begin` before `GetThreadStackTopAndBottom`,
and `tls_end` after. So we have partially initialized
state in `DTLS_on_tls_get_addr`.
This is an implementation of `ctime` and includes `ctime_r`.

According to documentation, `ctime` and `ctime_r` are defined as the
following:

```c
char *ctime(const time_t *timep);
char *ctime_r(const time_t *restrict timep, char buf[restrict 26]);
```

closes llvm#86567
Given that the instructions here are all control flow instructions,
adding indentations seem to make it easier to read.
The plan was to make `eh-assembly.s` contain both the legacy and the new
tests, but the new tests require `--no-type-check` because the type
checker for the new EH is in progress. In case this drags on further
than expected, this renames the current file to `-legacy.s` in order to
follow the current naming scheme in `test/CodeGen/WebAssembly`.

After landing this first, `eh-assembly-new.s` in llvm#108668 will be renamed
to `eh-assembly.s`.
Secondary cache entries are now released to the OS from least recent to
most recent entries. This helps to avoid unnecessary scans of the cache
since entries ready to be released (specifically, entries that are
considered old relative to the configurable release interval) will
always be at the tail of the list of committed entries by the LRU
ordering. For this same reason, the `OldestTime` variable is no longer
needed to indicate when releases are necessary so it has been removed.
This PR is implementing `asfloat` for HLSL.

Fixes: llvm#70098

Co-authored-by: Joao Saffran <jderezende@microsoft.com>
This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
This PR adds `f6E2M3FN` type to mlir.

`f6E2M3FN` type is proposed in [OpenCompute MX
Specification](https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf).
It defines a 6-bit floating point number with bit layout S1E2M3. Unlike
IEEE-754 types, there are no infinity or NaN values.

```c
f6E2M3FN
- Exponent bias: 1
- Maximum stored exponent value: 3 (binary 11)
- Maximum unbiased exponent value: 3 - 1 = 2
- Minimum stored exponent value: 1 (binary 01)
- Minimum unbiased exponent value: 1 − 1 = 0
- Has Positive and Negative zero
- Doesn't have infinity
- Doesn't have NaNs

Additional details:
- Zeros (+/-): S.00.000
- Max normal number: S.11.111 = ±2^(2) x (1 + 0.875) = ±7.5
- Min normal number: S.01.000 = ±2^(0) = ±1.0
- Max subnormal number: S.00.111 = ±2^(0) x 0.875 = ±0.875
- Min subnormal number: S.00.001 = ±2^(0) x 0.125 = ±0.125
```

Related PRs:
- [PR-94735](llvm#94735) [APFloat]
Add APFloat support for FP6 data types
- [PR-105573](llvm#105573) [MLIR]
Add f6E3M2FN type - was used as a template for this PR
This reverts commit 69f3244.

Reason: buildbot breakage because Android doesn't have <gnu/libc-version.h>
https://lab.llvm.org/buildbot/#/builders/186/builds/2381

(It's probably easy to fix but I don't readily have an Android device to test.)
…cxx.rst` (llvm#108714)

This makes it easier for readers to locate how to build the library.
The paper was implemented by commit b0386a5
(https://reviews.llvm.org/D46845) in LLVM 7.0. But it would be nice to
have test coverage for desired properties of `insert_return_type`.

Closes llvm#99944
Fixes asan, msan crash on check added in llvm#108684.
The llvm#108684 includes reproducer of the issue.

Change interface of `GetThreadStackAndTls` to
set `tls_begin` and `tls_end` at the same time.
…-zbc.mir. NFC

The IR used loads instead of stores.
…tion signature (llvm#107644)

When there is a function signature mismatch between a call
instruction and the callee, lower the call to an indirect call. The
current behavior is to produce direct calls that may or may not be
valid PTX. Consider the following example with mismatching return
types:

```
%struct.1 = type <{i64}>
%struct.2 = type <{i64}>
declare %struct.1 @callee()
...
%call1 = call %struct.2 @callee()
%call2 = call i64 @callee()
```

The return type of `callee` in PTX is `.b8 _[8]`. The return type of
`%call1` will be the same and so the PTX has no problems. The return
type of `%call2` will be `.b64`, so the types will not match and PTX
will be unacceptable to ptxas. This despite all the types having the
same size. The same is true for mismatching parameter types.

If we instead convert these calls to indirect calls, we will generate
functional PTX when the types have the same size. If they do not have
the same size then the PTX will likely be incorrect, though this will not
necessarily be caught by ptxas. Also, even if the sizes are the same, if
the types differ then it is technically undefined behavior. This change
allows for more flexibility in the bitcode that can be lowered to
functioning PTX, at the cost of sometimes producing PTX that is less
clearly wrong than it would have been previously (i.e. incorrect indirect
calls are not as obviously wrong as incorrect direct calls). We consider
it okay to generate PTX with undefined behavior as the behavior of
calls with mismatching types is not explicitly defined.
When both CREL and the experimental lld partitions feature are enabled,
the relocation section may look like .crel.llvm_sympart.f1, and
`rels.relas` is empty. While here, support relocation sections with zero
entry.
The test expects a hex float format of `0x0p+0`, but AIX prints
`0x0.0p+0`. This change adjusts the test to accept both.
@jorickert jorickert requested a review from mgehre-amd December 12, 2024 15:07
Base automatically changed from bump_to_d5f0969c to feature/fused-ops December 12, 2024 15:08
@jorickert jorickert enabled auto-merge December 12, 2024 15:43
@jorickert jorickert merged commit 1700d25 into feature/fused-ops Dec 13, 2024
38 checks passed
@jorickert jorickert deleted the bump_to_e99755d4 branch December 13, 2024 13:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.