- User Since
- Jul 30 2013, 7:58 PM (190 w, 4 d)
Fri, Mar 24
I'm seeing more problems than just nsw/nuw flags here.
Thu, Mar 23
Aren't there now broken patterns using COPY_TO_REGCLASS from FR32X/FR64X to VR128X below this now? For example the avx512_move_scalar_lowering multiclass.
Tue, Mar 21
Yeah I saw that. Should we add a debug counter around the top level worklist loop? The semantics of the "skip" part of the counter wouldn't make sense though.
Mon, Mar 20
Sun, Mar 19
That's great news! But this problem isn't unique to VK1. This test fails in 32-bit mode with avx512vl
Sat, Mar 18
I'm not sure how to do that. We eventually inferred the attributes. It just took a second trip through the InstCombine worklist.
Update all of the tests.
Add comment to PostOrderIterator.h
Fri, Mar 17
fputc and fputs check the type of one of the arguments before calling inferLibFuncAttributes. So its not always unconditional.
Just use RPOT and kill off the local vector
I was afraid of making the assumption about how RPOT works in case someone made it behave differently in the future. But I can change it to use RPOT if that's what you'd prefer.
Thu, Mar 16
Wed, Mar 15
Fix a couple additional fast isel bugs.
Tue, Mar 14
Mon, Mar 13
I've modified this to force the input to zero when the mask is all ones to break the execution dependency. I'll file a bug to look at using ExeDepsFix.
I've submitted r297651 to force the input to zero if the mask is all ones.
Sun, Mar 12
I wonder if we shouldn't keep zeroes to break execution dependency. I don't think the existing undef handling in ExeDependencyFix can handle the early clobber.
Looks like we only add xor for partial dependency breaking if the instruction is listed in hasUndefRegUpdate in X86InstrInfo.cpp and our first response it to use the same register as one of the other input operands, but that would be illegal for gather.
Sat, Mar 11
Fri, Mar 10
Have you ran the tests all the way through to assembly and made sure we don't regress? If we do regress, I wouldn't hold up fixing this, but we should at least have bugs for what breaks.
Wed, Mar 8
Mon, Mar 6
Sun, Mar 5
Add unit tests. Rebase for the removal of And/Or/Xor methods in r296993.
It is used in other places for example
Removing the And, Or, Xor functions could be removed separately.
Sat, Mar 4
Fix comment pointed out by Simon.
Fri, Mar 3
Cleanup the comments in setBitsSlowCase. Modify the implementation to just AND the low and high masks together when loWord and hiWord are the same.
LGTM with that one comment.
Thu, Mar 2
Make some portions of setBits inline. Use it to implement setLowBits and setHighBits.
I'm definitely going to look at moving some of setBits inline. I'm also planning to fix getBitsSet to use setBits. I might even fix setBits to support loBit > hiBit like getBitsSet supports.
@RKSimon , yes I think getLowBitsSet/getHighBitsSet would also benefit. I think they are mallocing twice due to the getAllOnes and then shifting. So I think we should be able to just create an all 0s APInt then call setLowBits/setHighBits instead and save one of the mallocs.
I haven't tried to measure any compile time differences. I was just inspired by Simon's patch for setBits and observing that ORing getLowBits/getHighBits was a common idiom in some places like ValueTracking. I assume we aren't often dealing larger than 64-bit numbers there on most types of compiled code.
Add periods at the end of comments.
Wed, Mar 1
Add a clearUpperBits call to the fast part of setHighBits along with a test case.
Fixed a copy/paste mistake
Tue, Feb 28
Should we fix the deficiencies in the current tables first so that there are no test changes?