Re: [Xen-devel] [PATCH] x86/msr: Fix fallout from mostly c/s 832c180

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> 
> > An optimising compiler which uses an object, and passes a const pointer
> > to that object to a function, is permitted to retain assumptions derived
> > from that state across the function call sequence point, because the ABI
> > of the function states that the content of the object doesn't change.
> 
> Very much not so, no. Take this simple (and granted contrived)
> example:
> 
> int integer;
> 
> int test(void) {
>       func(&integer);
>       return integer;
> }
> 
> and in a different CU (just to avoid the effect of the compiler
> inlining the whole thing)
> 
> void func(const int*pi) {
>       integer = ~*pi;
> }
> 
> Various other examples are possible, including ones where
> there's nothing contrived at all.
> 

I'm not sure whether the fact that 'integer' is accessed as a non-const global 
in the above makes any difference in this example but what you seem to be 
highlighting is that there's simply no point in ever using const struct vcpu 
pointers because the compiler can never actually do any useful optimization 
based on the const qualifier. Is that the case?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel