Related articles |
---|
detecting constants at runtime kamath.poornima@gmail.com (kamath.poornima@gmail.com) (2005-11-19) |
Re: detecting constants at runtime gene.ressler@gmail.com (Gene) (2005-11-21) |
Re: detecting constants at runtime gene.ressler@gmail.com (Gene) (2005-11-21) |
From: | "Gene" <gene.ressler@gmail.com> |
Newsgroups: | comp.compilers |
Date: | 21 Nov 2005 23:22:29 -0500 |
Organization: | http://groups.google.com |
References: | 05-11-090 |
Keywords: | optimize |
Posted-Date: | 21 Nov 2005 23:22:29 EST |
Detecting all constants is an undecidable problem, so it's hard to see
how runtime information is going to give an advantage over static
compile-time analysis for this optimization.
Without much trouble you ought to be able to do "reverse code
generation", converting machine instructions to basic blocks of tuples
or SSA or what have you. Registers and stack slots would become the
named quanitities and you'd have to use live range analysis to rename
these uniquely wherever possible. Then you can apply standard
optimizations (including constant folding) and register
(re)allocation. Where the optimizations and register allocation can
be informed by runtime profiles, you have opportunities to improve
performance.
I don't know the answer to the profiling question, but 80x86 debuggers
seem to handle data displays with low overhead. I believe they use
features of the VM archtecture to generate traps. You might look at
gdb or other debugger internals.
I don' t know about volatiles. The answer would depend entirely on
linker formats and source language conventions. I doubt that volatile
stack variables are tagged in any way.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.