search for: globalaa

...flag by default to all functions whose definitions aren't available (external), and then propagate from there on. I don't see any optimizations being inhibited by such a setting, so it should be okay. >I think we need to go back and look at the underlying use case (as I understand it): GlobalAA should be able to figure out that calls to malloc/free don't touch global variables visible to the optimizer. How do we address this problem? Yes, this is the primary concern. Most libc functions (including printf, malloc, free) fall into the same category. - Vaivaswatha On Fri, Dec 4, 201...

...#39;t available >> (external), and then propagate from there on. I don't see any >optimizations >> being inhibited by such a setting, so it should be okay. >> >> >> >I think we need to go back and look at the underlying use case (as I >> understand it): GlobalAA should be able to figure out that calls to >> malloc/free don't touch global variables visible to the optimizer. >How do >> we address this problem? >> Yes, this is the primary concern. Most libc functions (including >printf, >> malloc, free) fall into the same cat...

...n propagate from there on. I don't see any >optimizations >>>> being inhibited by such a setting, so it should be okay. >>>> >>>> >>>> >I think we need to go back and look at the underlying use case (as >I >>>> understand it): GlobalAA should be able to figure out that calls to >>>> malloc/free don't touch global variables visible to the optimizer. >How do >>>> we address this problem? >>>> Yes, this is the primary concern. Most libc functions (including >printf, >>>> mall...

...ble (external), and then propagate from there on. I don't see >> any optimizations being inhibited by such a setting, so it should be >> okay. >> >> >> >>> I think we need to go back and look at the underlying use case (as I >>> understand it): GlobalAA should be able to figure out that calls to >>> malloc/free don't touch global variables visible to the optimizer. >>> How do we address this problem? >> >> >> Yes, this is the primary concern. Most libc functions (including >> printf, malloc, free) fa...

>> In the case of user-defined allocation functions, the definitions for those functions are available >Are they? probably not unless you're in an LTO build. Yes, I'm assuming an LTO build. >Printf() is a very nasty one because it can actually affect a lot of state. The %n modifier can cause an argument to be written to. hence it would have HasInaccessibleState and ArgMemOnly

...m there on. I don't see > >> any optimizations being inhibited by such a setting, so it should > >> be okay. > >> > >> > >> > >>> I think we need to go back and look at the underlying use case (as > >>> I understand it): GlobalAA should be able to figure out that calls > >>> to malloc/free don't touch global variables visible to the > >>> optimizer. > >>> How do we address this problem? > >> > >> > >> Yes, this is the primary concern. Most libc functions...

...m there on. I don't see > >> any optimizations being inhibited by such a setting, so it should > >> be okay. > >> > >> > >> > >>> I think we need to go back and look at the underlying use case (as > >>> I understand it): GlobalAA should be able to figure out that calls > >>> to malloc/free don't touch global variables visible to the > >>> optimizer. > >>> How do we address this problem? > >> > >> > >> Yes, this is the primary concern. Most libc functions...