This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/2] Get rid of global state accesses in dominance.c
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Mikhail Maltsev <maltsevm at gmail dot com>
- Cc: gcc-patches <gcc-patches at gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Fri, 14 Aug 2015 10:02:46 +0200
- Subject: Re: [PATCH 2/2] Get rid of global state accesses in dominance.c
- Authentication-results: sourceware.org; auth=none
- References: <55CD3C87 dot 40101 at gmail dot com> <55CD3EA1 dot 1050104 at gmail dot com>
On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev <maltsevm@gmail.com> wrote:
> The second part removes all global state accesses (i.e. accesses to cfun and
> it's members) from dominance.c. This requires to change lots of code, but I hope
> that this is a step in right direction (if my understanding of ongoing
> re-architecture w.r.t. to global state is correct).
>
> For now this second part lacks a changelog entry, but it's very "mechanical". I
> will, of course, write it if the patch gets approved.
So the last time I did similar refactoring I wondered if we can somehow avoid
the "noise" in non-IPA passes. Ideas I came up with are
a) Inherit gimple/rtl pass classes from a class which is initialized with the
function the pass operates on and provides methods like
bool dom_info_available_p (..) { return dom_info_available_p (fn, ...); }
thus wraps APIs working on a specific function.
b) Do sth similar but make it work with overloads and clever (no idea what!)
C++ that disables them if this_fn cannot be looked up
template <disable-me-if-this_fn-cannot_be_lookedup-at-instantiation-place>
bool dom_info_available_p (..., struct function *fn = this_fn);
all of the above would of course require that passes make all their
implementation
be methods of their pass class. So even more refactoring.
Note that we do not have any IPA pass which accesses dominators, so the
implicit 'cfun' use was ok. The cases I refactored were those where we had
to push/pop_cfun () in IPA passes (which can be expensive) because it
used APIs with implicit cfun.
Overall I'm not sure we want all APIs using 'cfun' to be refactored.
It is after
all useless noise to callers if all callers are effectively using 'cfun'.
Refactoring APIs that are used from IPA and make push/pop_cfun necessary
for them are another thing. (there are still plenty left I think)
Richard.
> --
> Regards,
> Mikhail Maltsev