PR for tstellar/llvm-project#856 #857
Closed
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
tstellar
force-pushed
the
release/14.x
branch
5 times, most recently
from
2f5ccde
to
842e936
Compare
tstellar
force-pushed
the
main
branch
2 times, most recently
from
2fbfaf9
to
ccb58e1
Compare
tstellar
force-pushed
the
main
branch
10 times, most recently
from
bc9b8fb
to
3d8bbc8
Compare
tstellar
force-pushed
the
main
branch
2 times, most recently
from
d3382b7
to
4b5ec5b
Compare
tstellar
force-pushed
the
main
branch
4 times, most recently
from
d845a5e
to
250ae95
Compare
The first change is the clarification of rewrite-based semantics, and the fact that when doing the rewrite, all of the instructions involved need to have the rewrite. This is not a change in semantics: there is wide agreement that this behavior is true for most flags. But it is necessary to clarify this, and also clarify that there is a fundamental difference between a flag like `nnan` and a flag like `contract`. Note that several InstCombine transforms do not correctly check this behavior at the moment. The second change is a specific clarification of the rewrites performed by arcp. These rewrites capture what is necessary to enable the transformations that currently require just arcp, none of which are using the flag incorrectly right now.
The codegen for non-inlined version is "quite ugly" as it emits some checks to make sure the initialization routine is properly executed because the compiler does not see how the TLS object is initialized. This leads to some `callq 0x0` junk in the final outputs. For codegen details, see https://godbolt.org/z/rb5qYj3vY.
This is convenient when operating on vectors in a bulk, bit-manipulating fashion. I plan to use this in a future change.
llvm#100443) In llvm#98403 I enabled the SBSaveCoreOptions object, which allows users via the scripting API to define what they want saved into their core file. As the first option I've added a threadlist, so users can scan and identify which threads and corresponding stacks they want to save. In order to support this, I had to add a new method to `Process.h` on how we identify which threads are to be saved, and I had to change the book keeping in minidump to ensure we don't double save the stacks. Important to @jasonmolenda I also changed the MachO coredump to accept these new APIs.
Prevously, if INT_MIN was passed as a wildcard width to a printf conversion the parser would attempt to negate it to get the positive width (and set the left justify flag), but it would underflow and the width would be treated as 0. This patch corrects the issue by instead treating a width of INT_MIN as identical to -INT_MAX. Also includes docs changes to explain this behavior and adding b to the list of int conversions.
This patch set the `allocator_idx` attribute for allocatable descriptor that have specific CUDA attribute.
…header." (llvm#101752) Reverts llvm#100837 The test Modules/builtin-vararg.c is failing on AArch64 build bots: - https://lab.llvm.org/buildbot/#/builders/190/builds/3117 - https://lab.llvm.org/buildbot/#/builders/65/builds/2302 - https://lab.llvm.org/buildbot/#/builders/154/builds/2288 Revert to get the bots back to green.
…angExpressionParser constructor (llvm#101669) We plan to eventually use the Clang driver to initialize the `CompilerInstance`. This should make refactorings of this code more straightforward. **Changes**: * Introduced `SetupLangOpts` and `SetupImportStdModuleLangOpts` * Called them from `ClangExpressionParser::ClangExpressionParser`
This reverts commit 92fbc96. The patch also affected ARM and caused an assertion failure during CurDAG->Legalize (llvm#100723 (comment)).
Due to the slightly non-standard interface that returns a pointer rather than just an integer, the __syscall() utility cannot be used on all architectures. This change is required for example to use the sanitizers on Arm Morello. Pull Request: llvm#84438
This syncs the list of supported sanitizers with the matching code in clang (`FreeBSD::getSupportedSanitizers()`), Reviewed By: emaste, DimitryAndric Pull Request: llvm#84280
llvm.module.flag => llvm.module.flags
This PR has following changes/fixes to XeGPU definition: - Fix type print format for atomic_rmw - removed 2D support for MaskType - Update LoadNd definition - Add 1D TensorDesc support - Replaced vnni_axis attribute with packed attribute - Update DPAS op definition, limiting A to 2D vector, and B to either 2D/3D vector.
This adjusts the DXILOpBuilder API in a couple of ways: 1. Remove the need to call `getOverloadTy` before creating Ops 2. Introduce `tryCreateOp` to parallel `createOp` but propagate errors 3. Introduce specialized createOp methods for each DXIL Op This will simplify usage of the builder in upcoming changes, and also allows us to propagate errors via DiagnosticInfo rather than using fatal errors. Pull Request: llvm#101250
…header. (llvm#100837)" Fix the false warning > incompatible pointer types passing 'va_list' (aka '__builtin_va_list') to parameter of type 'struct __va_list_tag *' [-Wincompatible-pointer-types] The warning is wrong because both in the function declaration and at the call site we are using `va_list`. When we call `ASTContext::getBuiltinVaListDecl` at a specific moment, we end up re-entering this function which causes creating 2 instances of `BuiltinVaListDecl` and 2 instances of `VaListTagDecl` but the stored instances are unrelated to each other because of the call sequence like getBuiltinVaListDecl CreateX86_64ABIBuiltinVaListDecl VaListTagDecl = TagA indirectly call getBuiltinVaListDecl CreateX86_64ABIBuiltinVaListDecl VaListTagDecl = TagB BuiltinVaListDecl = ListB BuiltinVaListDecl = ListA Now we have `BuiltinVaListDecl == ListA` and `VaListTagDecl == TagB`. For x86_64 '__builtin_va_list' and 'struct __va_list_tag *' are compatible because '__builtin_va_list' == '__va_list_tag[1]'. But because we have unrelated decls for VaListDecl and VaListTagDecl the types are considered incompatible as we are comparing type pointers. Fix the error by creating `BuiltinVaListDecl` before `ASTReader::InitializeSema`, so that during `ASTContext::getBuiltinVaListDecl` ASTReader doesn't try to de-serialize '__builtin_va_list' and to call `ASTContext::getBuiltinVaListDecl` again. Reland with the requirement to have x86 target to avoid errors like > error: unable to create target: 'No available targets are compatible with triple "x86_64-apple-darwin"' rdar://130947515
…tor (llvm#100952)" This reverts commit ab819d7.
If there is a type T which can be converted to both float and double etc but itself is not specialized for __numeric_type, and it is called for math functions eg. fma, it will cause ambiguity with test function of __numeric_type. Since test is not template, this error is not bypassed by SFINAE. This is a design flaw of __numeric_type. This patch fixes clang wrapper header to use SFINAE to avoid such ambiguity. Fixes: SWDEV-461604 Fixes: llvm#101239
This pull request was closed.
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.
resolves #856