-
Notifications
You must be signed in to change notification settings - Fork 730
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 (WW22 2024) #13969
Conversation
…ctions (#91699) Availability diagnostic in instantiated template functions was intentionally skipped in the original [commit](llvm/llvm-project@5cd5717) years ago with a FIXME note. I ran into this when working on diagnostics for HLSL. When I remove the skip, it seems to be working just fine outputting expected messages. So, unless I am missing something, I would keep it enabled and use it for checking availability in HLSL templates as well.
The terminfo dependency introduces a significant nonhermeticity into the build. It doesn't respect `--no-undefined-version` meaning that it's not a dependency that can be built with Clang 17+. This forces maintainers of source-based distributions to implement patches or ignore linker errors. Remove it to reduce the closure size and improve portability of LLVM-based tools. Users can still use command line arguments to toggle color support expliticly. Fixes #75490 Closes #53294 #23355
On RISC-V, there are a few ways to control whether the PostMachineScheduler is enabled. If `-enable-post-misched` is passed or passed with a value of true, then the PostMachineScheduler is enabled. If it is passed with a value of false then the PostMachineScheduler is disabled. If the option is not passed at all, then `RISCVSubtarget::enablePostRAMachineScheduler` decides whether the pass should be enabled or not. `TargetSubtargetInfo::enablePostRAScheduler` and `TargetSubtargetInfo::enablePostRAMachineScheduler` who check the SchedModel value are not called by RISC-V backend. `RISCVSubtarget::enablePostRAMachineScheduler` currently checks if the active scheduler model sets `PostRAScheduler`. If it is set to true by the scheduler model, then the pass is enabled. If it is not set to true by the scheduler model, then the value of `UsePostRAScheduler` subtarget feature is used. I argue that the RISC-V backend should not use `PostRAScheduler` field of the scheduler model to control whether the PostMachineScheduler is enabled for the following reasons: 1. No other targets use this value to control whether PostMachineScheduler is enabled. They only use it to check whether the legacy PostRASchedulerList scheduler is enabled. 2. We can add the `UsePostRAScheduler` feature to the processor definition in RISCVProcessors.td to tie a processor to whether the pass should be enabled by default. This makes the feature and the sched model field redundant. 3. Since these options are redundant, we should prefer the feature, since we can set `+` and `-` on the feature, but the value of the scheduler cannot be controlled on the command line. 4. Keeping both options allows us to set the feature and the scheduler model value to conflicting values. Although the scheduler model value will win out, it feels awkward to allow it.
The profile density feature(the amount of samples in the profile relative to the program size) is used to identify insufficient sample issue and provide hints for user to increase sample count. A low-density profile can be inaccurate due to statistical noise, which can hurt FDO performance. This change introduces two improvements to the current density work. 1. The density calculation/definition is changed. Previously, the density of a profile was calculated as the minimum density for all warm functions (a function was considered warm if its total samples were within the top N percent of the profile). However, there is a problem that a high total sample profile can have a very low density, which makes the density value unstable. - Instead, we want to find a density number such that if a function's density is below this value, it is considered low-density function. We consider the whole profile is bad if a group of low-density functions have the sum of samples that exceeds N percent cut-off of the total samples. - In implementation, we sort the function profiles by density, iterate them in descending order and keep accumulating the body samples until the sum exceeds the (100% - N) percentage of the total_samples, the profile-density is the last(minimum) function-density of processed functions. We introduce the a flag(`--profile-density-threshold`) for this percentage threshold. 2. The density is now calculated based on final(compiler used) profiles instead of merged context-less profiles.
Disable the TestDebuggerAPI test in case of the remote target and Windows host.
When buildbots are crowded, the libomp LIT tests may hit timeouts so extend the limit from 1800 to 3000 seconds.
… (#85837) Introduced in #78041, originally reported as #79957 and fixed partially in #80050. `OpaqueValueExpr` used with `TemplateArgument::StructuralValue` has no corresponding source expression. A test case with subobject-referring NTTP added.
Use UTC. Add test coverage for AIX.
Even as the NPM has been in use by Polly for a while now, the majority of the tests continue using the LPM passes. This patch ports the tests to use the NPM passes (for example, by replacing a flag such as -polly-detect with -passes=polly-detect following the NPM syntax for specifying passes) with some exceptions for some missing features in the new passes. Relanding #90632.
Remove this test since it is marked as XFAIL and has some non-deterministic behaviour which causes it to spuriously pass on out-of-tree builds. Capturing this in llvm/llvm-project#93342 to make a proper fix and a test later.
We compute BF hashes in `YAMLProfileReader::readProfile` when first matching profile functions with binary functions, and second time in `YAMLProfileReader::parseFunctionProfile` during the profile assignment (we need to do that to account for LTO private functions with mismatching suffix). Avoid recomputing the hash if it's been set.
These are useful for finer-grain debugging and complement the already exposed global debug flag.
…(#89950) Previously, since response (.rsp) files weren't expanded at the very beginning of clang-scan-deps, we only parsed the command-line as provided in the Clang .cdb file. Unfortunately, when using Unreal Engine, arguments are always generated in a .rsp file (ie. `/path/to/clang-cl.exe @/path/to/filename_args.rsp`). After this patch, `/Fo` can be parsed and added to the final command-line. Without this option, the make targets that are emitted are made up from the input file name alone. We have some cases where the same input in the project generates several output files, so we end up with duplicate make targets in the scan-deps emitted dependency file.
llvm/llvm-project#93106 introduced some necessary fixes to module file generation, but has also caused a regression. The module file output can include bogus attempts to USE-associate symbols local to derived type scopes, like components and bindings. Fix, and extend a test.
We only know it expands to a 2 instruction sequence, not necessarily a sign extended sequence. Happened to notice while I was looking at naming for the proposed rematerializable LUI+ADDI for addresses.
Move out common X86MemOperand checks into helper lambdas. To be reused in #91667. Test Plan: NFC
As we have debuginfod as symbol locator available in lldb now, we want to make full use of it. In case of post mortem debugging, we don't always have the main executable available. However, the .note.gnu.build-id of the main executable(some other modules too), should be available in the core file, as those binaries are loaded in memory and dumped in the core file. We try to iterate through the NT_FILE entries, read and store the gnu build id if possible. This will be very useful as this id is the unique key which is needed for querying the debuginfod server. Test: Build and run lldb. Breakpoint set to https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolLocator/Debuginfod/SymbolLocatorDebuginfod.cpp#L147 Verified after this commit, module_uuid is the correct gnu build id of the main executable which caused the crash(first in the NT_FILE entry) Previous PR: llvm/llvm-project#92078 was mistakenly merged. This PR is re-opening the commit.
Simplify mutually exclusive sanity checks in analyzeIndirectBranch, where an UNKNOWN IndirectBranchType is to be returned. Reduces confusion and code duplication when adding a new IndirectBranchType (to be added in #91667). Test Plan: NFC
Inline traits used by `arith.select` only into `ArithOps.td`. Trim trailing whitespace in op description.
Move out common code extracting the address of a MCExpr. To be reused in #91667. Test Plan: NFC
Enables writing patterns where one has op creation with variadic in result pattern more easily. Signed-off-by: Jacques Pienaar <jpienaar@google.com>
…onment is MSVC (#91689) From looking at the rest of code and from my own understanding, the driver mode is supposed to be independent of MSVC compatibility when the target triple is `*-windows-msvc`. Therefore strict aliasing should be disabled by default when the target triple is `*-windows-msvc` so code assuming MSVC behaves as expected when compiled with Clang.
This is ready for review.
These two are trivial fixes in tests or message. @intel/dpcpp-cfe-reviewers Can someone have a quick look? |
@intel/llvm-gatekeepers Can someone help to issue a |
Is it ok for PR to be in 'draft' state when we issue '/merge'? Thanks |
I think so. @bader recommended to keep the PR in draft state to avoid sending out notifications for unintended reviewers. |
/merge |
Not sure if I have permission, but if I do, it was a pleasure serving with all of you. |
Wed 26 Jun 2024 03:54:58 PM UTC --- Start to merge the commit into sycl branch. It will take several minutes. |
Wed 26 Jun 2024 03:59:15 PM UTC --- Merge the branch in this PR to base automatically. Will close the PR later. |
LLVM: llvm/llvm-project@73e22ff
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@d4098cd