This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: revised and updated new-if-converter patchâ [PATCH] fix PR46029: reimplement if conversion of loads and stores
- From: Abe <abe_skolnik at yahoo dot com>
- To: Alan Lawrence <alan dot lawrence at arm dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Sebastian Pop <sebpop at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 20 Jul 2015 14:57:54 -0500
- Subject: Re: revised and updated new-if-converter patchâ [PATCH] fix PR46029: reimplement if conversion of loads and stores
- Authentication-results: sourceware.org; auth=none
- References: <55A95E1A dot 9000301 at yahoo dot com> <55AD3001 dot 6040605 at arm dot com>
[Alan wrote:]
> Would having a testsuite predicate for the target supporting gathered loads
> let you run this test on those architectures? I'd expect one to be useful
> in a few other places too, in time if it doesn't exist already...
Thanks, but I don`t think that would fully fix all the regressions about which I am currently concerned.
I`m sure it could be useful to solve other problems, but as for the problems I am currently working on,
even though the above could easily provide a "way out", this is not the way in which I want to fix
the problem. I`d much rather fix/improve the new if converter so that it doesn`t require
the target architecture to be able to gather/scatter when there is no fundamental need to do so,
e.g. when the vectorizer is complaining with messages that include the word "gather" only because
the new if converter is being "wasteful" with indirections that are not truly necessary and which
the vectorizer cannot tolerate [and for which there is no intermediate pass that eliminates them].
In other words, the new if converter IMO needs to be more careful, more analytical, and more
parsimonious with its use of indirection than it is right now. It`s already a lot better than
the old converter, but it`s not perfect yet. IMO it`s good enough to push to trunk already
largely b/c we have a lot of time IMO-and-AFAIK before 6.x is tagged for release. The sooner
this gets pushed to trunk, the sooner we`ll have more "eyeballs" on this code and more people
might have good ideas for how to fix the regressions and otherwise improve the new code.
One of the best/most-important things I learned during my undergraduate Computer Science
education is "all problems in CS can be solved by adding another layer/level of indirection,
_except_ for the problem âI/we/the-program have/has too many layers/levels of indirectionâ". ;-)
Regards,
Abe