* Jeremy Fitzhardinge (jeremy@goop.org) wrote:I am not saying that the standard marker will have to inhibit optimizations. Actually, it's the contrary : a well-thought marker should _not_ modify that kind of optimization, and we should put markers in code locations less likely to inhibit gcc optimizations. However, in the case where we happen to be interested in information otherwise optimized away by GCC, it makes sense to inhibit this optimization in order to have the information available for tracing. I expect this to happen rarely, but I think we must deal with optimizations to make sure we never trace garbage due to some unexpected gcc optimization. I think it's a small (e.g. undetectable at the macrobenchmark level) price to pay to get correct tracing information. Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Nigel Cunningham | Re: [PATCH] Remove process freezer from suspend to RAM pathway |
| Paul Mundt | Re: 2.6.22-rc4-mm2 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
