- User Since
- May 24 2016, 8:35 AM (242 w, 4 d)
Thanks for the patch. There is a patch to make MVE consistent with the rest of MVE in D94867. This will need rebasing on top of that, with update tests to make the two consistent again.
LGTM. We sometimes generate a lot of shuffles in an attempt to do lane interleaving and I know the simplification of them isn't always what it could be once all the lowering has happened. I thought more happened through simplifying buildvectors but apparently not. This looks like a good continuation to the existing code.
Wed, Jan 13
Thanks for the changes. LGTM
Mon, Jan 11
Oh yeah. Sorry. Forgot about that.
Fri, Jan 8
Rebase and ping. I also adjusted some code and better dealt with loop invariant operands.
Thanks. I made a typo in the summary, it should have said "do not seem to be correct", not "do seem...".
Hello. I tried running our downstream benchmarks with this patch and it did not appear to have any effect, either in performance or codesize. (That doesn't mean that nothing is effected, but it's at least a good sign).
Thu, Jan 7
LGTM thanks, but please try and simplify the test case if you can.
Wed, Jan 6
Thanks. LGTM with a couple of suggestions.
Added a unit test, that caught that the Parent was not set correctly.
Thanks. I don't know any of the details of this specific core, but this LGTM in terms of a schedule.
Tue, Jan 5
Mon, Jan 4
Updated to use is128BitVector
OK that seems to have done better. Thanks for the report. Let us know if anything else comes up.
Oh strange. Let me try with a more specific triple..
Wed, Dec 30
I've not ran any benchmarking, and this is touching some fairly commonly used parts of a commonly used schedule (and scheduling can be weird at times). If we do run into problems we can address them as we need, but it looks like a nice improvement and the numbers you have look good. Thanks for the patch.
Add a VPRecipeBase::moveBefore and use it and getFirstNonPhi.
Added an extra test with predicated stores and removed some undefs.
- Removed forward from ASMID multiplies (mul, pmul, sqdmulh, smull, umull).
Tue, Dec 29
Hello. Yeah those are related. I was using an AND here to get the same effect, but this is more likely to come up from the truncs in that patch in practice. D93834 is the mull part of handling any_extends. (It unfortunately doesn't entirely fix both the cases there because we end up turning one of the any_extends into a zext load, and are left with a smull of a sext load and zext load).
Sun, Dec 27
Thu, Dec 24
Thanks. I think this LGTM now.