Re: detecting constants at runtime

"Gene" <gene.ressler@gmail.com>
21 Nov 2005 23:22:29 -0500

          From comp.compilers

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)
| List of all articles for this month |

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.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.