This is the mail archive of the gcc-patches@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]

Re: revised and updated new-if-converter patchâ [PATCH] fix PR46029: reimplement if conversion of loads and stores


[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]