In the same vein as D127115, this is step toward processing the dag in topological order.
This is a bit of a shotgun diff and will require many issue to be fixed before proceeding.
Paths
| Differential D152928
[RFC][DAG] Initially add nodes in the worklist in topological order. Needs ReviewPublic Authored by deadalnix on Jun 14 2023, 8:52 AM.
Details Summary In the same vein as D127115, this is step toward processing the dag in topological order. This is a bit of a shotgun diff and will require many issue to be fixed before proceeding.
Diff Detail
Event Timelinedeadalnix retitled this revision from [RFX][DAG] Initially add nodes in the worklist in topological order. to [RFC][DAG] Initially add nodes in the worklist in topological order..Jun 14 2023, 8:53 AM Comment Actions oh no, not again :) A lot of these seem to be related to changes in extension/truncations - although I haven't noticed any common pattern Comment Actions
This one should be the most disruptive one. After that, it's mostly in topological order, and there will be a couple of patch up to ensure this is always the case, but disturbance should be minimal. Herald added subscribers: wangpc, luke, pmatos and 34 others. · View Herald TranscriptJun 16 2023, 6:41 AM
Comment Actions As I go on, the changeset is becoming so big that phabricator is unable to display it. Maybe this isn't the right approach, but then, what's the right approach? Comment Actions I'd probably focus initially on x86 only as that will have the most test changes and the most overlap with other targets.
dmgreen mentioned this in D153972: [AArch64] Fold tree of offset loads combine.Jun 29 2023, 12:45 AM Comment Actions @deadalnix Please can you rebase? A lot of the vector truncate issues should be fixed now
Comment Actions Given that this is not going to be resolved anytime soon and we're relatively early into the review, would you be open to moving this to a GitHub PR? Comment Actions
If this is what it takes, but I'm really not thrilled by the move to be honest. It's way harder to keep track of changes, notification are basically useless, and there is no kind of useful dashboard of what one need to pay attention to either. Comment Actions
Yes its as much fun as a tooth extraction :| But I'm worried that Phab will not get much love going forward and we're months away from getting the x86 regressions fixed, let alone any other backend. I've started my own WIP branch of this patch at https://github.com/RKSimon/llvm-project/tree/perf/D152928 so I can more easily work though addressing issues; I'll be rebasing + forcing pushes so don't rely on git history if you track it. But wherever you decide to keep the main patch will remain the reference. Large DiffThis large diff affects 560 files. Files without inline comments have been collapsed. Expand All Files
Revision Contents
Diff 557805 llvm/test/CodeGen/X86/abds.ll
llvm/test/CodeGen/X86/vselect.ll
|
This has regressed because the sign_extend(truncate()) have already been folded to sign_extend_inreg(any_extend()) before foldABSToABD is called via visitTRUNCATE, meaning we only call it later via visitABS directly and lose the smaller types.