[Bug tree-optimization/103117] uncprop produces harder to analyze but not better code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103117 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/103117] uncprop produces harder to analyze but not better code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103117 --- Comment #4 from hubicka at kam dot mff.cuni.cz --- > > I don't know - this way we have separate dumps etc. I think mistake was > > scheduling pure-const and later modref too late. > > Maybe. If you move them please put a comment before unc

[Bug tree-optimization/103117] uncprop produces harder to analyze but not better code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103117 --- Comment #3 from rguenther at suse dot de --- On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103117 > > --- Comment #2 from hubicka at kam dot mff.cuni.cz --- > > I suppose modref co

[Bug tree-optimization/103117] uncprop produces harder to analyze but not better code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103117 --- Comment #2 from hubicka at kam dot mff.cuni.cz --- > I suppose modref could (for pointer returns) use ranger to query its range > and see if it ever is non-NULL? I'm not sure if we reliably propagate > null pointer constants everywhere. I t

[Bug tree-optimization/103117] uncprop produces harder to analyze but not better code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103117 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment