- Jan 21, 2019
-
-
Chandler Carruth authored
all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. llvm-svn: 351731
-
Craig Topper authored
llvm-svn: 351729
-
Max Kazantsev authored
llvm-svn: 351727
-
Max Kazantsev authored
llvm-svn: 351726
-
Max Kazantsev authored
This patch introduces the field `ExpressionSize` in SCEV. This field is calculated only once on SCEV creation, and it represents the complexity of this SCEV from arithmetical point of view (not from the point of the number of actual different SCEV nodes that are used in the expression). Roughly saying, it is the number of operands and operations symbols when we print this SCEV. A formal definition is following: if SCEV `X` has operands `Op1`, `Op2`, ..., `OpN`, then Size(X) = 1 + Size(Op1) + Size(Op2) + ... + Size(OpN). Size of SCEVConstant and SCEVUnknown is one. Expression size may be used as a universal way to limit SCEV transformations for huge SCEVs. Currently, we have a bunch of options that represents various limits (such as recursion depth limit) that may not make any sense from the point of view of a LLVM users who is not familiar with SCEV internals, and all these different options pursue one goal. A more general rule that may potentially allow us to get rid of this redundancy in options is "do not make transformations with SCEVs of huge size". It can apply to all SCEV traversals and transformations that may need to visit a SCEV node more than once, hence they are prone to combinatorial explosions. This patch only introduces SCEV sizes calculation as NFC, its utilization will be introduced in follow-up patches. Differential Revision: https://reviews.llvm.org/D35989 Reviewed By: reames llvm-svn: 351725
-
Kito Cheng authored
Summary: Add R_RISCV_RELAX relocation to all possible relax candidates and update corresponding testcase. Reviewers: asb, apazos Differential Revision: https://reviews.llvm.org/D46677 llvm-svn: 351723
-
Dylan McKay authored
This updates the AVR Select8/Select16 expansion code so that, when inserting the two basic blocks for true and false conditions, any existing fallthrough on the previous block is preserved. Prior to this patch, if the block before the Select pseudo fell through to the subsequent block, two new basic blocks would be inserted at the prior fallthrough point, changing the fallthrough destination. The predecessor or successor lists were not updated, causing the BranchFolding pass at -O1 and above the rearrange basic blocks, causing an infinite loop. Not to mention the unconditional fallthrough to the true block is incorrect in of itself. This patch modifies the Select8/16 expansion so that, if inserting true and false basic blocks at a fallthrough point, the implicit branch is preserved by means of an explicit, unconditional branch to the previous fallthrough destination. Thanks to Carl Peto for reporting this bug. This fixes avr-rust bug https://github.com/avr-rust/rust/issues/123. llvm-svn: 351721
-
Dylan McKay authored
Prior to this, the code was missing AVR-specific relocation logic in RelocVisitor.h. This patch teaches RelocVisitor about R_AVR_16 and R_AVR_32. Debug information is emitted in the final object file, and understood by 'avr-readelf --debug-dump' from AVR-GCC. llvm-dwarfdump is yet to understand how to dump AVR DWARF symbols. llvm-svn: 351720
-
Dylan McKay authored
This reverts commit r351718. Carl pointed out that the unit test could be improved. This patch will be recommitted once the test is made more resilient. llvm-svn: 351719
-
Dylan McKay authored
This updates the AVR Select8/Select16 expansion code so that, when inserting the two basic blocks for true and false conditions, any existing fallthrough on the previous block is preserved. Prior to this patch, if the block before the Select pseudo fell through to the subsequent block, two new basic blocks would be inserted at the prior fallthrough point, changing the fallthrough destination. The predecessor or successor lists were not updated, causing the BranchFolding pass at -O1 and above the rearrange basic blocks, causing an infinite loop. Not to mention the unconditional fallthrough to the true block is incorrect in of itself. This patch modifies the Select8/16 expansion so that, if inserting true and false basic blocks at a fallthrough point, the implicit branch is preserved by means of an explicit, unconditional branch to the previous fallthrough destination. Thanks to Carl Peto for reporting this bug. This fixes avr-rust bug https://github.com/avr-rust/rust/issues/123. llvm-svn: 351718
-
Serge Guelton authored
llvm-svn: 351705
-
- Jan 20, 2019
-
-
Serge Guelton authored
llvm-svn: 351702
-
Serge Guelton authored
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
-
Matt Arsenault authored
llvm-svn: 351700
-
Matt Arsenault authored
llvm-svn: 351699
-
Matt Arsenault authored
There is a combine that was hiding these tests not actually testing what they should be, although they were producing the expected end result. llvm-svn: 351698
-
Simon Pilgrim authored
This causes a couple of changes in the upgrade tests as signed/unsigned eq/ne are equivalent and we constant fold true/false codes, these changes are the same as what we already do for avx512 cmp/ucmp. Noticed while cleaning up vector integer comparison costs for PR40376. llvm-svn: 351697
-
Matt Arsenault authored
llvm-svn: 351696
-
Matt Arsenault authored
llvm-svn: 351695
-
Matt Arsenault authored
This was crashing in the predicate function assuming the value is a vector. Copy more of what AArch64 uses. This probably needs more refinement later, but I don't exactly understand what it means in some cases, particularly since any legalization for these seems to be missing. llvm-svn: 351693
-
Matt Arsenault authored
llvm-svn: 351692
-
Matt Arsenault authored
llvm-svn: 351691
-
Simon Pilgrim authored
We were upgrading these to the new style VPCOM/VPCOMU intrinsics (which includes the condition code immediate), but we'll be getting rid of those shortly, so convert these to generics first. This causes a couple of changes in the upgrade tests as signed/unsigned eq/ne are equivalent and we constant fold true/false codes, these changes are the same as what we already do for avx512 cmp/ucmp. Noticed while cleaning up vector integer comparison costs for PR40376. llvm-svn: 351690
-
Simon Pilgrim authored
These intrinsics can always be replaced with generic integer comparisons without any regression in codegen, even for -O0/-fast-isel cases. Noticed while cleaning up vector integer comparison costs for PR40376. A future commit will remove/autoupgrade the existing VPCOM/VPCOMU llvm intrinsics. llvm-svn: 351688
-
Simon Pilgrim authored
Prior to SSE41 (and sometimes on AVX1), vector select has to be performed as a ((X & C)|(Y & ~C)) bit select. Exposes a couple of issues with the min/max reduction costs (which only go down to SSE42 for some reason). The increase pre-SSE41 selection costs also prevent a couple of tests from firing any longer, so I've either tweaked the target or added AVX tests as well to the existing SSE2 tests. llvm-svn: 351685
-
Simon Pilgrim authored
Typical throughputs: cmpss/cmpps = 1cy and cmpsd/cmppd = 2cy before the Core2 era llvm-svn: 351684
-
Simon Pilgrim authored
Minor tidyup to make it clearer whats going on before adding additional costs. llvm-svn: 351683
-
Simon Pilgrim authored
llvm-svn: 351682
-
Simon Pilgrim authored
llvm-svn: 351681
-
Simon Pilgrim authored
Also add AVX512 costs at the same time llvm-svn: 351680
-
Dylan McKay authored
These have been in place for quite a while now. Several bugs have since been fixed, and these tests now pass. llvm-svn: 351679
-
Dylan McKay authored
This extends the CMake cross compilation logic so that AVR can be set as the default target triple, and thus the generic codegen tests can be run. This used to be possible on AVR; the CMake configuration files have since been changed. With this patch, 'cmake -DLLVM_DEFAULT_TARGET_TRIPLE=avr-unknown-unknown' can be passed on the command line, making the `-mcpu` argument redundant to 'llc' and friends. llvm-svn: 351678
-
Dylan McKay authored
These were originally introduced in a copy-paste committed in r351526. The reference to 't2_so_imm' have been updated to 'imm_com8' so the comment is now accurate. Thanks to Eli Friedman for noticing this. llvm-svn: 351674
-
Dylan McKay authored
Prior to this patch, the AVR::LDWRdPtr instruction was always lowered to instructions of this pattern: ld $GPR8, [PTR:XYZ]+ ld $GPR8, [PTR]+1 This has a problem; the [PTR] is incremented in-place once, but never decremented. Future uses of the same pointer will use the now clobbered value, leading to the pointer being incorrect by an offset of one. This patch modifies the expansion code of the LDWRdPtr pseudo instruction so that the pointer variable is not silently clobbered in future uses in the same live range. Bug first reported by Keshav Kini. Patch by Kaushik Phatak. llvm-svn: 351673
-
Dylan McKay authored
This reverts commit r351544. In that commit, I had mistakenly misattributed the issue submitter as the patch author, Kaushik Phatak. The patch will be recommitted immediately with the correct attribution. llvm-svn: 351672
-
Vedant Kumar authored
llvm-svn: 351671
-
Eric Fiselier authored
llvm-svn: 351668
-
- Jan 19, 2019
-
-
Craig Topper authored
[X86] Add masked MCVTSI2P/MCVTUI2P ISD opcodes to model the cvtqq2ps cvtuqq2ps nodes that produce less than 128-bits of results. These nodes zero the upper half of the result and can't be represented with vselect. llvm-svn: 351666
-
Martin Storsjö authored
Differential Revision: https://reviews.llvm.org/D56873 llvm-svn: 351663
-
Martin Storsjö authored
Differential Revision: https://reviews.llvm.org/D56840 llvm-svn: 351662
-