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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.04.19 at 13:00, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----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?

Not exactly: Using const indeed doesn't help code generation.
The compiler can't assume objects pointed to by a pointer-to-
const won't change (e.g. across function calls). But as said in
my earlier reply, there's still value of adding const in that it
allows the compiler to spot programming mistakes.
 
Jan



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