- User Since
- Apr 21 2014, 4:27 PM (213 w, 2 d)
Tue, May 22
I'm ok with it, but please wait for Quentin's input.
Mon, May 21
Fri, May 18
Thu, May 17
Wed, May 16
Tue, May 15
Mon, May 14
Alright then. LGTM.
Sat, May 12
One thought I had was: if there is a block with only an unconditional branch, should we fold it away first? That is, redirect any branches to that block to the target of the branch?
Looks ok to me.
Fri, May 11
Thu, May 10
Wed, May 9
With the extra 40-bit testcase.
This looks good to me, I'm not concerned about the recursion, most of it is tail-recursion anyway.
Here's the IR immediately before LSR:
Here's a testcase where LSR generates code that it worse than the original (on Hexagon):
The whole loop is an assert. The only purpose of it is to verify the ID vs. its position in the loop. Maybe having for (unsigned i = ...; i != e; ++i) instead would be cleaner, but I think it's ok as is. I don't have a problem with changing it either, but I wouldn't say it's necessary.
Mon, May 7
Fri, May 4
- Removed incorrect (leftover from initial incorrect diff) Hexagon tests.
- Enable simplification on AArch64.
- Add testcases for AArch64 and Hexagon.
I don't know what AArch64 needs. I can enable it there too.
Thu, May 3
I have wanted something like this! Thanks for doing it.
Wed, May 2
Tue, May 1
I think we should recognize as much as we can out of the common idioms, and this is one of them. Looks good to me.
This recognizes something like "bitmask-any", where the code checks if any of the bits of V indicated by the mask C' is set. It looks like by replacing or with and you would get the corresponding "bitmask-all". Would it be worthwhile to add it? I don't have a use case, but the symmetry seems somewhat compelling.
Mon, Apr 30
Apr 20 2018
Apr 19 2018
@opaparo Please commandeer this revision, I only took over to restore the diff that got accidentally overwritten.
Hopefully the right diff was restored after the commit mismatch fiasco.
I screwed it up completely. Let me try to fix it.
Committed in https://reviews.llvm.org/rL330345.
Sorry, I pasted a wrong revision in a commit message.
I encountered a related problem in Hexagon code and I amended the patch to handle that as well. I couldn't upload it to this review, so I created a new one: D45819, but it's really meant to be an extension of this fix.
Apr 17 2018
Apr 16 2018
Apr 13 2018
Since you're ok with the vectorizer change, I'll commit this. If someone has concerns regarding the TTI interface, I'll address it post-commit.
Apr 12 2018
Wouldn't it be better to have this as a TII hook? There are instructions like "or reg, 0" or "add reg, 0" that are effectively copies, but only with specific operands.
Apr 10 2018
Apr 9 2018
Apr 6 2018
Would a change like the one in PassManagerBuilder.cpp be acceptable? There may be some work to make sure that the pre-existing components of the aggressive instcombine still apply, but I'm wondering if this direction is something we could agree on.
Moving aggressive instcombine pass to before the regular instcombine, just to demonstrate the idea.