summaryrefslogtreecommitdiffstats
path: root/sync.profile
Commit message (Expand)AuthorAgeFilesLines
* Modernize and update to latest CMake APIUlf Hermann2021-06-111-0/+1
* Remove references to multimedia and xmlpatternsLars Knoll2021-06-071-2/+0
* add missing repo dependenciesOswald Buddenhagen2016-02-011-0/+2
* Fix sync.profile dependency versioningv1.2.2Simon Hausmann2016-01-251-2/+2
* Depend directly on 5.6 branchJędrzej Nowacki2015-10-161-2/+2
* Module renamedTomi Korpipää2013-09-101-1/+1
* Added datavis3d back under srcHeikkinen Miikka2013-05-171-1/+1
* Directory structure reorganizedTomi Korpipää2013-05-081-1/+1
* Initial version of QtDataVis3DTomi Korpipää2013-03-071-0/+15
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-25 11:52:55 +0000
ream/revert-87987-win32-elf Vendor branches of https://github.com/llvm/llvm-project.git
summaryrefslogtreecommitdiffstats
path: root/llvm/test/Assembler
Commit message (Collapse)AuthorAgeFilesLines
* [WebAssembly] Add auto-upgrade for renamed intrinsicsNikita Popov2023-03-231-0/+53
| | | | | | | | | D138249 renamed a number of wasm intrinsics without implementing auto-upgrade support. Differential Revision: https://reviews.llvm.org/D146424 (cherry picked from commit 6fc670e5e370e90759b5adecd9980b63609dc2f8)
* IR: Add atomicrmw uinc_wrap and udec_wrapMatt Arsenault2023-01-241-0/+11
| | | | | | | | | | These are essentially add/sub 1 with a clamping value. AMDGPU has instructions for these. CUDA/HIP expose these as atomicInc/atomicDec. Currently we use target intrinsics for these, but those do no carry the ordering and syncscope. Add these to atomicrmw so we can carry these and benefit from the regular legalization processes.
* [LangRef] Require i8s to be naturally alignedJannik Silvanus2023-01-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | It is widely assumed that i8 is naturally aligned (i8:8), and that hence i8s can be used to access arbitrary bytes. As discussed in https://discourse.llvm.org/t/status-of-overaligned-i8, this patch makes this assumption explicit, by documenting it in the LangRef, and enforcing it when parsing a data layout string. Historically, there have been data layouts that violate this requirement, notably the old DXIL data layout that aligns i8 to 32 bits. A previous patch (df1a74a) enabled importing modules with invalid data layouts using override callbacks. Users who wish to continue importing modules with overaligned i8s (e.g. DXIL) thus need to provide a data layout override callback that fixes the data layout, at minimum by setting natural alignment for i8. Any further adjustments to the module (e.g. adding padding bytes if necessary) need to be done after module import. In the case of DXIL, this should not be necessary, because i8 usage in DXIL is very limited and its alignment actually does not matter, see https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#primitive-types Differential Revision: https://reviews.llvm.org/D142211
* [IR] Support importing modules with invalid data layouts.Jannik Silvanus2023-01-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the existing mechanism to change the data layout using callbacks. Before this patch, we had a callback type DataLayoutCallbackTy that receives a single StringRef specifying the target triple, and optionally returns the data layout string to be used. Module loaders (both IR and BC) then apply the callback to potentially override the module's data layout, after first having imported and parsed the data layout from the file. We can't do the same to fix invalid data layouts, because the import will already fail, before the callback has a chance to fix it. Instead, module loaders now tentatively parse the data layout into a string, wait until the target triple has been parsed, apply the override callback to the imported string and only then parse the tentative string as a data layout. Moreover, add the old data layout string S as second argument to the callback, in addition to the already existing target triple argument. S is either the default data layout string in case none is specified, or the data layout string specified in the module, possibly after auto-upgrades (for the BitcodeReader). This allows callbacks to inspect the old data layout string, and fix it instead of setting a fixed data layout. Also allow to pass data layout override callbacks to lazy bitcode module loader functions. Differential Revision: https://reviews.llvm.org/D140985
* [ConstantFold] Don't drop zero index gep with inrange attributeNikita Popov2023-01-061-3/+3
| | | | | | | This may cause GlobalSplit to fail if opaque pointers are used. inrange really needs a new representation, but for now restore the pre-opaque pointers status.
* [IR] Add a target extension type to LLVM.Joshua Cranmer2022-12-205-0/+73
| | | | | | | | | | | | Target-extension types represent types that need to be preserved through optimization, but otherwise are not introspectable by target-independent optimizations. This patch doesn't add any uses of these types by an existing backend, it only provides basic infrastructure such that these types would work correctly. Reviewed By: nikic, barannikov88 Differential Revision: https://reviews.llvm.org/D135202
* [Assembler] Convert tests to opaque pointers (NFC)Nikita Popov2022-12-13171-879/+848
| | | | | Some tests are removed because the error conditions can no longer occur with opaque pointers.
* [AsmWriter] Fix printing of atomicrmw xchg with pointer opNikita Popov2022-12-131-0/+8
| | | | | | atomicrmw always needs to print all types, even if the xchg value type happens to be the same as the pointer operand type. This couldn't occur prior to opaque pointers.
* [AsmParser] Check that addrspace fits within 24 bitsLuke Lau2022-12-091-0/+8
| | | | | | | | Address spaces equal or larger than 1 << 24 don't fit and produce an assertion during debug builds, or worse in release. This causes an error to be reported during parsing instead. Differential Revision: https://reviews.llvm.org/D139528
* [LLParser] Support symbolic address space numbersAlex Richardson2022-12-081-0/+73
| | | | | | | | | | | | | | | | | This allows the LLParser to also accept "A", "G", and "P" in `addrspace` usages. "A" will be replaced by the alloca address space defined in the globals, "G" by the default globals address space and "P" by the program address space. This makes it easier to write tests that use different address space and only only vary the RUN: lines. Currently, the only alternative is to pre-process the sources with a tool such as `sed` Importantly, these new string values are only accepted in .ll files and not stored in the bitcode format, so it does not round-trip via llvm-as and llvm-dis (see newly added test). Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D138789
* Overload all llvm.annotation intrinsics for globals argumentAlex Richardson2022-12-071-1/+1
| | | | | | | | | | The global constant arguments could be in a different address space than the first argument, so we have to add another overloaded argument. This patch was originally made for CHERI LLVM (where globals can be in address space 200), but it also appears to be useful for in-tree targets as can be seen from the test diffs. Differential Revision: https://reviews.llvm.org/D138722