User Details
- User Since
- Dec 17 2012, 10:03 AM (545 w, 2 d)
Today
Could you re-upload the patch with the full context please?
I like the improved readability.
Thanks!
Yesterday
Ping, @nikic maybe?
Fri, May 26
Thu, May 25
LGTM
Wed, May 24
Right, it does complain about the LiveIntervals, but I thought that indicated that the LiveIntervals were not computed correctly, not that the underlying MIR was malformed.
I need some help understanding the background here. Why does LiveIntervals::computeVirtRegs only call splitSeparateComponents if it detected dead defs in a live interval? Is this some artifact of the way MIR is typically constructed by instruction selection?
Mon, May 22
Given what you observed and this limit is pretty much never hit in practice, I'm fine with bumping it.
Wed, May 17
I was hoping this patch could address my problem reported here: https://github.com/llvm/llvm-project/issues/62736
Sadly, it isn't. Maybe it's worth to extend it?
Tue, May 16
On a second thought the ABI concerns are probably fine because we can get the information directly from the LLVM IR.
Ping^5
I'm still wondering if somehow adding more semantic operands to FP operations would be less intrusive.
Thu, May 11
I can help get the patch reviewed if it is still relevant.
Just one high-level remark: the changes in the peephole optimizer should be a separate patch, right?
Adding more reviews.
Sure!
I'll probably do that beginning of next week.
Mon, May 8
Fri, May 5
Thanks for the fix
Given the patch does not modify generic parts anymore, I'm happy with it.
I leave the final decision to @arsenm since AMDGPU is outside my domain of expertise.
May 2 2023
Ping^4
Apr 25 2023
Apr 24 2023
Ping^3
Apr 23 2023
LGTM, please add a test for the lowering to "simple" pad.
Apr 21 2023
LGTM
Apr 18 2023
Ping^2
Apr 13 2023
Do we want to support MachineFunction/Info cloning?
This has to work and needs to be serializable.
- Use all_of and llvm::seq where appropriate
- Use getMixedDimensions to future proof the code w.r.t. dynamic dimensions
- Early-exit to avoid else indentation
Forgot to submit these comments!
Apr 12 2023
LGTM
Apr 11 2023
Ping
Apr 5 2023
Apr 4 2023
Nice catch!
Sorry for the delay I don't have an answer, but I have a couple of questions:
- Would it work to attach the delegate in MachineFunction::initTargetMachineFunctionInfo?
- Do we want to support MachineFunction/Info cloning?
I don't think this is correct.
Here we are merging the main live-ranges, so if we set the join subrange flag we may not check the right thing. In particular, the LaneBitmask in this call is incorrect, unless I am mistaken, for a subrange check.
Apr 3 2023
LGTM but I think we're missing a test for populateResolveExtractStridedMetadataPatterns.
@nicolasvasilache should we use transform dialect for the test?
Mar 30 2023
> I think the break statement cannot be removed, as it would crash if the last instruction is a debug instruction. Please correct me if I am missing something here.
Mar 29 2023
Mar 28 2023
- Fix bazel build
I only had a cursory look but the overall direction seems good.
Mar 24 2023
- Remove the test pass
- Add a tranform op instead
- Add a comment for strides when creating the subview
- Add a test for non-1 strides (only for vector.transfer_write, @nicolasvasilache let me know if you want more)
- Report failures with notifyMatchFailure
- Add missing vector dialect dependency to the test-extract-address-computations pass
- Add support for vector.transfer_read/write
- Move the populate function in its own header (we'll want to move others as well in an NFC patch)
- Fix the dropping of the nontemporal flag (and add a test for that)
- Refactor getSrcMemRef to not choke on tensor type
- Refactor getViewSizeForEachDim to use the same implementation for ldmatrix, vector.transfer_read/write
- Add tests for vector.transfer_read/write
Mar 23 2023
Mar 22 2023
Mar 21 2023
Abandoning that one for now. I think it would make sense to introduce some interface for this kind of rewriting.
Mar 15 2023
Nice clean-up!
Mar 14 2023
Food for thoughts:
Since the canonicalization is going to undo the decomposition, should we rewrite the expression (e.g., as part of the canonicalization) to the ordering we want?
The downside is we would still rely on the backend to do the hoisting of the loop invariant stuff.