[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|--- |INVALID --- Comment #5 from Jan Hubicka --- As discussed uncprop really should propagate this way :)
[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 uncprop that it > should be last before RTL expansion. Will do, thanks! Honza
[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 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 think we simply want to reorder the passes here... > > > > Btw, uncprop is supposed to run right before RTL expansion - it is in fact > > an out-of-SSA optimization, so even removing it as separate pass and > > directly calling it from rewrite_out_of_ssa after eliminate_useless_phis > > might be an improvement. > > 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 uncprop that it should be last before RTL expansion.
[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 think we simply want to reorder the passes here... > > Btw, uncprop is supposed to run right before RTL expansion - it is in fact > an out-of-SSA optimization, so even removing it as separate pass and > directly calling it from rewrite_out_of_ssa after eliminate_useless_phis > might be an improvement. I don't know - this way we have separate dumps etc. I think mistake was scheduling pure-const and later modref too late. Thanks, Honza
[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 #1 from Richard Biener --- uncprop is supposed to reduce the number of copies required when expanding PHIs via coalescing which is never possible for constant PHI arguments, so yes, we do want this and maybe also for the case in question split out a forwarder to have only a single set of zero. 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. Btw, uncprop is supposed to run right before RTL expansion - it is in fact an out-of-SSA optimization, so even removing it as separate pass and directly calling it from rewrite_out_of_ssa after eliminate_useless_phis might be an improvement.
