search for: reset_options

Since updating to LLVM 3.3, the system is generating attributes such as: attributes #0 = { nounwind "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false"

...s to set the optimization level on a per function basis. > > http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html > describes the pragmas as > #pragma GCC optimize ("string") > #pragma GCC push_options > #pragma GCC pop_options > #pragma GCC reset_options > > Instead of imitating GCC's syntax, I think it would be better to use a > syntax > consistent with existing pragma clang diagnostics: > > #pragma clang optimize push > #pragma clang optimize "string" > #pragma clang optimize pop > Since the intent...

...mas have been added to allow users to set the optimization level on a per function basis. http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html describes the pragmas as #pragma GCC optimize ("string") #pragma GCC push_options #pragma GCC pop_options #pragma GCC reset_options Instead of imitating GCC's syntax, I think it would be better to use a syntax consistent with existing pragma clang diagnostics: #pragma clang optimize push #pragma clang optimize "string" #pragma clang optimize pop Each directive would have its own stack, which in my opini...

...vel on a per function basis. >> >> http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html >> describes the pragmas as >> #pragma GCC optimize ("string") >> #pragma GCC push_options >> #pragma GCC pop_options >> #pragma GCC reset_options >> >> Instead of imitating GCC's syntax, I think it would be better to use a >> syntax >> consistent with existing pragma clang diagnostics: >> >> #pragma clang optimize push >> #pragma clang optimize "string" >> #pragma clang opti...

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still