Re: [PATCH 1/1] x86: fix text_poke

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Jeremy Fitzhardinge (jeremy@goop.org) 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