- User Since
- Apr 21 2014, 4:27 PM (335 w, 4 d)
Thu, Sep 24
You're right, it goes in the other direction. Looks ok to me.
Wed, Sep 23
I don't think it's safe to add dead defs to the extra lanes. You could split the superset into the matching part and the remaining part, then only operate on the matching one.
We should probably change bugpoint to stop using undef everywhere.
Fixed in https://reviews.llvm.org/rGe976fb1e54f3.
Mon, Sep 21
Removed unnecessary checks in isSubmask.
Fixed submask detection.
Fri, Sep 18
Pre-committed new test file.
Add testcases with unequal masks.
Removed the bool argument to getMatchingValue. Added comments explaining how the return value is used.
Wed, Sep 16
Tue, Sep 15
Should be fixed in https://reviews.llvm.org/rG5f4abb7fab1c.
The machine instructions in both dumps are identical... There are differences in addresses that are printed in the dump, and in the names of some values in the LLVM IR, but the machine instructions are the same.
The LLVM ERROR: Do not know how to split the result of this operator! happens when a function with an HVX intrinsic is compiled without +hvx,+hvx-length... attributes.
I added it to attributes #0, #1, #3 and #4.
If you have the ability to pass LLVM options, could you get the good and bad outputs with -debug-only=isel,legalize-types,legalizedag -print-after-all?
Just llc -march=hexagon < bad_hvx64_code.ll, but I added "target-cpu"="hexagonv65" "target-features"="+hvx,+hvx-length64b" to attributes inside the file.
Rebased on top of D87691.
Created D87691 with the refactoring. Will rebase this patch soon.
Mon, Sep 14
Great, thanks! Will take a look tomorrow.
Do you know what vector types are involved (e.g. <32 x i8>)? Anything with i1 or i64?
This should be NFC for everything that doesn't involve masked loads/stores.
Sat, Sep 12
Fri, Sep 11
Sure. Keep me posted.
Thu, Sep 10
Wed, Sep 9
Fix for the crash: D87423.
Marked masked-storing intrinsics as write-only in 8b7c8f2c549d301fcea75d8e6e98a8ee160d5ff4.
Calling isMaskedStoreOverwrite from isOverwrite to avoid multiple checks.
I think that the isMaskedStoreOverwrite could be merged into isOverwrite, but it'd need to take instructions in addition to the locations. I think it would be a bit cleaner than what this patch does.
Proposed fix: https://reviews.llvm.org/D87414.
Still investigating. Changing getLocForWriteEx doesn't fix it.
Hopefully https://reviews.llvm.org/rG0ee54cf88329 fixes this.
Yes, it fails to remove the store.
I disabled MSSA in this testcase so it won't fail when you switch (db7defd9bab7527ec1d0ed3fc62b379a9adf0971). I'll fix it in the meantime.
Hm, it fails with MemorySSA. Let me figure this out...
@fhahn Sure, let me do it now.
Committed in https://reviews.llvm.org/rG81ff2d30a900. Forgot to update the commit message. :(
Tue, Sep 8
Pre-committed a testcase.
Sat, Sep 5
Fri, Sep 4
Thu, Sep 3
Added a testcase for GVN.