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]

RE: Register Pressure in Instruction Level Parallelism (fwd)


> What isn't promising about it is that integer programming is 
> a technique for exact solutions to NP-complete problems.  

No comment.

> Since these are hard problems, exact solutions tend to be 
> very computation-intensive. 

There not being any other type of solution, apparently?

> GCC is slow enough as it is; integer programming based 
> allocation is exceptionally computation-intensive, especially 
> for large or pathological programs.

Shovelling dirt takes time, especially when there's lots of dirt, or the
dirt is in fact rich in lead and thus rather heavy?

Seriously, what are you trying to say here? That GCC is (or should be) a
compiler that's fast, *particularly* for large or pathological programs?
I hope not. I think that donning the "GCC shall remain in P-time"
blinkers is rather inappropriate when it comes to instruction
scheduling. Perhaps a "please use damn-fast scheduling heuristic"
command line switch would be nice, but not on by default. And while I'm
aware it'll take more than a new whizz-bang scheduler to really improve
GCC's IA64 output, I'm sure you'll agree it's not just the large or
pathological programs that GCC could use some help with.

	Duraid



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