- Align ManualMapSet with X86MemoryFoldTableEntry instead of using UnfoldStrategy
- ManualMapSet able to update the existing record in auto-generated MemFold table
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
PLAN:
- Move MemoryFoldTable2Addr MemoryFoldTable0~4 into X86InstrFoldTables.def from llvm/lib/Target/X86/X86InstrFoldTables.cpp https://reviews.llvm.org/D142083
- Update llvm/lib/Target/X86/X86InstrFoldTables.def with adding records, mainly for avx512fp16 https://reviews.llvm.org/D143149
- Upgrade mechanism of auto-generated memfolding table https://reviews.llvm.org/D142084
- Update ManualMapSet in X86FoldTablesEmitter.cpp to make x86-auto-memfold.td pass
- small modification for remaining different ~30 records
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
35 | Where is NO_STRATEGY define? It looks like it was deleted from the left hand of this diff. |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
63 | Don't duplicate the definitions in llvm/lib/Target/X86/X86InstrFoldTables.h, try finding a common place | |
84 | See my comments in https://reviews.llvm.org/D142083, we can change thing to print here |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
35 | changed to 0 |
llvm/test/TableGen/x86-auto-memfold.td | ||
---|---|---|
3 | Drop "-asmwriternum=1" "-write-if-changed" | |
4 | Drop this line by using pipleline in the previous line. | |
5 | We should remove all the \t or space in INC file, don't use "tr" for it. | |
8 | Drop the XFAIL, this patch should be merged after fp16 records are added. | |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
47–48 | Move this into a .inc as a whitelist |
llvm/test/TableGen/x86-auto-memfold.td | ||
---|---|---|
3 | Question: what do we skip here? |
llvm/utils/TableGen/X86FoldTablesEmitterManualMapSet.inc | ||
---|---|---|
2 | This comment does not applies to all the entries in the table, I think we should move it to a suitable place. in this file. |
llvm/test/TableGen/x86-auto-memfold.td | ||
---|---|---|
3 | the first 568 bytes are: /*===- TableGen'erated file -------------------------------------*- C++ -*-===*\ |* *| |* X86 fold tables *| |* *| |* Automatically generated file, do not edit! *| |* *| \*===----------------------------------------------------------------------===*/ |
llvm/lib/Target/X86/X86MemFoldTables.inc | ||
---|---|---|
261 ↗ | (On Diff #495799) | It would be good to get some/all of these diffs committed first to minimize any changes in codegen due to this patch - the patch should only be about the build process. |
llvm/lib/Target/X86/X86MemFoldTables.inc | ||
---|---|---|
261 ↗ | (On Diff #495799) | Both methods are okay to me. I suggested the author to merge the table change into this PR b/c we are not confident the update in the table is correct. The new table needs a careful review. And if the reviewer doubted an entry was incorrect, the author could point out which rule used in the X86FoldTablesEmitter.cpp was "guilty" and get suggestion/feedback from reviewers. A separate diff would be the best way if we could check the correctness of the table just by looking at the entry themselves. |
llvm/lib/Target/X86/X86MemFoldTables.inc | ||
---|---|---|
509–510 ↗ | (On Diff #495799) | should remove one of them otherwise leads to duplicate entry in unfolding table. |
llvm/lib/Target/X86/X86MemFoldTables.inc | ||
---|---|---|
614 ↗ | (On Diff #495799) | These aren't real load instructions. It doesn't really make sense for them to be in the table. Folding the load would make the load not happen. That would be incorrect for volatile. |
4009 ↗ | (On Diff #495799) | Would this allow unfolding a VMOVAPDZ128rmk to VMOVAPDZ128rrk + VMOVAPDZ128rm? That would be a bug. |
llvm/lib/Target/X86/X86MemFoldTables.inc | ||
---|---|---|
4009 ↗ | (On Diff #495799) | @craig.topper besides, do we need to add TB_NO_REVERSE for {X86::VMOVAPDZ128rr, X86::VMOVAPDZ128rm, TB_ALIGN_16}? |
llvm/lib/Target/X86/X86MemFoldTables.inc | ||
---|---|---|
4009 ↗ | (On Diff #495799) | What I said previously applied to arithmetic that has loads folded into them. VMOVAPDZ128rmk is created from a masked load with an isel pattern. VMOVAPDZ128rm will never be unfolded. We unfold to separate a loop invariant load from arithmetic. There’s no arithmetic folded in to it.. the only operands are address operands. They would all need to be loop invariant to hoist so the whole instruction is hoistable. For VMOVAPDZ128rmk there is a mask operand and address operands. Without TB_NO_REVERSE we would try to unfold it if the address was loop invariant but the mask wasn’t. This would be incorrect. The mask may be masking off elements that will fault. |
llvm/lib/Target/X86/X86MemFoldTables.inc | ||
---|---|---|
4009 ↗ | (On Diff #495799) | thanks for explanation. i also check the code in llvm/lib/CodeGen/MachineLICM.cpp // First check whether we should hoist this instruction. if (!IsLoopInvariantInst(*MI) || !IsProfitableToHoist(*MI)) { // If not, try unfolding a hoistable load. MI = ExtractHoistableLoad(MI); if (!MI) return false; } since VMOVAPDZ128rmk((the address isloop invariant but the mask is not)) is not IsLoopInvariantInst, we can extract a wholeload from it if it is Without TB_NO_REVERSE. so what you said about VMOVAPDZ128rmk and VMOVAPDZ128rm makes sense to me. |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
422 | Is there better way to check no-kz version's isMoveReg? |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
432 | load such as VMOVAPDZ128rm will never be unfolded. // First check whether we should hoist this instruction. if (!IsLoopInvariantInst(*MI) || !IsProfitableToHoist(*MI)) { // If not, try unfolding a hoistable load. MI = ExtractHoistableLoad(MI); if (!MI) return false; } MachineInstr *MachineLICMBase::ExtractHoistableLoad(MachineInstr *MI) { // Don't unfold simple loads. if (MI->canFoldAsLoad()) return nullptr; @craig.topper , does line429~439 make sense to you as well? |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
133 | I copy the code from "bool operator<(const X86FoldTableEntry &RHS) const {", |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
133 | I think it's a NFC change from me. If we remove this comparison, will any test fail? |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
133 | It's the sort order for the enum in X86GenInstrInfo.inc. Instructions with isPseudo set are ordered before other instructions. |
does unfolding only happen in LICM?
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
432 | @craig.topper i think my analysis of VMOVAPDZ128rm is only for LICM. but for other passes in codegen, is it possible for VMOVAPDZ128rm to be unfolded? |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
432 | The other 2 places I know that unfold are TwoAddressInstructionPass and SelectionDAG->MachineIR TwoAddressInstuctionPass should only happen for instructions with tied source and dest. That doesn't apply to moveReg. I think SelectionDAG->MachineIR case happens if we need to duplicate an instruction that has an EFLAGS def. If the EFLAGS are used by two instructions and EFLAGS is clobbered in between them. We need to duplicate the flag producing instruction to satisfy the second user. But we can't duplicate the folded load so we have to unfold. That doesn't apply to moveReg. |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
432 | i saw two kinds of unfoldMemoryOperand, one of which is for MIR and another is for DAG. Our folding table can't affect unfoldMemoryOperand for DAG, right? |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
432 | I think the DAG unfoldMemoryOperand uses the same table. |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
432 | The DAG unfold occurs after the isel portion of SelectionDAG. So it's MachineOpcodes |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
432 | oh, you're right. unfoldMemoryOperand is trying to find the MIR according to DAGNode's Machinecode, and then lookupUnfoldTable bool X86InstrInfo::unfoldMemoryOperand(SelectionDAG &DAG, SDNode *N, SmallVectorImpl<SDNode*> &NewNodes) const { if (!N->isMachineOpcode()) return false; const X86MemoryFoldTableEntry *I = lookupUnfoldTable(N->getMachineOpcode()); @craig.topper , but where can i find the code of DAG unfold which occurs after the isel portion of SelectionDAG? |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
432 | ScheduleDAGRRList.cpp is the code. The DAG needs to be scheduled into linear basic block for MachineIR. |
llvm/utils/TableGen/X86FoldTablesEmitterManualMapSet.inc | ||
---|---|---|
31 | for myself, why " { "TAILJMPr", "TAILJMPm", TB_FOLDED_LOAD }," listed here. |
llvm/test/TableGen/x86-auto-memfold.td | ||
---|---|---|
3 | From the manpage of cmp, it should be like: cmp [OPTIONS] file1 file2 There are some implementation that cannot take --ignore-initial after the files. Can you move it to the front? |
llvm/test/TableGen/x86-auto-memfold.td | ||
---|---|---|
3 | This was breaking our tests on macOS as well, so I pushed rG7e271c2a8552 to fix. |
@vitalybuka , do you know how to reproduce the issue by buildbot_fast.sh?
i tried https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild#try-local-changes
but it set HEAD wrongly at
commit 8dfdcc7b7bf66834a761bd8de445840ef68e4d1a Author: Nikolas Klauser <nikolasklauser@berlin.de> Date: Thu Nov 17 21:34:29 2022 +0100 [libc++] Fix memory leaks when throwing inside std::vector constructors Fixes #58392 Reviewed By: ldionne, #libc Spies: alexfh, hans, joanahalili, dblaikie, libcxx-commits Differential Revision: https://reviews.llvm.org/D138601
@hctim do you know how to reproduce the ubsan issue elegantly. after i spend some time modify buildbot_functions.sh, i still can't reproduce it locally. https://lab.llvm.org/buildbot/#/builders/5/builds/32220/steps/16/logs/stdio
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
386 | Is it possible for S & TB_ALIGN_MASK to be 0? That would cause 1<< -1 which would match the ubsan error |
llvm/utils/TableGen/X86FoldTablesEmitter.cpp | ||
---|---|---|
387 | Use a variable instead of repeating the same code twice? |
This commit may be breaking this bot:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/52590/console
llvm-project/llvm/utils/TableGen/X86FoldTablesEmitterManualMapSet.inc:4:48: error: use of undeclared identifier 'TB_NO_REVERSE' { "ADD16ri_DB", "ADD16mi", TB_NO_REVERSE },
Also note that the pre-merge checks failed to clang format these files:
llvm/include/llvm/Support/X86FoldTablesUtils.h llvm/lib/Target/X86/X86InstrFoldTables.h llvm/utils/TableGen/X86FoldTablesEmitter.cpp llvm/utils/TableGen/X86FoldTablesEmitterManualMapSet.inc
llvm/include/llvm/Support/X86FoldTablesUtils.h | ||
---|---|---|
12 | The anon namespace is causing the bot failure, was a there a particular reason for this change? If not, I'll submit a patch |
llvm/include/llvm/Support/X86FoldTablesUtils.h | ||
---|---|---|
12 | I think it's a typo by the author of this patch. |
Hi, this is also causing a failure on the clang-ppc64-aix bot https://lab.llvm.org/buildbot/#/builders/214/builds/6519
+ : 'RUN: at line 1' + /scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/build/bin/llvm-tblgen -gen-x86-fold-tables -asmwriternum=1 /scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/TableGen/../../lib/Target/X86/X86.td -I /scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/TableGen/../../include -I /scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/TableGen/../../lib/Target/X86/ -I /scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/TableGen/../../include/ -I /scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/TableGen/../../lib/Target/ --write-if-changed -o /scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/build/test/TableGen/Output/x86-auto-memfold.td.tmp1 + : 'RUN: at line 2' + cmp --ignore-initial=0:568 /scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/TableGen/../../lib/Target/X86/X86MemFoldTables.inc /scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/build/test/TableGen/Output/x86-auto-memfold.td.tmp1 cmp: illegal option -- - usage: cmp [-l | -s] file1 file2
llvm/include/llvm/Support/X86FoldTablesUtils.h | ||
---|---|---|
12 | thanks for fixing it. |
@abhina.sreeskantharajan
seems "--ignore-initial=0:568" doesn't support ppc64? will https://reviews.llvm.org/D146498 works for you?
llvm/test/TableGen/x86-auto-memfold.td | ||
---|---|---|
1 | Could you update/fix this test to not depend on the real .td file - all the other tblgen tests include a small snippet/test case/example instead? (though the test was renamed in 35aeb321c005ed77ef5e5fb4f8dea69a81c81253) |
llvm/test/TableGen/x86-auto-memfold.td | ||
---|---|---|
1 | @dblaikie Thank you for the suggestion! The test itself aims to expose the vulnerable rules in X86FoldTablesEmitter.cpp. Due to the complexity of X86ISA, even the folding rules are already complicated, it is hard to predict whether exceptions will occur when new ISAs are introduced. So unfortunately, we need the real .td file as input. I illustrated the usage of the test file in D147527 |
The anon namespace is causing the bot failure, was a there a particular reason for this change? If not, I'll submit a patch