This change is in preparation to reuse these test for the Attributor.
It mainly is to remove UB, make it clear what is tested, and use
"modern" run lines.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 40440 Build 40547: arc lint + arc unit
Event Timeline
llvm/test/Transforms/IPConstantProp/2009-09-24-byval-ptr.ll | ||
---|---|---|
27 | This matches closer the check lines above and it also does not force us to fold the gep into the load (which is not what is important here). | |
llvm/test/Transforms/IPConstantProp/PR26044.ll | ||
62 | Having the check lines at the end makes it hard to relate them to code so I went with a update of all lines here. | |
llvm/test/Transforms/IPConstantProp/arg-count-mismatch.ll | ||
57 | The calls were essentially dead and could be removed, make sure that is not the optimization we are looking for. | |
llvm/test/Transforms/IPConstantProp/solve-after-each-resolving-undefs-for-function.ll | ||
18 | Branch on undef is UB, I think, and even if not, this method did trivially return 10 even without resolving any constant branches. Make sure this is not the case anymore and add a "for sure UB-free" path while we are at it. | |
llvm/test/Transforms/IPConstantProp/user-with-multiple-uses.ll | ||
33 | These attributes are given already (and arguably wrong from a more fundamental standpoint) so it is questionable why we should check for them in the first place. |
It seems some of those files test IPSCCP while others test the IPConstantPropagation pass. Having them both in there is a bit confusing. I think most IPSCCP tests live in test/Transforms/SCCP, which they share the code with. It might be worth to move the IPSCCP tests from IPConstantPropagation to test/Transforms/SCCP or create a new IPSCCP test directory.
And FWIW, I think we might want to consider removing the IPConstantPropagation pass, because it looks like it is not used in any pipelines and IPSCCP is more powerful.
I don't mind either way. Do you want me to do it in this commit or do it after?
And FWIW, I think we might want to consider removing the IPConstantPropagation pass, because it looks like it is not used in any pipelines and IPSCCP is more powerful.
Agreed, see: https://reviews.llvm.org/D69656#1728773
Any comments wrt. the changes I made?
This patch looks good to me.
Now, on the more general discussion. There are some cases that are caught by IPCP [but not IPSCCP]. We can craft examples, if we want, but it's unclear how often they happen in practice.
Having IPCP in tree doesn't seem to be a huge maintenance burden. OTOH, the algorithm is extremely naive and the pass isn't used anywhere, so if somebody wants to remove it, I wouldn't have any objections.
Also note that the cases that are caught by IPCP and not by IPSCCP are due to the fact that IPCP isn't really an analysis, and replaces stuffs as it goes. Having a context-sensitive IPSCCP pass could alleviate some of the differences, but it's unclear whether it's worth the complexity.
[if you probably replace opt -ipconstprop with opt -ipsccp in the tests you'll stumble upon the cases I pointed out.
Interesting! That's unfortunate, with the pass being disabled. I'll try to take a look at those when I have a bit of time.
I briefly tried this and it looks like the two main features ipconstprop has and ipsccp not are: 1) multi-return/extractvalue support, 2) callback support
This matches closer the check lines above and it also does not force us to fold the gep into the load (which is not what is important here).