- May 15, 2022
-
-
Nico Weber authored
-
Wende Tan authored
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D106888
-
Sheng authored
This is an example usage of D120958. After these patches are landed, we can strip off the codebeads officially. Reviewed By: myhsu Differential Revision: https://reviews.llvm.org/D120960
-
Sheng authored
The name `MCFixedLenDisassembler.h` is out of date after D120958. Rename it as `MCDecoderOps.h` to reflect the change. Reviewed By: myhsu Differential Revision: https://reviews.llvm.org/D124987
-
Min-Yih Hsu authored
Add support for translating llvm::ShuffleVectorInst Differential Revision: https://reviews.llvm.org/D125030
-
Min-Yih Hsu authored
Add support for translating llvm::InsertValue and llvm::ExtractValue. Differential Revision: https://reviews.llvm.org/D125028
-
Craig Topper authored
ISD::VSCALE only allows constant operands.
-
varconst authored
Quite a few C++20 LWG issues/papers related to the One Ranges Proposal were already effectively implemented (or contain semantic-only wording changes that don't affect the implementation), mark them as such. Differential Revision: https://reviews.llvm.org/D125065
-
Nikolas Klauser authored
This simplifies the string structs a bit more and the normal layout should not contain any undefined behaviour anymore. I don't think there is a way to achieve this in the alternate string mode without breaking the ABI. Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D125496
-
Richard authored
Clang erroneously flagged the function as "unused", but it is most definitely used by gtest to pretty print the parameter value when a test fails. Make the pretty printing function a friend function in the parameter class similar to other clang unit tests.
-
Simon Pilgrim authored
v_cttz_zero_undef_i64_with_select should be selecting '64' for the x != 0 case instead of '32' like we just did in the previous 'v_cttz_zero_undef_i32_with_select' test. Noticed by accident because it was causing some weird regressions.... Differential Revision: https://reviews.llvm.org/D125612
-
Simon Pilgrim authored
Also, initialize entire mask to -1 to simplify undefined cases.
-
Alex Brachet authored
st_size may not be of importance to the abi if you are not using copy relocations. This is helpful when you want to check the abi of a shared object both when instrumented and not because asan will increase the size of objects to include the redzone. Differential revision: https://reviews.llvm.org/D124792
-
Fangrui Song authored
-
Simon Pilgrim authored
SelectionDAG::FoldConstantArithmetic determines if operands are foldable constants, so we don't need to bother with isConstantOrConstantVector / Opaque tests before calling it directly.
-
Alex Brachet authored
This reverts commit b6b0fd6a.
-
Alex Brachet authored
st_size may not be of importance to the abi if you are not using copy relocations. This is helpful when you want to check the abi of a shared object both when instrumented and not because asan will increase the size of objects to include the redzone. Differential revision: https://reviews.llvm.org/D124792
-
Simon Pilgrim authored
-
- May 14, 2022
-
-
Jonas Devlieghere authored
crashlog.py catches every exception in order to format them. This results in both the exception name as well as the backtrace getting swallowed. Here's an example of the current output: error: python exception: in method 'SBTarget_ResolveLoadAddress', argument 2 of type 'lldb::addr_t' Compare this to the output without the custom exception handling: Traceback (most recent call last): File "[...]/site-packages/lldb/macosx/crashlog.py", line 929, in __call__ SymbolicateCrashLogs(debugger, shlex.split(command)) File "[...]/site-packages/lldb/macosx/crashlog.py", line 1239, in SymbolicateCrashLogs SymbolicateCrashLog(crash_log, options) File "[...]/site-packages/lldb/macosx/crashlog.py", line 1006, in SymbolicateCrashLog thread.dump_symbolicated(crash_log, options) File "[...]/site-packages/lldb/macosx/crashlog.py", line 124, in dump_symbolicated symbolicated_frame_addresses = crash_log.symbolicate( File "[...]/site-p... -
Jonas Devlieghere authored
-
Simon Pilgrim authored
-
Alex Richardson authored
Previously, creating a zero floating-point constant used MOVID even when NEON was disabled which resulted in the following fatal error: `Attempting to emit MOVID instruction but the Feature_HasNEON predicate(s) are not met` Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D125237
-
Alex Richardson authored
Variable captures such as `<MCInst #` can change based on unrelated changes to the LLVM backends, to avoid the generated test cases being different use an incrementing counter for variable names instead of using the actual value from the output file. This change may also be beneficial for some nameless IR variables (especially when combined with filtering of output), but for now I've restricted this change to the obvious candidates (--asm-show-inst output). Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D125405
-
Alex Richardson authored
To avoid test churn when backends add/rename new instructions/registers, it makes sense to use FileCheck captures for the exact MCInst/Reg number. This is motivated by D125307, where I use --asm-show-inst to differentiate the output for multiple instructions with the same mnemonic. This does not quite fix the churn issue yet: While files with the generated checks will be immune to the numbers changing, the update script test still suffers from this problem since the number is encoded in the FileCheck variable name. I plan to address this in a follow-up patch. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D125307
-
Alex Richardson authored
To avoid test churn when backends add/rename new instructions/registers, it makes sense to scrub the exact MCInst/Reg number. Differential Revision: https://reviews.llvm.org/D125305
-
Alex Richardson authored
This avoids repeated calls to get_idx_from_ir_value_match() and will make it easier for a future patch that adds new assembly-level nameless values in addition to the IR ones. Differential Revision: https://reviews.llvm.org/D125390
-
Alex Richardson authored
I was trying to compile code with -march=+nosimd and hit various instruction predicate verification errors, this patch should address the ones I saw in integer to floating-pointer conversions. I noticed that for signed conversions, some non-NEON instruction sequences are shorter. I don't know if the longer one is still faster on current architectures (the patterns date back to the initial backend import) Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D125308
-
Alex Richardson authored
Differential Revision: https://reviews.llvm.org/D125240
-
Arnab Dutta authored
Erase gpu.memcpy op when only uses of dest are the memcpy op in question, its allocation and deallocation ops. Reviewed By: bondhugula, csigg Differential Revision: https://reviews.llvm.org/D124257
-
Simon Pilgrim authored
-
Simon Pilgrim authored
SelectionDAG::FoldConstantArithmetic determines if operands are foldable constants, so we don't need to bother with isConstantOrConstantVector / Opaque tests before calling it directly.
-
Simon Pilgrim authored
-
Simon Pilgrim authored
-
Christian Sigg authored
Reviewed By: ThomasRaoux Differential Revision: https://reviews.llvm.org/D125112
-
Simon Pilgrim authored
This is a much more realistic target than just avx512bw, which has never existed as a real world cpu target
-
Mark de Wever authored
This improves the speed of `to_chars` for bases 2, 8, and 16. These bases are common and used in `<format>`. This change uses a lookup table, like done in base 10 and causes an increase in code size. The change has a small overhead for the other bases. ``` Benchmark Time CPU Time Old Time New CPU Old CPU New ------------------------------------------------------------------------------------------------------------------ BM_to_chars_good/2 -0.9476 -0.9476 252 13 252 13 BM_to_chars_good/3 +0.0018 +0.0018 145 145 145 145 BM_to_chars_good/4 +0.0108 +0.0108 104 105 104 105 BM_to_chars_good/5 +0.0159 +0.0160 89 91 89 91 BM_to_chars_good/6 +0.0162 +0.0162 80 81 80 81 BM_to_chars_good/7 +0.0117 +0.0117 72 73 72 73 BM_to_chars_good/8 -0.8643 -0.8643 64 9 64 9 BM_to_chars_good/9 +0.0095 +0.0095 60 60 60 60 BM_to_chars_good/10 +0.0540 +0.0540 6 6 6 6 BM_to_chars_good/11 +0.0299 +0.0299 55 57 55 57 BM_to_chars_good/12 +0.0060 +0.0060 48 49 49 49 BM_to_chars_good/13 +0.0102 +0.0102 48 48 48 48 BM_to_chars_good/14 +0.0184 +0.0185 47 48 47 48 BM_to_chars_good/15 +0.0269 +0.0269 44 45 44 45 BM_to_chars_good/16 -0.8207 -0.8207 37 7 37 7 BM_to_chars_good/17 +0.0241 +0.0241 37 38 37 38 BM_to_chars_good/18 +0.0221 +0.0221 37 38 37 38 BM_to_chars_good/19 +0.0222 +0.0223 37 38 37 38 BM_to_chars_good/20 +0.0317 +0.0317 38 39 38 39 BM_to_chars_good/21 +0.0342 +0.0341 38 39 38 39 BM_to_chars_good/22 +0.0336 +0.0336 36 38 36 38 BM_to_chars_good/23 +0.0222 +0.0222 34 35 34 35 BM_to_chars_good/24 +0.0185 +0.0185 31 32 31 32 BM_to_chars_good/25 +0.0157 +0.0157 32 32 32 32 BM_to_chars_good/26 +0.0181 +0.0181 32 32 32 32 BM_to_chars_good/27 +0.0153 +0.0153 32 32 32 32 BM_to_chars_good/28 +0.0179 +0.0179 32 32 32 32 BM_to_chars_good/29 +0.0189 +0.0189 32 33 32 33 BM_to_chars_good/30 +0.0212 +0.0212 32 33 32 33 BM_to_chars_good/31 +0.0221 +0.0221 32 33 32 33 BM_to_chars_good/32 +0.0292 +0.0292 32 33 32 33 BM_to_chars_good/33 +0.0319 +0.0319 32 33 32 33 BM_to_chars_good/34 +0.0411 +0.0410 33 34 33 34 BM_to_chars_good/35 +0.0515 +0.0515 33 34 33 34 BM_to_chars_good/36 +0.0502 +0.0502 32 34 32 34 BM_to_chars_bad/2 -0.8752 -0.8752 40 5 40 5 BM_to_chars_bad/3 +0.1952 +0.1952 21 26 21 26 BM_to_chars_bad/4 +0.3626 +0.3626 16 22 16 22 BM_to_chars_bad/5 +0.2267 +0.2268 17 21 17 21 BM_to_chars_bad/6 +0.3560 +0.3559 14 19 14 19 BM_to_chars_bad/7 +0.4599 +0.4600 12 18 12 18 BM_to_chars_bad/8 -0.5074 -0.5074 11 5 11 5 BM_to_chars_bad/9 +0.4814 +0.4814 10 15 10 15 BM_to_chars_bad/10 +0.7761 +0.7761 2 4 2 4 BM_to_chars_bad/11 +0.3948 +0.3948 12 16 12 16 BM_to_chars_bad/12 +0.3203 +0.3203 10 13 10 13 BM_to_chars_bad/13 +0.3067 +0.3067 11 14 11 14 BM_to_chars_bad/14 +0.2235 +0.2235 12 14 12 14 BM_to_chars_bad/15 +0.2675 +0.2675 11 14 11 14 BM_to_chars_bad/16 -0.1801 -0.1801 7 5 7 5 BM_to_chars_bad/17 +0.5651 +0.5651 7 11 7 11 BM_to_chars_bad/18 +0.5407 +0.5406 7 11 7 11 BM_to_chars_bad/19 +0.5593 +0.5593 8 12 8 12 BM_to_chars_bad/20 +0.5823 +0.5823 8 13 8 13 BM_to_chars_bad/21 +0.6032 +0.6032 9 15 9 15 BM_to_chars_bad/22 +0.6407 +0.6408 9 14 9 14 BM_to_chars_bad/23 +0.6292 +0.6292 7 12 7 12 BM_to_chars_bad/24 +0.5784 +0.5784 6 10 6 10 BM_to_chars_bad/25 +0.5784 +0.5784 6 10 6 10 BM_to_chars_bad/26 +0.5713 +0.5713 7 10 7 10 BM_to_chars_bad/27 +0.5969 +0.5969 7 11 7 11 BM_to_chars_bad/28 +0.6131 +0.6131 7 11 7 11 BM_to_chars_bad/29 +0.6937 +0.6937 7 11 7 11 BM_to_chars_bad/30 +0.7655 +0.7656 7 12 7 12 BM_to_chars_bad/31 +0.8939 +0.8939 6 12 6 12 BM_to_chars_bad/32 +1.0157 +1.0157 6 13 6 13 BM_to_chars_bad/33 +1.0279 +1.0279 7 14 7 14 BM_to_chars_bad/34 +1.0388 +1.0388 7 14 7 14 BM_to_chars_bad/35 +1.0990 +1.0990 7 15 7 15 BM_to_chars_bad/36 +1.1503 +1.1503 7 15 7 15 ``` Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D97705
-
Simon Pilgrim authored
Also rename X32 check prefixes to X86 as we try to use X32 for gnux32 targets
-
Chris Lattner authored
We want getRaw() on tensors with i1 element type with a zero or 1 value to be treated as a splat. This fixes: https://github.com/llvm/llvm-project/issues/55440
-
Aaron Puchert authored
Precommit builds cover Linux and Windows, but this ambiguity would only show up on Mac OS: there we have int32_t = int, int64_t = long long and size_t = unsigned long. So printing a size_t, while successful on the other two architectures, cannot be unambiguously resolved on Mac OS. This is not really meant to support printing arguments of type long or size_t, but more as a way to prevent build breakage that would not be detected in precommit builds, as happened in D125429. Technically we have no guarantee that one of these types has the 64 bits that afdac5fb wanted to provide, so proposals are welcome. We do have a guarantee though that these three types are different, so we should be fine with overload resolution. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D125580
-
Andrzej Warzynski authored
This patch re-factors the driver code in LLVM Flang (frontend + compiler) to use the MLIR style. For more context, please see: https://discourse.llvm.org/t/rfc-coding-style-in-the-driver/ Most changes here are rather self-explanatory. Accessors are renamed to be more consistent with the rest of LLVM (e.g. allSource --> getAllSources). Additionally, MLIR clang-tidy files are added in the affected directories. clang-tidy and clang-format files were copied from MLIR. Small additional changes are made to silence clang-tidy/clang-format warnings. [1] https://mlir.llvm.org/getting_started/DeveloperGuide/ Differential Revision: https://reviews.llvm.org/D125007
-
