@mtrofin, I think it makes sense to have these tests available in all configurations. We have a bunch of printer passes which are not conditioned by NDEBUG.
Jun 19 2020
Jun 17 2020
Jun 3 2020
That sounds fine, my point is that having some run on benchmarks to quantify the benefit would help understand the value of this particular omission from the cost analysis (or at minimum show there's no regression, or understand where the regressions may be). It could shed important insights into what matters for the cost analysis, basically.
Apr 16 2020
Apr 9 2020
Apr 7 2020
Can you please elaborate what is the issue you are solving? May be give an example?
Feb 27 2020
Feb 26 2020
Demonstrating an improvement accuracy due to PHI translation turned out to be a bit tricky.
Feb 21 2020
I reworked the patch using PHITransAddr. Now instead of tracking the backedge flag I keep track of the address to check and translate the address when needed.
Couple of nit comments inlined, LGTM once addressed.
Feb 20 2020
Feb 14 2020
what is the use case of these options? Do hidden nodes create too much noise?
Feb 12 2020
LGTM with the renaming addressed.
Jan 31 2020
- Comment cleanup was landed separately
- Fixed the issue mentioned in https://reviews.llvm.org/D68006#inline-616849
- Added more tests
Dec 16 2019
Nov 21 2019
Nov 11 2019
Nov 8 2019
Nov 7 2019
Yeah, this limitation seems arbitrary and overly conservative.
Can we handle the case with inbounds offsets only first and extend with non-inbounds support in a follow up change? This way in the first change you'll not need to change IR interfaces at all.
Nov 6 2019
LGTM. Maybe add a test when the WC has one use but the branch condition is used in multiple branches.
Nov 1 2019
Oct 31 2019
Oct 28 2019
Oct 20 2019
Oct 1 2019
Sep 27 2019
This change was resubmitted as D68006.
This is specifically a hole in the calloc() handling, right? This case can't come up in regular load->store no-op stores: the address of the load dominates the load, so the address dominates all the operations between the load and the store, so alias() does the right thing.
That's right. I don't think that load->store case is affected.
Sep 25 2019
It looks like you successfully avoid the pitfall the original original loop predication fell into by filtering implicit exits and using trip counts. It makes me think that we can revisit loop predication again and go back to SCEV based implementation.
+1 to a test.
Sep 24 2019
It looks like you forgot to CC llvm-commits? Please post a new differential so the patch is sent to the list.
Resubmitted as D68006.
We should just skip debug instructions while looking for the guard in the window. Just use getNextNonDebugInstruction instead of current getNextNode.
Sep 20 2019
Aug 28 2019
Aug 1 2019
The original patch introduces a function minIterationWidthForEvaluateAtIteration. This way it exposes the limitation of evaluateAtIteration through the API and makes it possible for the user to choose the proper It width (e.g. like I did in the first revision https://reviews.llvm.org/D62563?vs=on&id=201795). What was the reason to remove it?
Jun 27 2019
Even though it's motivated by downstream code, looks harmless to change upstream.
Jun 11 2019
Jun 3 2019
Fall back to non-canonical mode for non-affine addrecs.
May 31 2019
May 30 2019
May 29 2019
Artur, nice find. In terms of staging complexity, have you considered how impactful it would be to simply refuse to generate the value at the given iteration in this case? evaluateAtIteration is allowed to return SCEVCouldNotCompute. I'm tempted to first introduce a bailout for a quick correctness fix - maybe along side your assert to see if we're missing any other cases - and then spend more time considering your full fix.
Have you considered reusing calculateByteProvider mechanism from load combining instead of matching an exact pattern?
May 28 2019
Apr 29 2019
Apr 28 2019
Apr 26 2019
Apr 22 2019
LGTM. I agree that we can leave the stronger variant for the future.
Apr 17 2019
Looks good overall, a couple of comments inline.
Apr 15 2019
Apr 3 2019
- Since we need to fiddle with the insertion point I think we should stop using single IRBuilder which we pass around. It looks like creating a local IRBuilder is a cheap operation, so we can have local IRBuilders when we need to generate instructions. This way the insertion point will be clear from the local context.
Jan 9 2019
Jan 3 2019
Dec 17 2018
Nov 29 2018
Nov 28 2018
Add diff with context.
One of the alternatives naming schemes which was discussed is to call this intrinsic should_deoptimize. In this case the meaning of the returned value is inverted, so we need to or it with the condition which we want to widen.
Nov 12 2018
Nov 7 2018
Nov 2 2018
Nov 1 2018
With this change you seem to be invalidating AST for instructions which have not been previously invalidated. I would hesitate to call this NFC.
Oct 29 2018
Current patch seems to have comments like "this block doesn't need invalidation". Maybe sink this decision down to the SafetyInfo implementation? It should reduce the complexity of the user: just call invalidate every time you delete/insert instructions and you would be fine.
Sep 8 2018
Sep 4 2018
Jun 26 2018
@rcorcs this has been accepted for quite a while, is there anything preventing integration? I'm looking forward to using colored graphs out of the box.