Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-10-07 15:18, David Laight wrote:
From: Jonas Oberhauser
Sent: 07 October 2024 12:55

Am 10/3/2024 um 3:23 PM schrieb Mathieu Desnoyers:
What _does_ work however are the following two approaches:

1) Perform the equality check on the original variables, creating
new versions (with OPTIMIZER_HIDE_VAR) of both variables for the
rest of their use, therefore making sure the pointer dereference
are not derived from versions of the variables which were compared
with another pointer. (as suggested by Boqun)

This should not be guaranteed to work, because right after the
comparison the compiler can do b=a, then it doesn't matter how much you
hide afterwards.

However it might work if you escape the addresses of a and b first, in
which case the compiler will not do b=a anymore, but it might force the
compiler to put a and b on the stack, which has some performance impact.

Nope, as pointed out last week, the compiler can move the 'a == b'
check to before the OPTIMISER_HID_VAR() and then use the same register
for both of them.

Yes.


2) Perform the equality check on the versions resulting of hiding
both variables, making sure those versions of the variables are
not dereferenced afterwards. (as suggested by Linus)

That (and other things) could usefully use:
#define OPTIMISER_HIDE_VALUE(x) \
	({ __auto_type _x = x; OPTIMISER_HIDE_VAR(_x); _x; })
You'll almost certainly end up with a register-register move
even if 'x' isn't used afterwards.

Yes.


The calling could just become:
	if (a == OPTIMISER_HIDE_VALUE(b) ...
since it is likely that you only care about one of the pointers.
(Actually isn't hiding one of them always enough?)

Linus asked that we hide both inputs, otherwise it's really asking
for trouble in terms of API misuse.

Thanks,

Mathieu


	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux