forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 3
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 41fecca9 (Jun 14) (76) #340
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add the support to handle Linux kernel perf files. The functionality is under option -kernel. Note that currently only main kernel (in vmlinux) is handled: kernel modules are not handled. --------- Co-authored-by: Han Shen <shenhan@google.com>
…lvm#95337) This patch adds armv7m and armv8m runtimes to Fuchsia Clang toolchain configuration.
When the very first statement of the executable part has syntax errors, it's not at all obvious whether the error messages that are reported to the user should be those from its failure to be the last statement of the specification part or its failure to be the first executable statement when both failures are at the same character in the cooked character stream. Fortran makes this problem more exciting by allowing statement function definitions look a lot like several executable statements. The current error recovery scheme for declaration constructs depends on a look-ahead test to see whether the failed construct is actually the first executable statement. This works fine when the first executable statement is not in error, but should also allow for some error cases that begin with the tokens of an executable statement. This can obviously still go wrong for declaration constructs that are unparseable and also have ambiguity in their leading tokens with executable statements, but that seems to be a less likely case. Also improves error recovery for parenthesized items.
An assumed-rank dummy argument is not an acceptable MOLD argument to NULL(), whose result must have a known rank at compilation time.
Without this patch, a typical traversal over the value data looks like: uint32_t NV = Func.getNumValueDataForSite(VK, S); std::unique_ptr<InstrProfValueData[]> VD = Func.getValueForSite(VK, S); for (uint32_t V = 0; V < NV; V++) Do something with VD[V].Value and/or VD[V].Count; This patch adds getValueArrayForSite, which returns ArrayRef<InstrProfValueData>, so we can do: for (const auto &V : Func.getValueArrayForSite(VK, S)) Do something with V.Value and/or V.Count; I'm planning to migrate the existing uses of getValueForSite to getValueArrayForSite in follow-up patches and remove getValueForSite and getNumValueDataForSite.
llvm#95297) Accommodate operations with VALUE dummy arguments in the runtime support for the REDUCE intrinsic function by splitting most entry points into Reduce...Ref and Reduce...Value variants. Further work will be needed in lowering to call the ...Value entry points.
llvm#95332) …rective Implement fixed-form line continuation when the continuation line is the result of text produced by an #include or other preprocessing directive. This accommodates the somewhat common practice of putting dummy or actual arguments into a header file and #including it into several code sites. Fixes llvm#78928.
…m#94279)" (llvm#95231)" This reverts commit 7051073. The following code is now incorrectly rejected. ``` % cat neon.c #include <arm_neon.h> __attribute__((target("arch=armv8-a"))) uint64x2_t foo(uint64x2_t a, uint64x2_t b) { return veorq_u64(a, b); } % newclang --target=aarch64-linux-gnu -c neon.c neon.c:5:10: error: always_inline function 'veorq_u64' requires target feature 'outline-atomics', but would be inlined into function 'foo' that is compiled without support for 'outline-atomics' 5 | return veorq_u64(a, b); | ^ 1 error generated. ``` "+outline-atomics" seems misleading here.
Extra test cases that caused revert of llvm#92555
This patch is a collection of one-liner migrations to getValueArrayForSite.
The file was added to MLIRBindingsPythonCoreNoCAPI but objects weren't. Signed-off-by: Jacques Pienaar <jpienaar@google.com>
If NV == 0, nothing interesting happens after the "if" statement. We should just "continue" to the next value site. While I am at it, this patch migrates a use of getValueForSite to getValueArrayForSite.
The setAtom call introduced by e17bc02 was due to my misunderstanding of flushPendingLabels (see https://discourse.llvm.org/t/mc-removing-aligned-bundling-support/79518). When evaluating `.quad x-y`, MCExpr.cpp:AttemptToFoldSymbolOffsetDifference gives different results at parse time and layout time because the `if (FA->getAtom() == FB.getAtom())` condition in isSymbolRefDifferenceFullyResolvedImpl only works when `setAtom` with a non-null pointer has been called. Calling setAtom in flushPendingLabels does not help anything.
…vm#95313) 1. Added a conversion for `vector.deinterleave` to the `VectorToSPIRV` pass. 2. Added LIT tests for the new conversion. --------- Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>
Mach-O's `.subsections_via_symbols` mechanism associates a fragment with an atom (a non-temporary defined symbol). The current approach (`MCFragment::Atom`) wastes space for other object file formats. After llvm#95077, `MCFragment::LayoutOrder` is only used by `AttemptToFoldSymbolOffsetDifference`. While it could be removed, we might explore future uses for `LayoutOrder`. @aengelke suggests one use case: move `Atom` into MCSection. This works because Mach-O doesn't support `.subsection`, and `LayoutOrder`, as the index into the fragment list, is unchanged. This patch moves MCFragment::Atom to MCSectionMachO::Atoms. `getAtom` may be called at parse time before `Atoms` is initialized, so a bound checking is needed to keep the hack working. Pull Request: llvm#95341
Hello! Currently, watchpoints don't work on Windows (this can be reproduced with the existing tests). This patch fixes the related issues so that the tests and watchpoints start working. Here is the list of tests that are fixed by this patch (on Windows, checked in **release/18.x** branch): - commands/watchpoints/hello_watchpoint/TestMyFirstWatchpoint.py - commands/watchpoints/multiple_hits/TestMultipleHits.py - commands/watchpoints/multiple_threads/TestWatchpointMultipleThreads.py - commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py - commands/watchpoints/unaligned-watchpoint/TestUnalignedWatchpoint.py - commands/watchpoints/watchpoint_commands/TestWatchpointCommands.py - commands/watchpoints/watchpoint_commands/command/TestWatchpointCommandLLDB.py - commands/watchpoints/watchpoint_commands/command/TestWatchpointCommandPython.py - commands/watchpoints/watchpoint_commands/condition/TestWatchpointConditionCmd.py - commands/watchpoints/watchpoint_count/TestWatchpointCount.py - commands/watchpoints/watchpoint_disable/TestWatchpointDisable.py - commands/watchpoints/watchpoint_size/TestWatchpointSizes.py - python_api/watchpoint/TestSetWatchpoint.py - python_api/watchpoint/TestWatchpointIgnoreCount.py - python_api/watchpoint/TestWatchpointIter.py - python_api/watchpoint/condition/TestWatchpointConditionAPI.py - python_api/watchpoint/watchlocation/TestTargetWatchAddress.py --------- Co-authored-by: Jason Molenda <jmolenda@apple.com>
Some of the freelist code uses type punning which is UB in C++, namely because we read from a union member that is not the active union member.
Print .altinstructions parsing stats only once.
…Axis (llvm#95059) In unsplitLastAxisInResharding, wrong argument was passed when calling targetShardingInUnsplitLastAxis.There weren't any tests to uncover this. I added one in mesh-spmdization.mlir for Linalg and one in resharding-spmdization.mlir for Mesh dialects.
llvm#95481) My recent change that distinguishes pass-by-reference from pass-by-value reduction operation functions missed the "CppReduceComplex" cases, and also broke the shared library build-bots. Fix.
Use the packaging [1] module for parsing version numbers, instead of pkg_resources which is distributed with setuptools. I recently switched over to using the latter, knowing it was deprecated (in favor of the packaging module) because it comes with Python out of the box. Newer versions of setuptools have removed `pkg_resources` so we have to use packaging. [1] https://pypi.org/project/packaging/
This was reverted in llvm#95435 because it broke Android static hwasan binaries. This reland limits the change to !SANITIZER_ANDROID. Original commit message: When set to non-zero, the HWASan runtime will map the shadow base at the specified constant address. This is particularly useful in conjunction with the existing compiler option 'hwasan-mapping-offset', which bakes a hardcoded constant address into the instrumentation. --------- Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>
…60 (llvm#94004) lowerInvokeable wasn't updating the returned chain after emitting the lowerEndEH, which caused SwiftErrorVal-handling code to re-set the DAG root, and thus accidentally skip the EH_LABEL node it was supposed to have addeed. After fixing that, a few places needed to be adjusted that assume the specific shape of the returned DAG. Fixes: llvm#64826 Fixes: rdar://113994760
…lvm#95504) Global with initial value were missing the CUDA data attribute.
…FC) (llvm#95334) Commit 8306968 deleted file `compiler-rt/lib/memprof/memprof_meminfoblock.h`, but didn't remove it from MEMPROF_HEADERS in `compiler-rt/lib/memprof/CMakeLists.txt`. Remove unneeded leftover line in `compiler-rt/lib/memprof/CMakeLists.txt`. p.s. GH llvm#54777 reported a llvm14 build failure due to the existence of the leftover line, but I'm unable to reproduce the build failure with llvm19 trunk.
In HLSL we really want to be using the HLSL vector template and other built-in sugared spellings for some builtin types. This updates the type printer to take an option to use HLSL type spellings. This changes printing vector type names from: ``` T __attribute__((ext_vector_type(N))) ``` To: ``` vector<T, N> ```
…#94515) VarDecl::isNull() doesn't tell whether the VarDecl has an initializer as methods like ensureEvaluatedStmt can create an EvaluatedStmt even when there isn't an initializer. Revert e1c3e16 as the change isn't needed anymore with this change. See the discussion in llvm#93749.
When I filed LWG4110 after the discussion in llvm#93071, I thought it was going to be a straightforward fix. It turns out that it isn't, so we should stay in the state where libc++ is Standards conforming even if that state leads to some reasonable code being rejected by the library. Once WG21 figures out what to do with this issue and votes on it, we'll implement it through our normal means. This reverts f638f7b and 16f2aa1.
While we copy the asset files, like index.js, into the correct location in the install step, tests do not have access to those resources in the build directory. This patch copies the contents of the clang-doc/assets directory into the build folder, so that they can be used in testing. Pull Request: llvm#95185
… constructors (llvm#93071) This reverts commit d868f09, which was shown to break some code and we don't know yet whether the code should be valid or not. Reverting until we've had time to figure it out next week.
Keep track of the Fortran procedure attributes on the func operation.
…vailable" (llvm#95574) Reverts llvm#92142 For now sending this to run on CI
Avoid copying the Python interpreter when running in a virtual environment as it will already have its own copy of the Python interpreter. Also leave a breadcrumb that we're running with a different Python interpreter.
This refactors some of the FreeListHeap, FreeList, and Block classes to have constexpr ctors so we can constinit a global allocator that does not require running some global function or global ctor to initialize. This is needed to prevent worrying about initialization order and any other module-ctor can invoke malloc without worry.
The previous check was false when compiling with `clang++`, which prevented `ntdll` from being specified as a link library, causing an undefined symbol error when trying to resolve `RtlGetLastNtStatus`. Since we always want to link these libraries on Windows, the check can be simplified to just `if( WIN32 )`.
At least on my Windows machine, these two tests fail due to not being able to look up `??3@YAXPEAX_K@Z` (which is `void __cdecl operator delete(void *, unsigned __int64)` in demangled) after 130e93c. Since they don't test anything related to sized deallocation, just disable sized allocation for them. Possibly fixes llvm#95451.
This test is explicitly checking for dwarf 4 behavior on Apple platforms, so we should explicitly use the dwarf4 flag. Related to llvm#95164
Match TAPI behavior and allow input headers to be resolved via a passed directory, which is expected to be a library sitting in a build directory.
Never opening `namespace std` avoids even the possibility of introducing new symbols as well as making the code a bit shorter by removing unnecessary boiler plate.
The putchar header was including the public stdio.h. It doesn't need to do that and it was causing build failures for downstream baremetal users so this patch fixes it.
Add the LIBC_INLINE annotation to all the functions in blockstore.
cferry-AMD
approved these changes
Sep 12, 2024
An error occurred while trying to automatically change base from
bump_to_e3872996
to
feature/fused-ops
September 13, 2024 06:28
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.