Reorder DAG updates in visitZERO_EXTEND and visitSIGN_EXTEND to remove insertions of deleted nodes.
This fixes additional related cases in PR32284.
Differential D31625
[SDAG] Fix CombineTo ordering in visitZERO_EXTEND and visitSIGN_EXTEND niravd on Apr 3 2017, 1:27 PM. Authored by
Details Reorder DAG updates in visitZERO_EXTEND and visitSIGN_EXTEND to remove insertions of deleted nodes. This fixes additional related cases in PR32284.
Diff Detail
Event TimelineComment Actions Hi, Thanks for submitting this change, but I don't understand it. The phab issue title and summary don't seem to match up, the summary isn't descriptive enough for me to grok what's going on here and you haven't provided a testcase. Cheers, James Comment Actions Add missing test cases. This solves most of the skx SelectionDAG errors we've been seeing under O0. Comment Actions Hi, Those testcases are too strict. If you just need to check that a testcase doesn't cause an assertion failure, you can avoid any FileCheck checks and put "; REQUIRES: asserts" (I think that's the syntax) to ensure it only gets run on an asserts build. James
Comment Actions This is specifically what Chandler requested on a similar previous patch (see https://reviews.llvm.org/D31286). Comment Actions Hi Nirav, Looking at the linked issue, it doesn't look like Chandler actually saw the updated testcase, approving before you updated it. This testcase is overly strict and any change in codegen will make it fail. If you really want to put FileCheck checks in there, you should check *some property* of the generated output, not it in its entirety. James Comment Actions You're still checking the entire codegen output for this function. That's not what this test is about; this doesn't add any value, all it does is add maintenance burden. Can the test be reduced at all? I think, at least for this case, I respectfully disagree with Chandler and don't see the utility in adding FileCheck lines. James Comment Actions What Chandler requested in that commit is what James is requesting now. A meaningful check on the generated instructions. Not nothing. Not everything. A meaningful representation of the problem, which normally translates to a short (3-5) sequence of instructions that change between bugged and non-bugged versions. Both Chandler and James are absolutely correct that checking for failure as well as checking for the exact sequence will generate problems later and it's not acceptable. If you don't know what to check for, run the program before and after your patch and see what changes. This will also give confidence to the reviewers that your patch is only changing what's required and needed, not some random parts of the program. cheers, Comment Actions ExtendSetCCs must happen before other CombineTo calls. This should fix the errors dbabokn found Comment Actions The fact that this review keeps going between all-checks and no-checks is enough to make me distrust the change. The fact that people are finding errors with the implementation and the tests don't reflect that makes me distrust the tests. The fact that the description is lacking and there was no further attempt to explain what the problem is makes me distrust the analysis of the problem and therefore the fix. The fact that bug PR32884 doesn't exist is just the icing. Comment Actions Renato, apologies for the frustration. Had I not been in a rush to leave I would have realized my "please don't review yet" message hadn't been committed. This started as a follow up fix for PR32284 (not 32884 as I typoed in the summary) which is a simple CombineTo ordering issue that caused use of deleted SDNodes causing assertions and could be solved with a little reordering. It was reopened after Dmitry found 100s large number of test failures of which he'd been able to package a few. Having a fix for that It was entirely unclear if I'd gotten them all and started this review as a rendezvous. I hadn't but the initial failure I saw looked unrelated so I planned on a follow up patch when I'd gotten a few more failures. But looking at the new failures this afternoon made it clear there was an ordering dependence on N0 and SetCCs which should be part of this patch. At this point I'm waiting to hear if the current patch fixes the problem or if there's another testcase that has a similar failure. I'm still uncertain what to do about tests. The nature of the assertion requires a certain amount of redundance in the input making using the auto-generated path relatively long as James commented. If we limited the tests to -O0 the output it should be fairly stable though and the differences should be obvious (and given these were all found with -O0 doesn't seem unreasonable). The make sure it doesn't assert approach seems reasonable as well. Barring comments, my default plan is to mark the shared subset of instructions across the RUN calls that make sense. Comment Actions Nirav, I still see 19 fails with current patch. All the remaining fails that I have are reduced and attached to 32284 as third attachment. Thanks for taking care of these fails. Comment Actions Hi,
As Renato said previously, a sequence of 3-4 CHECK lines is normally more than sufficient. Any more than that and I start to worry about what the test is actually checking for. James Comment Actions It looks like this is still being marked as pending revision. I'm explicitly marking as planning changes and updating it. Comment Actions Pinging again. This patch still just needs a review that the test checking is acceptable.
|
Please can you re-add the i686 tests?