#407 More accurate notVolatile()

open
nobody
None
5
2014-02-13
2014-02-12
No

The peephole optimizer uses a function notVolatile() to check if a variable is voaltile. Currently, this works OK for variables in registers and global variables. Everything else is considered as potentially volatile, resulting in some optimizations not being done where they could be done.

I suggest to improve this:
1) Scan over all variables accessed in the function (at some earlier time), and record if there is no volatile one among them. In this case, notVolatile() can always return true.
2) Scan over all on-stack variables accessed in the function (at some earlier time), and record if there is no volatile one among them. In this case, notVolatile() can always return true for on-stack variables. THis is useful for functions that access volatile variables, but do not use local volatile variables.

Philipp

Discussion

  • Maarten Brock

    Maarten Brock - 2014-02-13

    When you say global variables, do you mean statically allocated variables? So it would include most local variables in the mcs51 and other ports?

    Scanning on-stack variables will certainly help as most of the time a volatile variable is a global or static variable. With the most common exception being a pointer to a volatile variable.

    Is there a special reason why the function cannot detect if a stacked variable is volatile at the moment of interest?

     
  • Philipp Klaus Krause

    notVolatile looks for a symbol name in the asm. That works with anything that has a symbol name in the asm, e.g. global variables. For stack variables we don't have a symbol name in the asm. We might have a frame-pointer offset that could be used to find the original symbol (or find the subset of stacked variables that are stored at that location). Or we might have a stack offset, which might or might not be good enough to find the underlying symbol.

    Philipp

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks