- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
LGTM
Rebase after the argument register change
Rebase
Rebase
Is this dependent on the frame lowering patch to emit the csrr vlenb?
Is this patch dependent on https://reviews.llvm.org/D93614?
LGTM
LGTM
LGTM
LGTM
@mundaym do you have commit access yet? I think Sam had been committing your previous patches?
Rebase
Doesn't this mean that if you only enable zvlsseg, you'll be able to use the instruction in that extension but not the vsetvli instruction that you need to program the VL register?
Move pack tests from rv32zbbp-invalid.s to rv32zbp-invalid.s
Remove conflict marker that got left behind
Rebase after clang-format in Zba patch
clang-format
Update header on RISCVInstrInfoB.td
Yesterday
Does this need earlyclobber? The spec says "For vector indexed segment loads, the destination vector register groups cannot overlap the source vector register group (speci fied by vs2), else an illegal instruction exception is raised."
LGTM
-Add tests for unused results on the masked intrinsic
-Make the masked intrinsic have "side effects"
-Use the default read/write memory property instead of IntrReadMem+IntrHasSideEffects which doesn't work correctly without tablegen changes.
Rebase
Rebase
Rebase
Rebase
Rebase
Rebase
Rebase
Rebase
Revoking my approval
Rebase
Rebase
Remove Zba changes that accidentally got merged in the previous rebase
Rebase
Rebase
Rebase
Rebase
Rebase
Rebase
Rebase
Remove side effects from READ_VL portion. Allowing it to be deleted.
In D76127#2510504, @jdoerfert wrote:TBH, I feel "X is readonly and has side effects" sends the wrong message to begin with. It is a contradiction (in the IR world) as basically shown by the need for this patch. Given that there are no examples in-tree I don't understand why one would mark a side-effect intrinsic as readonly (or similar). Long story short, I would argue this should be a loud error, not silently ignored.
Having just tripped over this bug again. I think we should fix this
LGTM
LGTM
LGTM
LGTM
In D94652#2509274, @frasercrmck wrote:Changes look good but, like you, I can't see that these instructions are in that section (or any section for that matter). We can keep an eye on the issue you filed and approve once it's confirmed?
In D94653#2509254, @frasercrmck wrote:What are the implications of having the renamed Zbe instructions in what we'll advertise as 0.93?
In D94637#2509271, @frasercrmck wrote:LGTM. I take it the patterns can come later?
Tue, Jan 19
LGTM to me with that one comment.
This is a very incomplete review, but I need to go eat dinner
LGTM
In D94951#2508538, @arcbbb wrote:In D94951#2507301, @craig.topper wrote:I'm not sure I understand what's special about vrgathere16 that needs this refactor. Can you provide an explanation?
VPatBinary helps encode LMUL in the instruction name,
but for vrgatherei16 it needs to encode both LMUL & EMUL in the instruction name,
like PseudoVRGATHEREI16_VV_M1_M1, and PseudoVRGATHEREI16_VV_M1_M2.
Here is my patch for vrgatherei16 based on the NFC patch https://reviews.llvm.org/D95014
Rebase
Fix comment
Modify to use the same approach as rev8 and orc.b patch
Consistently use isCompressOnly = true
I'm not sure I understand what's special about vrgathere16 that needs this refactor. Can you provide an explanation?