[mlir][llvm] Port overflowFlags to a native operation property
#1
Conversation
This file contains hidden or 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
…educe.{fmin,fmax,fmaximum,fminimum}`; NFC
…ce.{fmin,fmax,fmaximum,fminimum}`
Closes llvm#88408
Fix a use of inline code markup to have a non-word character after the ending delimiter as required by reST.
libc.incude.fenv -> libc.include.fenv
…iles (llvm#88994) followed the same style used in "TensorOps.td".
…e backend. (llvm#88954) This is largely a revert of commit e817966. As llvm#88029 shows, there exists hardware that only supports unaligned scalar. I'm leaving how this gets exposed to the clang interface to a future patch.
The previous patch was reverted because the test fails to build when libsanitizers is not present. This patch catches the BuildError exception and skips the test appropriately. This patch tests LLDB integration with libsanitizers for ASan. rdar://111856681
- With the memory operand as the destination, 'mr' variants of CFCMOV works like STORE and their memory operands should be input operands instead of output ones. Reviewers: XinWang10, arsenm Pull Request: llvm#88970
This change updates a few of the transformations in foldFMulReassoc to respect absent fast-math flags in cases where fmul and fdiv, fadd, or fsub instructions were being folded but the code was only checking for fast-math flags on the fmul instruction and was transferring flags to the folded instruction that were not present on the other original instructions. This fixes llvm#82857
llvm#88249) …se of tensor pack When the vector sizes are not passed as inputs to the vector transform operation, the vector sizes are queried from the static result shape in the case of tensor.pack op.
Since 97fe519, in ARM64EC mode, we don't define `__aarch64__`. Fix various preprocessor guards to account for this.
This reverts commit 7d4e8c1. Contrary to the commit description, this does cause large compile-time regressions (up to 10% on individual files).
- Those special register stores are STORE and their memory operands are input operands instead of output ones. Reviewers: JDevlieghere, arsenm, yinying-lisa-li, koachan, PeimingLiu, jyknight, aartbik, matthias-springer Reviewed By: arsenm Pull Request: llvm#88971
- If a def operand includes multiple sub-operands, count them when generating instr info. - Found issues in x86 and sparc backends, where memory operands of store or store-like instructions are wrongly placed in the output list. Reviewers: jayfoad, arsenm, Pierre-vh Reviewed By: arsenm Pull Request: llvm#88972
…h" (llvm#89006) Reverts llvm#88546 Leak and performance regression. Details in llvm#88546
RFC: https://discourse.llvm.org/t/rfc-introduce-new-clang-builtin-builtin-allow-runtime-check/78281 --------- Co-authored-by: Noah Goldstein <[email protected]> Co-authored-by: Aaron Ballman <[email protected]>
getFileOffsetFor() was replaced with getFileOffsetForAddress().
RewriteInstance::isKSymtabSection() is deprecated.
…ference (llvm#88843) Reapply for llvm#88765. Partially fixes: llvm#60895.
The VTYPE operands of a vsetvli pseudo are always immediates
…6811) Currently the CFI offset for RVV registers are not handled entirely, this patch add those information for either stack unwinding or debugger to work correctly on RVV callee-saved stack object. Depends On D154576 Differential Revision: https://reviews.llvm.org/D156846
The `clang-scan-deps` tool can be used for fast scanning of batches of compilation commands passed in via the `-compilation-database` option. This gets awkward in our tests where we have to resort to using `.in`/`.template` JSON files and running them through `sed` in order to embed LIT's `%t` variable into them. However, most of our tests only need to pass single compilation command, so this dance is entirely unnecessary. This patch makes sure the existing "per-file" mode (where the compilation command is passed in-line after the `--` argument) works for all output formats, not only `P1689`.
This makes it possible to pass "-o /dev/null" to `clang-scan-deps` and skip some potentially expensive work, making timings less noisy. Also removes the need for stream redirection.
llvm::SmallVector::operator== exactly meets our needs.
…89001) Instead of searching all encodings, we can convert the encoding back to a register and use getMatchingSuperReg.
Per [tab:time.format.spec]
%z The offset from UTC as specified in ISO 8601-1:2019, subclause
5.3.4.1. For example -0430 refers to 4 hours 30 minutes behind UTC.
If the offset is zero, +0000 is used. The modified commands %Ez and
%Oz insert a : between the hours and minutes: -04:30. If the offset
information is not available, an exception of type format_error is
thrown.
Typically the modified versions Oz or Ez would have wording like
The modified command %OS produces the locale's alternative
representation.
In this case the modified version does not depend on the locale.
This change is a preparation for formatting sys_info which has time zone
information. The function time_put<_CharT>::put() does not have proper
time zone support, therefore it's a manual implementation.
Fixes llvm#78184
Building ASTs with compile flags that are incompatible to the ones used for the Preamble are not really supported by clang and can trigger crashes. In an ideal world, we should be re-using not only TargetOpts, but the full ParseInputs from the Preamble to prevent such failures. Unfortunately current contracts of ThreadSafeFS makes this a non-safe change for certain implementations. As there are no guarantees that the same ThreadSafeFS is going to be valid in the Context::current() we're building the AST in.
The usage of IsEABI was only valid for RV32E. For RV64E, the stack
adjust
base needs to be 32 when ra,s0-s1 are being saved. Since it takes more
than 16 bytes to save 3 64-bit registers.
The spec lists the rv32e behavior explicitly, but not rv64e. My
assumption is that the only thing that changes with rv64e is which
registers can be used in the register list, but not how the register
list affects the stack_adj_base.
Some FS implementations rely on snapshots available in the context.
This was copy-paste from the identical add test, and didn't change to test the or from the name.
If lldb finds the dynamic linker in the search path or if the binary is linked staticlly, it will fail at `lldbutil.run_break_set_by_symbol` because the breakpoint is resolved. Otherwise, it's not resolved at this point. But we don't care if it's resolved or not. This test cares about if the breakpoint is hit or not after launching. This changes the num_expected_locations to -2, which means don't assert on if this breakpoint resolved or not.
…singleuse_vdst instructions. (llvm#88520) Both single use producer and consumer instructions using wide/sub registers are now correctly tracked and eligible for being marked as single use.
This adds the local_info type and its formatting options. The usage of the local_info object will be done in separate patches. Implements parts of: - P0355 Extending to Calendars and Time Zones - P1361 Integration of chrono with text formatting
…CARRY with carry in larger than setcc result type. (llvm#89121) In the attach test case we were creating a UADDO_CARRY with i1 carry out and i41 carry in. i41 exceeds is larger than the setcc result type for AArch64 which is i32. i41 needs to be promoted to i64 since it is larger than i32. The type legalizer tried to use promoteTargetBoolean, but that can only promote from a type smaller than setcc result type. The easiest fix here is to force the carryin type to match the carryout type at the type of creation. This should ensure the node won't exceeed setcc result type as long as the output type doesn't. I think we should explore requiring the types to match for this node. Fixes llvm#88966
Once llvm#89115 has landed, we can handle per-element shifts as well using (V)GF2P8MULB
Once llvm#89115 has landed, we can handle per-element rotates as well using (V)GF2P8MULB
…ld. (llvm#87822)" This reverts commit 9202984.
There are users reporting saving minidump from lldb-dap does not work. Turns out our stack trace request always evaluate a function call which caused JIT object file like "__lldb_caller_function" to be created which can fail minidump builder to get its module size. This patch fixes "getModuleFileSize" for ObjectFileJIT so that module list can be saved. I decided to create a lldb-dap test so that this end-to-end functionality can be validated from our tests (instead of only command line lldb). The patch also improves several other small things in the workflow: 1. It logs any minidump stream failure so that it is easier to find out what stream saving fails. In future, we should show process and error to end users. 2. It handles error from "getModuleFileSize" llvm::Expected<T> otherwise it will complain the error is not handled. --------- Co-authored-by: jeffreytan81 <[email protected]>
…7316) The pull request includes the following changes. 1. Refactors the interface to `PresburgerSpace::identifiers` to `setId` and a const `getId`, instead of previous `getId` which returned a mutable reference. `resetIds` does not need to be called to use identifiers, `setId` calls `resetIds` if identifiers are not enabled. 2. Deprecates `FlatAffineRelation` by refactoring all usages of `FlatAffineRelation` to `IntegerRelation`. To achieve this, `FlatAffineRelation::compose` is refactored into `IntegerRelation::mergeAndCompose`. 3. Deletes unneeded overrides of virtual functions `hasConsistentState`, `clearAndCopyFrom` and `fourierMotzkinEliminate` from `FlatLinearValueConstraints` as these were only used through `FlatAffineRelation` and we now use `IntegerRelation`'s member functions instead. 4. Fixes an existing bug in FlatLinearValueConstraints' constructor which caused identifiers set by superclass FlatLinearConstraints' constructor to be erased. 5. Fixes `IntegerRelation::convertVarKind` not preserving identifiers.
…es (llvm#88995) This adds some additional bits into a ProcessInfo structure that will be of use in filling structs in an elf core file. This is a demand for implementing process save-core
512-bit GFNI doesn't require AVX512BW
This PR increases accurasy of FFT2D/RFFT2D calculation by removing periodic part of sin/cos
…, being used in signed nodes.
…OMP (llvm#87086) This removes the last use of genOmpObjectList2, which has now been removed. --------- Co-authored-by: Sergio Afonso <[email protected]>
This is useful for defining operation properties that are enums.
This PR changes the LLVM dialect's IntegerOverflowFlags to be stored on operations as native properties.
Mogball
pushed a commit
that referenced
this pull request
May 24, 2024
…vm#90820) This solves some ambuguity introduced in P0522 regarding how template template parameters are partially ordered, and should reduce the negative impact of enabling `-frelaxed-template-template-args` by default. When performing template argument deduction, a template template parameter containing no packs should be more specialized than one that does. Given the following example: ```C++ template<class T2> struct A; template<template<class ...T3s> class TT1, class T4> struct A<TT1<T4>>; // #1 template<template<class T5 > class TT2, class T6> struct A<TT2<T6>>; // llvm#2 template<class T1> struct B; template struct A<B<char>>; ``` Prior to P0522, candidate `llvm#2` would be more specialized. After P0522, neither is more specialized, so this becomes ambiguous. With this change, `llvm#2` becomes more specialized again, maintaining compatibility with pre-P0522 implementations. The problem is that in P0522, candidates are at least as specialized when matching packs to fixed-size lists both ways, whereas before, a fixed-size list is more specialized. This patch keeps the original behavior when checking template arguments outside deduction, but restores this aspect of pre-P0522 matching during deduction. --- Since this changes provisional implementation of CWG2398 which has not been released yet, and already contains a changelog entry, we don't provide a changelog entry here.
Mogball
pushed a commit
that referenced
this pull request
May 24, 2024
…llvm#92855) This solves some ambuguity introduced in P0522 regarding how template template parameters are partially ordered, and should reduce the negative impact of enabling `-frelaxed-template-template-args` by default. When performing template argument deduction, we extend the provisional wording introduced in llvm#89807 so it also covers deduction of class templates. Given the following example: ```C++ template <class T1, class T2 = float> struct A; template <class T3> struct B; template <template <class T4> class TT1, class T5> struct B<TT1<T5>>; // #1 template <class T6, class T7> struct B<A<T6, T7>>; // llvm#2 template struct B<A<int>>; ``` Prior to P0522, `llvm#2` was picked. Afterwards, this became ambiguous. This patch restores the pre-P0522 behavior, `llvm#2` is picked again. This has the beneficial side effect of making the following code valid: ```C++ template<class T, class U> struct A {}; A<int, float> v; template<template<class> class TT> void f(TT<int>); // OK: TT picks 'float' as the default argument for the second parameter. void g() { f(v); } ``` --- Since this changes provisional implementation of CWG2398 which has not been released yet, and already contains a changelog entry, we don't provide a changelog entry here.
Mogball
pushed a commit
that referenced
this pull request
May 24, 2024
The problematic program is as follows:
```shell
#define pre_a 0
#define PRE(x) pre_##x
void f(void) {
PRE(a) && 0;
}
int main(void) { return 0; }
```
in which after token concatenation (`##`), there's another nested macro
`pre_a`.
Currently only the outer expansion region will be produced. ([compiler
explorer
link](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:___c,selection:(endColumn:29,endLineNumber:8,positionColumn:29,positionLineNumber:8,selectionStartColumn:29,selectionStartLineNumber:8,startColumn:29,startLineNumber:8),source:'%23define+pre_a+0%0A%23define+PRE(x)+pre_%23%23x%0A%0Avoid+f(void)+%7B%0A++++PRE(a)+%26%26+0%3B%0A%7D%0A%0Aint+main(void)+%7B+return+0%3B+%7D'),l:'5',n:'0',o:'C+source+%231',t:'0')),k:51.69491525423727,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((g:!((h:compiler,i:(compiler:cclang_assertions_trunk,filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'1',trim:'1',verboseDemangling:'0'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:2,lang:___c,libs:!(),options:'-fprofile-instr-generate+-fcoverage-mapping+-fcoverage-mcdc+-Xclang+-dump-coverage-mapping+',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x86-64+clang+(assertions+trunk)+(Editor+%231)',t:'0')),k:34.5741843594503,l:'4',m:28.903654485049834,n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compilerName:'x86-64+clang+(trunk)',editorid:1,fontScale:14,fontUsePx:'0',j:2,wrap:'1'),l:'5',n:'0',o:'Output+of+x86-64+clang+(assertions+trunk)+(Compiler+%232)',t:'0')),header:(),l:'4',m:71.09634551495017,n:'0',o:'',s:0,t:'0')),k:48.30508474576271,l:'3',n:'0',o:'',t:'0')),l:'2',m:100,n:'0',o:'',t:'0')),version:4))
```text
f:
File 0, 4:14 -> 6:2 = #0
Decision,File 0, 5:5 -> 5:16 = M:0, C:2
Expansion,File 0, 5:5 -> 5:8 = #0 (Expanded file = 1)
File 0, 5:15 -> 5:16 = #1
Branch,File 0, 5:15 -> 5:16 = 0, 0 [2,0,0]
File 1, 2:16 -> 2:23 = #0
File 2, 1:15 -> 1:16 = #0
File 2, 1:15 -> 1:16 = #0
Branch,File 2, 1:15 -> 1:16 = 0, 0 [1,2,0]
```
The inner expansion region isn't produced because:
1. In the range-based for loop quoted below, each sloc is processed and
possibly emit a corresponding expansion region.
2. For our sloc in question, its direct parent returned by
`getIncludeOrExpansionLoc()` is a `<scratch space>`, because that's how
`##` is processed.
https://github.com/llvm/llvm-project/blob/88b6186af3908c55b357858eb348b5143f21c289/clang/lib/CodeGen/CoverageMappingGen.cpp#L518-L520
3. This `<scratch space>` cannot be found in the FileID mapping so
`ParentFileID` will be assigned an `std::nullopt`
https://github.com/llvm/llvm-project/blob/88b6186af3908c55b357858eb348b5143f21c289/clang/lib/CodeGen/CoverageMappingGen.cpp#L521-L526
4. As a result this iteration of for loop finishes early and no
expansion region is added for the sloc.
This problem gets worse with MC/DC: as the example shows, there's a
branch from File 2 but File 2 itself is missing. This will trigger
assertion failures.
The fix is more or less a workaround and takes a similar approach as
llvm#89573.
~~Depends on llvm#89573.~~ This includes llvm#89573. Kudos to @chapuni!
This and llvm#89573 together fix llvm#87000: I tested locally, both the reduced
program and my original use case (fwiw, Linux kernel) can run
successfully.
---------
Co-authored-by: NAKAMURA Takumi <[email protected]>
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.
This PR changes the LLVM dialect's IntegerOverflowFlags to be stored on operations as native properties.