- Mar 19, 2021
-
-
Andrei Elovikov authored
I foresee two uses for this: 1) It's easier to use those in debugger. 2) Once we start implementing more VPlan-to-VPlan transformations (especially inner loop massaging stuff), using the vectorized LLVM IR as CHECK targets in LIT test would become too obscure. I can imagine that we'd want to CHECK against VPlan dumps after multiple transformations instead. That would be easier with plain text dumps than with DOT format. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D96628
-
Craig Topper authored
[RISCV] Lower scalable vector masked loads to intrinsics to match fixed vectors and reduce isel patterns. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D98840
-
Fraser Cormack authored
I'm not sure how I failed to notice this before, but when optimizing dominant-element BUILD_VECTORs we would lower via the scalable container type, which lost us the information about the fixed length of the vector types. By lowering via the fixed-length type we can preserve that information and eliminate redundant vsetvli instructions. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D98938
-
Philip Reames authored
-
Fraser Cormack authored
Since the "LMUL-MAX=2" output for some test functions differed between RV32 and RV64, the update_llc_test_checks script failed to emit a unified LMULMAX2 check for them. I'm not sure why it didn't warn about this. This patch also takes the opportunity to add unified RV32/RV64 checks to help shorten the test file when the output for LMULMAX1 and LMULMAX2 is identical but differs between the two ISAs. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D98944
-
Fraser Cormack authored
Returning the scalable-vector container type would present problems when the fixed-length INSERT_VECTOR_ELT was used by later operations. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D98776
-
Martin Storsjö authored
This matches what GCC warns about when -pedantic is enabled. This should avoid such redundant semicolons creeping into the codebase. Differential Revision: https://reviews.llvm.org/D98941
-
Jay Foad authored
-
Jay Foad authored
-
Paul Robinson authored
Count iterations of zero-trip loops and assert the count is zero, rather than asserting inside the loop. Unreachable functions should use llvm_unreachable. Remove tautological 'if' statements, even when they're following a pattern of checks. Found by the Rotten Green Tests project.
-
Simon Pilgrim authored
Reuse the existing KnownBits multiplication code to handle the 'extend + multiply + extract high bits' pattern for multiply-high ops. Noticed while looking at the codegen for D88785 / D98587 - the patch helps division-by-constant expansion code in particular, which suggests that we might have some further KnownBits div/rem cases we could handle - but this was far easier to implement. Differential Revision: https://reviews.llvm.org/D98857
-
Jay Foad authored
Add some atomic optimizer tests where there is no use of the result of the atomic operation, which is a common case in real code. NFC. Differential Revision: https://reviews.llvm.org/D98952
-
Stanislav Mekhanoshin authored
-
Christian Kühnel authored
Installing the Unix tools on Windows is quite painful. To make things easier, I explained how to use a package manager or a Docker image. Note: This still uses the GNUWin tools as explained on this page. Once we replace these with something else, we would also need to update the installation commands. Differential Revision: https://reviews.llvm.org/D97387
-
Simon Pilgrim authored
Followup to D96345, handle unary shuffles of binops (as well as binary shuffles) if we can merge the shuffle with inner operand shuffles. Differential Revision: https://reviews.llvm.org/D98646
-
Paul C. Anagnostopoulos authored
This requires changes to TableGen files and some C++ files due to incompatible multiclass template arguments that slipped through before the improved handling.
-
Ricky Taylor authored
Replace the unknown operand used for immediate operands for DIV/MUL with a fixed 16-bit immediate. This is required since the assembly parser generator requires that all operands are typed. Differential Revision: https://reviews.llvm.org/D98819
-
Jeroen Dobbelaere authored
This patch adds support for intrinsic overloading on unnamed types. This fixes PR38117 and PR48340 and will also be needed for the Full Restrict Patches (D68484). The main problem is that the intrinsic overloading name mangling is using 's_s' for unnamed types. This can result in identical intrinsic mangled names for different function prototypes. This patch changes this by adding a '.XXXXX' to the intrinsic mangled name when at least one of the types is based on an unnamed type, ensuring that we get a unique name. Implementation details: - The mapping is created on demand and kept in Module. - It also checks for existing clashes and recycles potentially existing prototypes and declarations. - Because of extra data in Module, Intrinsic::getName needs an extra Module* argument and, for speed, an optional FunctionType* argument. - I still kept the original two-argument 'Intrinsic::getName' around which keeps the original behavior (providing the base name). -- Main reason is that I did not want to change the LLVMIntrinsicGetName version, as I don't know how acceptable such a change is -- The current situation already has a limitation. So that should not get worse with this patch. - Intrinsic::getDeclaration and the verifier are now using the new version. Other notes: - As far as I see, this should not suffer from stability issues. The count is only added for prototypes depending on at least one anonymous struct - The initial count starts from 0 for each intrinsic mangled name. - In case of name clashes, existing prototypes are remembered and reused when that makes sense. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D91250
-
Nemanja Ivanovic authored
When a D-Form instruction is fed by an add-immediate, we attempt to merge the two immediates to form a single displacement so we can remove the add-immediate. However, we don't check whether the new displacement fits into a 16-bit signed immediate field early enough. Namely, we do a sign-extend from 16 bits first which will discard high bits and then we check whether the result is a 16-bit signed immediate. It of course will always be. Move the check prior to the sign extend to ensure we are checking the correct value. Fixes https://bugs.llvm.org/show_bug.cgi?id=49640
-
Abhina Sreeskantharajan authored
This patch consists of the initial changes to help distinguish between text and binary content correctly on z/OS. I would like to get feedback from Windows users on setting OF_None for all ToolOutputFiles. This seems to have been done as an optimization to prevent CRLF translation on Windows in the past. Reviewed By: zibi Differential Revision: https://reviews.llvm.org/D97785
-
Simonas Kazlauskas authored
This is in preparation of changes in this area (such as D98789 and D98906). Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D98909
-
Ricky Taylor authored
This makes it simpler to determine when two registers are actually the same vs just partially aliasing. The only real caveat is that it becomes impossible to know which name was used for the register previously. (i.e. parsing assembly and then disassembling it can result in the register name changing.) Differential Revision: https://reviews.llvm.org/D98536
-
Ricky Taylor authored
This is required in order to determine during disassembly whether a Reg bead without associated DA bead is referring to a data register. Differential Revision: https://reviews.llvm.org/D98534
-
Jay Foad authored
This is redundant because we have already checked that we can't handle divergent 64-bit atomic operands.
-
Jay Foad authored
-
Jay Foad authored
-
Jay Foad authored
-
Martin Storsjö authored
This reverts commit d09adfd3. That commit caused failures in clang-tidy/infrastructure/validate-check-names.cpp on windows buildbots. That change exposed a surprising issue, not directly related to this change in itself, but in how TestRunner quotes command line arguments that later are going to be interpreted by a msys based tool (like grep.exe, when provided by Git for Windows). This worked accidentally before, when grep was invoked via not.exe which took a more conservative approach to windows argument quoting.
-
Kristof Beyls authored
-
Simon Pilgrim authored
Split off from D98857 https://reviews.llvm.org/D98866
-
Mikael Holmen authored
gcc complained with ../lib/Target/NVPTX/NVPTXLowerArgs.cpp:203:2: warning: extra ';' [-Wpedantic] 203 | }; | ^
-
Clement Courbet authored
In preparation for https://reviews.llvm.org/D98925
-
Martin Storsjö authored
When running in a Windows Container, the Git for Windows Unix tools (C:\Program Files\Git\usr\bin) just hang if this variable isn't passed through. Currently, running the LLVM/clang tests in a Windows Container fails if that directory is added to the path, but succeeds after this change. (After this change, the previously used GnuWin tools can be left out entirely, too, as lit automatically picks up the Git for Windows tools if necessary.) Differential Revision: https://reviews.llvm.org/D98858
-
Martin Storsjö authored
Keep running "not --crash" via the external "not" executable, but for plain negations, and for cases that use the shell "!" operator, just skip that argument and invert the return code. The libcxx tests only use the shell operator "!" for negations, never the "not" executable, because libcxx tests can be run without having a fully built llvm tree available providing the "not" executable. This allows using the internal shell for libcxx tests. Differential Revision: https://reviews.llvm.org/D98859
-
Max Kazantsev authored
-
Max Kazantsev authored
-
Max Kazantsev authored
-
Max Kazantsev authored
-
Fangrui Song authored
-
Max Kazantsev authored
We can prove more predicates when we have a context when eliminating ICmp. As first (and very obvious) approximation we can use the ICmp instruction itself, though in the future we are going to use a common dominator of all its users. Need some refactoring before that. Observed ~0.5% negative compile time impact. Differential Revision: https://reviews.llvm.org/D98697 Reviewed By: lebedev.ri
-