* Jeremy Fitzhardinge (jeremy@xxxxxxxx) wrote: > Mathieu Desnoyers wrote: >> Markers, with immediate values, only clobbers the eax register and the >> ZF. It does not restrain inlining nor loop unrolling. It also requires >> gcc to leave the variables in which the marker is interested "live". > > That in itself is pretty significant. If that value would otherwise be > constant folded or strength-reduced away, you're putting a big limitation > on what the compiler can do. The mere fact that its necessary to do > something to preserve many values shows how much the compiler transforms > the code away from what's in the source, and specifically referencing > otherwise unused intermediates inhibits that. > > In other words, if you weren't preventing optimisations, you wouldn't need > to preserve values as much, because the optimiser wouldn't be getting rid > of them. If you need to preserve lots of values, you're necessarily > preventing the optimiser from doing its job. > > J 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
