This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 11/01/2017 08:24 AM, Richard Biener wrote:
On November 1, 2017 3:12:05 PM GMT+01:00, Jeff Law <law@redhat.com> wrote:On 11/01/2017 12:31 AM, Richard Biener wrote:In my local tree I'm just passing around the vrp_bitmap_obstackrightnow. Nobody's accessing it via a global anymore. So at least weknowwhat routines directly or indirectly want to touchvrp_bitmap_obstack.Maybe that's not necessary in most places given existing bitmaps knowtheir obstack? IIRC most places do sth to equivalences only if a range already contains some. I'd think that would help significantly if we're willing to make the assumption that all the bitmap allocations come from the same bitmap obstack.I think we can. Maybe add a comment with respect to that to the equiv field.
Sounds wise :-)
Glad to help. So with new way to find the obstack we can do away with passing around the equiv_obstack entirely.Again, the positive is this can be tested very quickly now. The joys of losing the global and getting some refactoring in done :-):) Thanks for doing this work! (... Strikes one item from too long todo list...)
Not sure what the biggest wart is now... Hmm, I guess that's a good place to be. There's still certainly cleanup to do, but it's coming together nicely.
It's probably time to carve off some chunks that are ready to commit. Like the obstack cleanup :-)
Jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |