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: Combine four insns


On 08/06/2010 01:22 PM, Steven Bosscher wrote:
On Fri, Aug 6, 2010 at 6:45 PM, Paolo Bonzini<bonzini@gnu.org> wrote:
(I know, it's the old argument we've had before: You have a real fix
now for a real problem, others (incl. me) believe that to fix this
problem in combine is a step away from sane instruction selection that
GCC may not have for years to come...)
In this case I actually think this argument is not going to work, since we
have not even a prototype of a sane instruction selection pass and not even
someone who is thinking about working on it.
To be honest I am periodically thinking about working on it but I did not make a final decision yet and don't know when I can start.
Agreed. There is the work from Preston Briggs, but that appears to
have gone no-where, unfortunately.

IMHO the code should have become public if we want to see a progress on the problem solution. But it is a Google property and they probably decided not to give it gcc community. Although I heard that Ken Zadeck has access to it. We will see what the final result will be.

I only can guess from speculations on info I have that Preston's code is probably not so valuable for GCC because as I understand the backend was only specialized for x86/x86_64.

The real problem is not in implementing modern pattern matching itself (there are a lot free pattern matching code and tools for code selection). The real problem is in how to feed all md files (in which implementation a lot of gcc community efforts were made) to pattern matcher (in any case most probably we will not need define_split in md files if we use a modern pattern matcher).

Another problem, most modern pattern matchers works on trees not on DAGs. There are some solutions (heuristic or expensive optimal) for this problem. The combiner already solves the problem in some way.

In any case I'd not expect, from a new code selection pass, big code or compile time improvements (e.g. code selection in LLVM is very expensive and takes more time than GCC combiner). But a new code selection pass could be more readable and easy for maintenance.



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