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

LLVM and SPIRV-LLVM-Translator pulldown (WW15 2024) #13362

Merged
merged 548 commits into from
Apr 15, 2024
Merged

Conversation

iclsrc
Copy link
Contributor

@iclsrc iclsrc commented Apr 11, 2024

arsenm and others added 30 commits April 8, 2024 09:32
Correct strictfp tests to follow the rules documented in the LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

These tests needed the strictfp attribute added to some function
definitions. FP wait instructions now appear as a result.

Test changes verified with D146845.
These were accidentally broken in 61efea7.

Thanks to @mgorny and @rjodinchr for spotting this.
  CONFLICT (content): Merge conflict in libclc/CMakeLists.txt
This PR adds handling for TXT records in the GOFF reader.

---------

Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>
readability-identifier-naming now supports renaming designated
initializers.
…ics.

https://alive2.llvm.org/ce/z/ivPZ26 for the abs transformations.

Reviewers: RKSimon

Reviewed By: RKSimon

Pull Request: llvm/llvm-project#86135
The last fix was incomplete.
Now that we have AST nodes for OpenACC Clauses, this patch adds their
creation to Sema and makes the Parser call all the required functions.
This also redoes TreeTransform to work with the clauses/make sure they
are transformed.

Much of this is NFC, since there is no clause we can test this behavior
with. However, there IS one noticable change; we are now no longer
diagnosing that a clause is 'not implemented' unless it there was no
errors parsing its parameters. This is because it cleans up how we
create and diagnose clauses.
I brain-farted on how assert works :)
…is present (#87677)

This behavior is aligned with both LoopVectorizer and SLPVectorizer.
In full build mode, the fuzzing tests fail to build. This PR disabled MPFR related tests in full build
```
[2/4] Building CXX object projects/libc/fuzzing/stdio/CMakeFiles/libc.fuzzing.stdio.printf_float_conv_fuzz.dir/printf_float_conv_fuzz.cpp.o
FAILED: projects/libc/fuzzing/stdio/CMakeFiles/libc.fuzzing.stdio.printf_float_conv_fuzz.dir/printf_float_conv_fuzz.cpp.o 
/usr/bin/clang++ -DLIBC_NAMESPACE=__llvm_libc_19_0_0_git -I/home/schrodingerzy/Documents/llvm/llvm-project/build/projects/libc/fuzzing/stdio -I/home/schrodingerzy/Documents/llvm/llvm-project/libc/fuzzing/stdio -I/home/schrodingerzy/Documents/llvm/llvm-project/libc -isystem /home/schrodingerzy/Documents/llvm/llvm-project/build/projects/libc/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fsanitize=fuzzer -O2 -g -DNDEBUG -std=c++17 -MD -MT projects/libc/fuzzing/stdio/CMakeFiles/libc.fuzzing.stdio.printf_float_conv_fuzz.dir/printf_float_conv_fuzz.cpp.o -MF projects/libc/fuzzing/stdio/CMakeFiles/libc.fuzzing.stdio.printf_float_conv_fuzz.dir/printf_float_conv_fuzz.cpp.o.d -o projects/libc/fuzzing/stdio/CMakeFiles/libc.fuzzing.stdio.printf_float_conv_fuzz.dir/printf_float_conv_fuzz.cpp.o -c /home/schrodingerzy/Documents/llvm/llvm-project/libc/fuzzing/stdio/printf_float_conv_fuzz.cpp
In file included from /home/schrodingerzy/Documents/llvm/llvm-project/libc/fuzzing/stdio/printf_float_conv_fuzz.cpp:19:
In file included from /home/schrodingerzy/Documents/llvm/llvm-project/libc/utils/MPFRWrapper/mpfr_inc.h:21:
In file included from /usr/include/mpfr.h:53:
In file included from /usr/include/gmp.h:35:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/iosfwd:38:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/requires_hosted.h:31:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/x86_64-pc-linux-gnu/bits/c++config.h:679:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/x86_64-pc-linux-gnu/bits/os_defines.h:44:5: error: function-like macro '__GLIBC_PREREQ' is not defined
   44 | #if __GLIBC_PREREQ(2,15) && defined(_GNU_SOURCE)
      |     ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/x86_64-pc-linux-gnu/bits/os_defines.h:55:5: error: function-like macro '__GLIBC_PREREQ' is not defined
   55 | #if __GLIBC_PREREQ(2, 26) \
      |     ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/x86_64-pc-linux-gnu/bits/os_defines.h:66:6: error: function-like macro '__GLIBC_PREREQ' is not defined
   66 | # if __GLIBC_PREREQ(2, 27)
      |      ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/x86_64-pc-linux-gnu/bits/os_defines.h:78:6: error: function-like macro '__GLIBC_PREREQ' is not defined
   78 | # if __GLIBC_PREREQ(2, 34)
      |      ^
In file included from /home/schrodingerzy/Documents/llvm/llvm-project/libc/fuzzing/stdio/printf_float_conv_fuzz.cpp:19:
In file included from /home/schrodingerzy/Documents/llvm/llvm-project/libc/utils/MPFRWrapper/mpfr_inc.h:21:
In file included from /usr/include/mpfr.h:53:
In file included from /usr/include/gmp.h:35:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/iosfwd:42:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/postypes.h:40:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:64:11: error: no member named 'mbstate_t' in the global namespace
   64 |   using ::mbstate_t;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:143:11: error: no member named 'btowc' in the global namespace
  143 |   using ::btowc;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:144:11: error: no member named 'fgetwc' in the global namespace
  144 |   using ::fgetwc;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:145:11: error: no member named 'fgetws' in the global namespace
  145 |   using ::fgetws;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:146:11: error: no member named 'fputwc' in the global namespace
  146 |   using ::fputwc;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:147:11: error: no member named 'fputws' in the global namespace
  147 |   using ::fputws;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:148:11: error: no member named 'fwide' in the global namespace
  148 |   using ::fwide;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:149:11: error: no member named 'fwprintf' in the global namespace
  149 |   using ::fwprintf;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:150:11: error: no member named 'fwscanf' in the global namespace
  150 |   using ::fwscanf;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:151:11: error: no member named 'getwc' in the global namespace
  151 |   using ::getwc;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:152:11: error: no member named 'getwchar' in the global namespace
  152 |   using ::getwchar;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:153:11: error: no member named 'mbrlen' in the global namespace
  153 |   using ::mbrlen;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:154:11: error: no member named 'mbrtowc' in the global namespace
  154 |   using ::mbrtowc;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:155:11: error: no member named 'mbsinit' in the global namespace
  155 |   using ::mbsinit;
      |         ~~^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/cwchar:156:11: error: no member named 'mbsrtowcs' in the global namespace
  156 |   using ::mbsrtowcs;
      |         ~~^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
```
… (#87415)

The specification allow list-directed PRINT and WRITE statements to
appear in device code. This patch relax the semantic check to allow
them.

3.6.11.
List-directed PRINT and WRITE statements to the default unit may be used
when compiling for compute capability 2.0 and higher; all other uses of
PRINT and WRITE are disallowed.
This restructures the code to make the fact that most of
getVLENFactoredAmount is just a generic multiply w/immediate more
obvious and prepare for a couple of upcoming enhancements to this code.

Note that I plan to switch mulImm to early return, but decided I'd do
that as a separate commit to keep this diff readable.

---------

Co-authored-by: Luke Lau <luke_lau@icloud.com>
This patch introduces `SemaHLSL` class, and moves some HLSL-related
functions there. No functional changes intended.

Removing "HLSL" from function names inside `SemaHLSL` is left for a
subsequent PR by HLSL contributors, if they deem that desirable.

This is a part of the effort to split `Sema` into smaller manageable
parts, and follows the example of OpenACC. See #82217, #84184, #87634
for additional context.
This patch covers
[CWG605](https://cplusplus.github.io/CWG/issues/605.html) "Linkage of
explicit specializations",
[CWG650](https://cplusplus.github.io/CWG/issues/650.html) "Order of
destruction for temporaries bound to the returned value of a function",
[CWG653](https://cplusplus.github.io/CWG/issues/653.html) "Copy
assignment of unions",
[CWG658](https://cplusplus.github.io/CWG/issues/658.html) "Defining
`reinterpret_cast` for pointer types",
[CWG661](https://cplusplus.github.io/CWG/issues/661.html) "Semantics of
arithmetic comparisons",
[CWG672](https://cplusplus.github.io/CWG/issues/672.html) "Sequencing of
initialization in _new-expression_s".

[CWG624](https://cplusplus.github.io/CWG/issues/624.html) "Overflow in
calculating size of allocation" and
[CWG668](https://cplusplus.github.io/CWG/issues/668.html) "Throwing an
exception from the destructor of a local static object" are marked as
requiring libc++abi tests.
…-win-x-* configurations (#88011)

Fix for issue:
llvm/llvm-project#87277 (comment)

The test fails on the windows to linux cross builders. The proposed
resolution is to print some text. The issue is possibly due to the
original test outputting a single `\n` character.
Add a number of LAA test cases with both forward and backward
dependences with non-constant strides and dependence distances.

This includes test coverage for
llvm/llvm-project#87336

Also includes a LoopLoadElimination test to make sure the pass does not
crash on non-constant dependence distances.
[CWG593](https://cplusplus.github.io/CWG/issues/593.html) "Falling off
the end of a destructor's function-try-block handler". As usual with CWG
issues resolved as NAD, we test for status-quo confirmed by CWG.
This is a follow-up to #81506. As discussed in #87737, we're rejecting
incomplete types, save for exceptions listed in the C++ standard (`void`
and arrays of unknown bound). Note that arrays of unknown bound of
incomplete types are accepted.

Since we're happy with the current behavior of this intrinsic for
flexible array members
(llvm/llvm-project#87737 (comment)),
I added a couple of tests for that as well.
Correct a strictfp test to follow the rules documented in the
LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

This test needed the strictfp attribute added to some function
definitions. FP wait instructions now appear as a result. The need
for the wait instructions is explained by Andy Kaylor in PR#87791:
llvm/llvm-project#87791

Test changes verified with D146845.
Don't accept a putative statement function definition for a symbol that
is a subprogram but can't possibly be a statement function.

Fixes llvm/llvm-project#86936.
A reduction folding template assumed lower bounds were 1.

Fixes llvm/llvm-project#86935.
…CIT (#87280)

A derived type name in an IMPLICIT statement might be a host association
or it might be a forward reference to a local derived type, which may be
shadowing a host-associated name. Add a scan over the specification part
in search of derived type definitions to determine the right
interpretation.

Fixes llvm/llvm-project#87215.
@jsji jsji marked this pull request as ready for review April 12, 2024 02:23
@jsji jsji requested review from a team and bader as code owners April 12, 2024 02:23
@jsji jsji requested a review from JackAKirk April 12, 2024 02:23
@JackAKirk
Copy link
Contributor

This hasn't triggered any cuda e2e testing from what I can see. It would be good to do this to confirm there are no issues.
I don't see any major amdgpu/cuda changes so I wouldn't expect any issues.

@jsji
Copy link
Contributor

jsji commented Apr 12, 2024

This hasn't triggered any cuda e2e testing from what I can see. It would be good to do this to confirm there are no issues. I don't see any major amdgpu/cuda changes so I wouldn't expect any issues.

Thanks @JackAKirk . It is interesting that we did not even trigger CUDA tests with such huge changes.

@jsji
Copy link
Contributor

jsji commented Apr 12, 2024

This hasn't triggered any cuda e2e testing from what I can see. It would be good to do this to confirm there are no issues. I don't see any major amdgpu/cuda changes so I wouldn't expect any issues.

Thanks @JackAKirk . It is interesting that we did not even trigger CUDA tests with such huge changes.

Actually, we did trigger CUDA e2e test here: https://github.com/intel/llvm/actions/runs/8655894409/job/23735557333
But unfortunately update_check failed. https://github.com/intel/llvm/actions/runs/8655894409/job/23736551645
@intel/dpcpp-devops-reviewers Looks like password or other credentials expired or something ?
"Error: Unhandled error: HttpError: Resource not accessible by integration"

Only 1 failures, which also failed before this. So we are good. @JackAKirk .

Failed Tests (1):
  SYCL :: bindless_images/read_norm_types.cpp

Copy link
Contributor

@JackAKirk JackAKirk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM for hip/cuda

@jsji
Copy link
Contributor

jsji commented Apr 12, 2024

Actually, we did trigger CUDA e2e test here: https://github.com/intel/llvm/actions/runs/8655894409/job/23735557333 But unfortunately update_check failed. https://github.com/intel/llvm/actions/runs/8655894409/job/23736551645 @intel/dpcpp-devops-reviewers Looks like password or other credentials expired or something ? "Error: Unhandled error: HttpError: Resource not accessible by integration"

Hmm... Last CUDA e2e success was https://github.com/intel/llvm/actions/runs/8460746056 2 weeks ago!! So looks like a problem caused by #13173 again.. FYI. @stdale-intel @intel/dpcpp-devops-reviewers

@jsji
Copy link
Contributor

jsji commented Apr 12, 2024

Last CUDA e2e success was https://github.com/intel/llvm/actions/runs/8460746056 2 weeks ago!! So looks like a problem caused by #13173 again.. FYI. @stdale-intel @intel/dpcpp-devops-reviewers

#13377 Posted to fix it.

@jsji
Copy link
Contributor

jsji commented Apr 15, 2024

@intel/dpcpp-cfe-reviewers Can someone have a quick look at this testcase update and add comments/approval explicitly so that this can be merged. Thanks.

@elizabethandrews
Copy link
Contributor

@intel/dpcpp-cfe-reviewers Can someone have a quick look at this testcase update and add comments/approval explicitly so that this can be merged. Thanks.

It is not clear to me if the solution here is to add the warning flag or modify the tests itself. Where was the warning being fired?@zahiraam can you take a look?

@zahiraam
Copy link
Contributor

@intel/dpcpp-cfe-reviewers Can someone have a quick look at this testcase update and add comments/approval explicitly so that this can be merged. Thanks.

It is not clear to me if the solution here is to add the warning flag or modify the tests itself. Where was the warning being fired?@zahiraam can you take a look?

From my reading of #6323 and the original code of the tests, the warnings should stay.

@jsji
Copy link
Contributor

jsji commented Apr 15, 2024

From my reading of #6323 and the original code of the tests, the warnings should stay.

Thanks @zahiraam .
Yes, we still have those warnings if we don't disable them.
But these are community tests, disabling these warnings using options in RUN lines will help reducing the conflicts and maintenance effort. We keep the testing point of community tests synced with community, without having to check the warnings we added in #6323.

For #6323, we have other tests, especially sycl related code that will test it, so I don't think we need to update the community tests in HLSL to check the warning message as well.

@zahiraam
Copy link
Contributor

From my reading of #6323 and the original code of the tests, the warnings should stay.

Thanks @zahiraam . Yes, we still have those warnings if we don't disable them. But these are community tests, disabling these warnings using options in RUN lines will help reducing the conflicts and maintenance effort. We keep the testing point of community tests synced with community, without having to check the warnings we added in #6323.

For #6323, we have other tests, especially sycl related code that will test it, so I don't think we need to update the community tests in HLSL to check the warning message as well.

I see. So adding the flag in the RUN line would actually allow the tests to be synced with community. In this case, I think that makes sense to me.

@jsji
Copy link
Contributor

jsji commented Apr 15, 2024

@bader @intel/llvm-gatekeepers This is ready for merge. Thanks.

@bader
Copy link
Contributor

bader commented Apr 15, 2024

/merge

@bb-sycl
Copy link
Contributor

bb-sycl commented Apr 15, 2024

Mon 15 Apr 2024 03:53:49 PM UTC --- Start to merge the commit into sycl branch. It will take several minutes.

@bb-sycl
Copy link
Contributor

bb-sycl commented Apr 15, 2024

Mon 15 Apr 2024 03:58:08 PM UTC --- Merge the branch in this PR to base automatically. Will close the PR later.

@bb-sycl bb-sycl merged commit 06bd6bc into sycl Apr 15, 2024
17 of 18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disable-lint Skip linter check step and proceed with build jobs
Projects
None yet
Development

Successfully merging this pull request may close these issues.