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.
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.
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
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.
llvm/test/CodeGen/X86/abds.ll | ||
---|---|---|
31 | t0: ch,glue = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %0 t3: i8 = truncate t2 t7: i64 = sign_extend t3 t5: i32,ch = CopyFromReg t0, Register:i32 %1 t6: i8 = truncate t5 t8: i64 = sign_extend t6 t9: i64 = sub t7, t8 t10: i64 = abs t9 t11: i8 = truncate t10 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. |
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?
I'd probably focus initially on x86 only as that will have the most test changes and the most overlap with other targets.
llvm/test/CodeGen/X86/avx2-shift.ll | ||
---|---|---|
416 | Many of the vector regressions are due to X86's combineVectorTruncation fold that is destroying truncate patterns too soon. We should be able to get rid of it with a little more work. |
@deadalnix Please can you rebase? A lot of the vector truncate issues should be fixed now
llvm/test/CodeGen/X86/vselect.ll | ||
---|---|---|
5 | We need to add AVX1/AVX2 prefixes back here: ; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx | FileCheck %s --check-prefix=AVX1,AVX1 ; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx2 | FileCheck %s --check-prefixes=AVX,AVX2 |
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?
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.
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.