"git@repo.hca.bsc.es:rferrer/llvm-epi-0.8.git" did not exist on "a696ca66e91528e31d17974a95d86e8d1e3277cd"
- Mar 31, 2020
-
-
Florian Hahn authored
This is a speculative fix to silence the spurious C4129 warning that some version of MSVC generate for the raw string literals in the changed files. Before disabling the warning (D76428), try a potential fix suggested in the review.
-
- Mar 18, 2020
-
-
Florian Hahn authored
When the an underlying value is available, we can use its name for printing, as discussed in D73078. Reviewers: rengolin, hsaito, Ayal, gilr Reviewed By: Ayal Differential Revision: https://reviews.llvm.org/D76200
-
- Mar 05, 2020
-
-
Florian Hahn authored
Currently when printing VPValues we use the object address, which makes it hard to distinguish VPValues as they usually are large numbers with varying distance between them. This patch adds a simple slot tracker, similar to the ModuleSlotTracker used for IR values. In order to dump a VPValue or anything containing a VPValue, a slot tracker for the enclosing VPlan needs to be created. The existing VPlanPrinter can take care of that for the existing code. We assign consecutive numbers to each VPValue we encounter in a reverse post order traversal of the VPlan. Reviewers: rengolin, hsaito, fhahn, Ayal, dorit, gilr Reviewed By: gilr Differential Revision: https://reviews.llvm.org/D73078
-
- Mar 03, 2020
-
-
Florian Hahn authored
This patch adds a getPlan accessor to VPBlockBase, which finds the entry block of the plan containing the block and returns the plan set for this block. VPBlockBase contains a VPlan pointer, but it should only be set for the entry block of a plan. This allows moving blocks without updating the pointer for each moved block and in the future we might introduce a parent relationship between plans and blocks, similar to the one in LLVM IR. Reviewers: rengolin, hsaito, fhahn, Ayal, dorit, gilr Reviewed By: gilr Differential Revision: https://reviews.llvm.org/D74445
-
- Nov 09, 2019
-
-
Gil Rapaport authored
This recommits 11ed1c02 (reverted in 9f08ce0d for failing an assert) with a fix: tryToWidenMemory() now first checks if the widening decision is to interleave, thus maintaining previous behavior where tryToInterleaveMemory() was called first, giving priority to interleave decisions over widening/scalarization. This commit adds the test case that exposed this bug as a LIT.
-
- Nov 08, 2019
-
-
Gil Rapaport authored
This reverts commit 11ed1c02 - causes an assert failure.
-
Gil Rapaport authored
This recommits 100e797a (reverted in 009e0326 for failing an assert). While the root cause was independently reverted in eaff3004, this commit includes a LIT to make sure IVDescriptor's SinkAfter logic does not try to sink branch instructions.
-
- Nov 07, 2019
-
-
Eric Christopher authored
as it's causing assert failures. This reverts commit 100e797a.
-
- Nov 05, 2019
-
-
Gil Rapaport authored
This recommits 2be17087 (reverted in d3ec06d2 for heap-use-after-free) with a fix in IAI's reset() which was not clearing the set of interleave groups after deleting them.
-
- Nov 04, 2019
-
-
Benjamin Kramer authored
This reverts commit 2be17087. Fails ASAN.
-
Gil Rapaport authored
The sink-after and interleave-group vectorization decisions were so far applied to VPlan during initial VPlan construction, which complicates VPlan construction – also because of their inter-dependence. This patch refactors buildVPlanWithRecipes() to construct a simpler initial VPlan and later apply both these vectorization decisions, in order, as VPlan-to-VPlan transformations. Differential Revision: https://reviews.llvm.org/D68577
-
- Oct 11, 2019
-
-
Florian Hahn authored
This patch adds a moveAfter method to VPRecipeBase, which can be used to move elements after other elements, across VPBasicBlocks, if necessary. Reviewers: dcaballe, hsaito, rengolin, hfinkel Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D46825 llvm-svn: 374565
-
- Jan 19, 2019
-
-
Chandler Carruth authored
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
-
- Jun 18, 2018
-
-
Florian Hahn authored
Reviewers: dcaballe, hsaito, mkuper, hfinkel Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D48081 llvm-svn: 334951
-
Florian Hahn authored
Reviewers: dcaballe, mkuper, hfinkel, hsaito, mssimpso Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D48080 llvm-svn: 334933
-