fix: stop using hex display when printElementsAttrWithHexIfLarger is … #2
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
Didn't fail locally for some reason with my gcc toolchain.
The result of DWARFFormValue::isFormClass depends on DWARF version in some cases. The current implementation takes DWARF version from the stored DWARFUnit. If there is no stored DWARFUnit then the current behavior is to assume DwarfVersion <= 3. This patch adds new function which has a DWARF version as a parameter so it is possible to check form class for various DWARF versions. Differential Revision: https://reviews.llvm.org/D145499
We don't configure this way and don't intend to.
Precommit test for D145155 Reviewed By: reames Differential Revision: https://reviews.llvm.org/D145697
In the calculation of derived type component byte sizes, ensure that CLASS(*) unlimited polymorphic components have space allocated for their addenda. Differential Revision: https://reviews.llvm.org/D145248
The predicate used to determine whether the initial "dtv" argument to a user-defined derived type I/O procedure specified by a generic interface that is not in the derived type definition is wrong. The "dtv" argument must be passed via a descriptor whenever it is polymorphic. Differential Revision: https://reviews.llvm.org/D145255
Reviewed by: ldionne, Mordante Differential Revision: https://reviews.llvm.org/D128084
It also simplifies the implementation of the method. The map is not needed in the check. Reviewed By: chelini Differential Revision: https://reviews.llvm.org/D145522
…llapsed COO tensors. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D145532
Add checks to prevent decomposing constants bigger than 64. relates to llvm/llvm-project#61127 Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D145677
This change fixes "Pass modifies its input and doesn't report it" error when running SPIRVPrepareFunctions pass with LLVM_ENABLE_EXPENSIVE_CHECKS enabled. Differential Revision: https://reviews.llvm.org/D145121
The Mach-O file format uses 32-bit values to encodes offsets which they cannot exceed UIN32_MAX (4GB). The Mach-O file itself can be larger than 4GB as long as none of the offsets fall within this limit. For universal binaries, dsymutil determines if the offset is going to exceed the 4GB limit by computing the size of the header and adding it to the size of all the slices. This is incorrect because it computes the end offset of the final slice. For the purpose of the 4GB limit, only the starting offset matters. The size of the last slice is irrelevant as long as it itself is a valid Mach-O. rdar://104435018 Differential revision: https://reviews.llvm.org/D145637
Add the same nullptr check to SymbolVendorWasm that was added to SymbolVendorELF.
Reviewed By: lntue Differential Revision: https://reviews.llvm.org/D145633
Add functions to set the verifier, printer, and parser of dynamic attributes definitions, and dynamic type definitions. This feature was already implemented for dynamic operations, but is missing for attributes and types. This is necessary to define attributes and types verifiers that refer to each others in a cyclic way. Differential Revision: https://reviews.llvm.org/D144690
This reverts commit 8cf85a0. This is add back change of "Add map info for dereference pointer." In addition turn off test run on amdgpu, since I don't know the way to reprodue the problem.
Disable the test as Windows (or at least the bot) doesn't have 'strip': 'strip' is not recognized as an internal or external command
The memprof profiles and binaries need to be updated in case of version updates. This change adds three scripts for llvm-profdata, clang and llvm tests where memprof profiles are used as inputs. Also update the tests, profiles and binaries in this change. Change based on the review suggestions in D145023. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D145644
This pattern is not specific to nvgpu; I intend to use in SPIR-V codegen. `VectorTransforms` seems like a more generally useful place. In addition: - Fix a bug in the second condition (the dimensions were swapped for RHS). - Add tests. - Add support for externally provided filter functions, similar to other vector transforms. - Prefer to transpose before zero/sign-extending inputs. Reviewed By: ThomasRaoux Differential Revision: https://reviews.llvm.org/D145638
Add codegen for llvm exp/exp2 elementwise builtin The exp/exp2 elementwise builtins are necessary for HLSL codegen. Tests were added to make sure that the expected errors are encountered when these functions are given inputs of incompatible types. The new builtins are restricted to floating point types only. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D145270
…m ordering Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D145723
…ettingStarted As requested in D145413. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D145714
…rse tensor Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D145728
It's helpful Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D145541
Thin and full LTO modes use different pre-link pipelines compared to regular compilation. This patch adds support for calling those pipelines. This patch closely mimics Clang's implementation with the exception that I changed the codegen option name from `PrepareForLTO` to `PrepareForFullLTO` to be more precise. With this patch: - Compilation for full LTO should be as we expect (except possibly missing optimizations enabled by module summaries which we do not produce yet). - thinLTO uses the correct prelink pipeline but will use the postlink backend for fullLTO due to missing metadata and summary in the llvm module. I have added a warning regarding this: `flang-new: warning: the option '-flto=thin' is a work in progress`. Differential Revision: https://reviews.llvm.org/D142420 Change-Id: I6b94b775b5b8e93340e520c5cd4bf60834b2e209
asan+lsan We should follow suite with how asan handles this now that lsan also works with hwasan. Differential Revision: https://reviews.llvm.org/D145613
Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D145621
DO NOT SUBMIT YET, test exposes bug Reviewed By: Peiming Differential Revision: https://reviews.llvm.org/D145708
Simplify the use of the basic_string and basic_string_view types by providing default template arguments. Depends on D145311 Reviewed By: PiotrZSL Differential Revision: https://reviews.llvm.org/D145724
…mbol MD Post ISel, LDS variables are absolute values. Representing them as such is simpler than the frame recalculation currently used to build assembler tables from their addresses. This is a precursor to lowering dynamic/external LDS accesses from non-kernel functions. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D144221
…old. NFC. Preliminary cleanup before adding some additional legality and value tracking handling.
Differential Revision: https://reviews.llvm.org/D145875
These implementations both match the TargetLoweringBase.isZExtFree implementation
D102894 introduced common code for the emission of ELF attributes. Our implementation in RISC-V predates this, and basically copies the Arm logic at the time. This patch removes that duplication and uses the shared logic instead. Differential Revision: https://reviews.llvm.org/D145570
…natures that don't have MemBytes. D145471 added overrides of the other signature to return MemBytes, but shouldn't have removed these overrides. These signatures will now call the MemBytes signature and ignore the MemBytes. This matches X86.
Warn when an rvalue reference function paramter is never moved from within the function body. Reviewed By: carlosgalvezp Differential Revision: https://reviews.llvm.org/D141569
…rwin OS This change generalizes the OS version macro for all darwin OSes. The OS-specific OS version macros are still defined to preserve compatibility.
We fail to use fli.h for the 2 denormal values. We use fli.d for some values where the value is larger than a float can represent due to truncating the exponent to 8 bits without checking if it fits in 8 bits.
Use separate lookup tables instead of trying to reuse the fli.s table. We were missing the 2 denormal cases for fli.h. We also had an issue where fli.d was only checking 8 bits of the 11 bit exponent.
This patch precommits tests for: llvm/llvm-project#60802 llvm/llvm-project#61183 which are about std::bit_ceil and std::bit_floor, respectively.
This patch simplify the parent component handling when it's the last ref. The first field is not necessary when the target box type is set correctly. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D145795
… hoisting barrier
Linalg named operations are currently limited to tensors and memrefs
composed of floating point, integer or complex elements and using any
other element type triggers an assertion.
This change adds support for arbitrary element types through the
specification of the arithmetic operations associated to a type in
specific attributes of a linalg named operation. The attributes' names
correspond to the short form of the arithmetic operator implemented by
the operation (i.e., add, sub, mul, max_signed, max_unsigned,
min_signed, min_unsigned, exp, abs, ceil, negf or log) and receive as
values the name of an operation and optionally a return type given
after a colon.
For example, a `linalg.matmul` operation multiplying two tensors
composed of in would be expressed as:
linalg.matmul { add = "complex.add", mul = "complex.mul" }
ins(%arg1, %arg2 : tensor<?x?xcomplex<f32>>, tensor<?x?xcomplex<f32>>)
outs(%2 : tensor<?x?xcomplex<f32>>)
Sensible default values for the attributes are given for float,
integer and complex types, such that the omission of the attributes
results in the original behavior of the named operation before this
change. I.e., the expression:
linalg.matmul { add = "arith.addf", mul = "arith.mulf" }
ins(%arg1, %arg2 : tensor<?x?xf32>, tensor<?x?xf32>)
outs(%2 : tensor<?x?xf32>)
and:
linalg.matmul
ins(%arg1, %arg2 : tensor<?x?xf32>, tensor<?x?xf32>)
outs(%2 : tensor<?x?xf32>)
yield identical results.
By default, the result type of an operation implementing an arithmetic
operator is assumed to be identical with the type of the first
argument. If this assumption does not hold for an operation, the
result type must be specified explicitly, e.g.,
linalg.matmul { add = "custom_add_op:restypeadd",
mul = "custom_mul_op:restypemul" }
ins(%arg1, %arg2 : tensor<?x?xcomplex<f32>>, tensor<?x?xcomplex<f32>>)
outs(%2 : tensor<?x?xcomplex<f32>>)
The extraction of operation names and result types from attributes,
proper instantiation and default values are provided by a set of
operation interfaces (one per operator) in
`LinalgFrontendInterfaces.td`. The set of operation interfaces
required for a named operation is derived transparently from the
arithmetic expressions in its YAML specification via
`mlir-linalg-ods-yaml-gen`.
umut-sahin
approved these changes
Sep 8, 2023
BourgerieQuentin
requested changes
Sep 13, 2023
I have not seen one. But this hard coded default value is making our MLIR not easy to read and probably bigger than needed. @andidr @antoniupop Is it possible to the llvm AsmPrinterOptions from the Concrete Compiler ? |
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.
…not set