- User Since
- Apr 25 2018, 1:47 PM (64 w, 4 d)
Wed, Jul 17
Mon, Jul 15
Fri, Jul 12
Thu, Jul 11
Wed, Jul 10
*ping* Is it ok to proceed with only checking the new PM output for these tests? If so I could just edit my previous patch to remove the legacy PM run lines since they already include the bitcasts from the new PM.
Mon, Jul 8
LGTM. Good catch
Tue, Jul 2
Mon, Jul 1
Fri, Jun 28
Reverted in r364692
Understood. I'll revert this patch.
I mean, I'm happy for the patch to be reverted, but I still really don't understand why this fixes the test to work *exactly* the same as w/ the old pass manager and doesn't break any other tests if it is completely wrong? It seems like there must be something strange with the test coverage if this is so far off of correct without any failures...
I also don't understand what fix you are suggesting instead, but maybe you can show a patch?
Thu, Jun 27
@t.p.northover Would you feel ok reviewing this?
Wed, Jun 26
Any updates on this? I'm thinking that in the meantime maybe we could commit D63174 and work on this while that lands. If so, we could get an upstream new PM buildbot that can catch any new PM regressions.
Mon, Jun 24
Hmm is there usually a protocol/etiquette for getting a new built-in submitted to compiler-rt?
Is there not a function for that already in compiler-rt? Or is the problem that it doesn't necessarily exist, e.g. if we're supporting a 64-bit scaled integer type but not a 128-bit integer type?
Jun 21 2019
Jun 20 2019
Jun 19 2019
CodeGen/pgo-sample.c [No new fix]: The test checks that PruneEH runs, but there doesn’t seem to be a corresponding new PM pass for it. Should there be? If there is one then we can just check for that in the debug PM dump.
The analog would be function-attrs and function(simplify-cfg) in some combination. Maybe this should just check that some specific thing is optimized away at -O2 rather than checking the specific details of pass pipeline construction?
Jun 18 2019
OK so I instead wrote a script that generated the tests for me since changing each individual case by hand was painful. All the -cc1 tests now match, although I don't know any ways of simplifying the IR further to help reduce test size. I would definitely love to know if there are any ways to simplify the instructions. Unfortunately for convergent.cl, the codegen still differs slightly around the end of the loop when using -instcombine in addition to instnamer:
Jun 14 2019
For the avx tests, I don't suppose you know a simple way to generate these tests? They're about 10k lines long and it's taking a while to go through it by hand to replace the current IR checks with codegen for -O1. (Perhaps something along the lines of utils/update_llc_test_checks.py in llvm?)
I did some more digging and found the following differences between PMs for each test, and they seem to all differ and can be fixed for different reasons.