From: Sandipan Das <hidden> Date: 2017-10-09 11:07:38
According to the GCC documentation, the behaviour of __builtin_clz()
and __builtin_clzl() is undefined if the value of the input argument
is zero. Without handling this special case, these builtins have been
used for emulating the following instructions:
* Count Leading Zeros Word (cntlzw[.])
* Count Leading Zeros Doubleword (cntlzd[.])
This fixes the emulated behaviour of these instructions by adding an
additional check for this special case.
Signed-off-by: Sandipan Das <redacted>
---
arch/powerpc/lib/sstep.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
From: David Laight <hidden> Date: 2017-10-09 13:49:29
From: Sandipan Das
Sent: 09 October 2017 12:07
According to the GCC documentation, the behaviour of __builtin_clz()
and __builtin_clzl() is undefined if the value of the input argument
is zero. Without handling this special case, these builtins have been
used for emulating the following instructions:
* Count Leading Zeros Word (cntlzw[.])
* Count Leading Zeros Doubleword (cntlzd[.])
=20
This fixes the emulated behaviour of these instructions by adding an
additional check for this special case.
Presumably the result is undefined because the underlying cpu
instruction is used - and it's return value is implementation defined.
Here you are emulating the cpu instruction - so executing one will
give the same answer as it the 'real' one were execucted.
Indeed it might be worth an asm statement that definitely executes
the cpu instruction?
David
From: David Laight <hidden> Date: 2017-10-09 14:43:48
From: Segher Boessenkool
Sent: 09 October 2017 15:21
On Mon, Oct 09, 2017 at 01:49:26PM +0000, David Laight wrote:
quoted
From: Sandipan Das
quoted
Sent: 09 October 2017 12:07
According to the GCC documentation, the behaviour of __builtin_clz()
and __builtin_clzl() is undefined if the value of the input argument
is zero. Without handling this special case, these builtins have been
used for emulating the following instructions:
* Count Leading Zeros Word (cntlzw[.])
* Count Leading Zeros Doubleword (cntlzd[.])
This fixes the emulated behaviour of these instructions by adding an
additional check for this special case.
Presumably the result is undefined because the underlying cpu
instruction is used - and it's return value is implementation defined.
=20
It is undefined because the result is undefined, and the compiler
optimises based on that. The return value of the builtin is undefined,
not implementation defined.
=20
The patch is correct.
But the code you are emulating might be relying on the (un)defined value
the cpu instruction gives for zero input rather than the input width.
Or, put another way, if the return value for a clz instruction with zero
argument is undefined (as it is on x86 - intel and amd may differ) then the
emulation can return any value since the code can't care.
So the conditional is not needed.
David
From: Naveen N. Rao <hidden> Date: 2017-10-09 14:45:26
On 2017/10/09 11:07AM, Sandipan Das wrote:
According to the GCC documentation, the behaviour of __builtin_clz()
and __builtin_clzl() is undefined if the value of the input argument
is zero. Without handling this special case, these builtins have been
used for emulating the following instructions:
* Count Leading Zeros Word (cntlzw[.])
* Count Leading Zeros Doubleword (cntlzd[.])
This fixes the emulated behaviour of these instructions by adding an
additional check for this special case.
So:
Fixes: 3cdfcbfd32b9d ("powerpc: Change analyse_instr so it doesn't
modify *regs")
Sent: 09 October 2017 15:21
On Mon, Oct 09, 2017 at 01:49:26PM +0000, David Laight wrote:
quoted
From: Sandipan Das
quoted
Sent: 09 October 2017 12:07
According to the GCC documentation, the behaviour of __builtin_clz()
and __builtin_clzl() is undefined if the value of the input argument
is zero. Without handling this special case, these builtins have been
used for emulating the following instructions:
* Count Leading Zeros Word (cntlzw[.])
* Count Leading Zeros Doubleword (cntlzd[.])
This fixes the emulated behaviour of these instructions by adding an
additional check for this special case.
Presumably the result is undefined because the underlying cpu
instruction is used - and it's return value is implementation defined.
It is undefined because the result is undefined, and the compiler
optimises based on that. The return value of the builtin is undefined,
not implementation defined.
The patch is correct.
But the code you are emulating might be relying on the (un)defined value
the cpu instruction gives for zero input rather than the input width.
Or, put another way, if the return value for a clz instruction with zero
argument is undefined (as it is on x86 - intel and amd may differ) then the
emulation can return any value since the code can't care.
So the conditional is not needed.
This is about the behavior of the gcc builtin being undefined, rather
than the actual cpu instruction itself.
- Naveen
On Mon, Oct 09, 2017 at 02:43:45PM +0000, David Laight wrote:
From: Segher Boessenkool
quoted
Sent: 09 October 2017 15:21
On Mon, Oct 09, 2017 at 01:49:26PM +0000, David Laight wrote:
quoted
From: Sandipan Das
quoted
Sent: 09 October 2017 12:07
According to the GCC documentation, the behaviour of __builtin_clz()
and __builtin_clzl() is undefined if the value of the input argument
is zero. Without handling this special case, these builtins have been
used for emulating the following instructions:
* Count Leading Zeros Word (cntlzw[.])
* Count Leading Zeros Doubleword (cntlzd[.])
This fixes the emulated behaviour of these instructions by adding an
additional check for this special case.
Presumably the result is undefined because the underlying cpu
instruction is used - and it's return value is implementation defined.
It is undefined because the result is undefined, and the compiler
optimises based on that. The return value of the builtin is undefined,
not implementation defined.
The patch is correct.
But the code you are emulating might be relying on the (un)defined value
the cpu instruction gives for zero input rather than the input width.
Or, put another way, if the return value for a clz instruction with zero
argument is undefined (as it is on x86 - intel and amd may differ) then the
emulation can return any value since the code can't care.
So the conditional is not needed.
The cntlz[wd][.] insn has defined behaviour for 0 input. It's just the
builtin that does not. So we shouldn't call the builtin with an input
of 0 -- exactly what this patch does -- and that is all that was wrong.
Segher
On Mon, Oct 09, 2017 at 01:49:26PM +0000, David Laight wrote:
From: Sandipan Das
quoted
Sent: 09 October 2017 12:07
According to the GCC documentation, the behaviour of __builtin_clz()
and __builtin_clzl() is undefined if the value of the input argument
is zero. Without handling this special case, these builtins have been
used for emulating the following instructions:
* Count Leading Zeros Word (cntlzw[.])
* Count Leading Zeros Doubleword (cntlzd[.])
This fixes the emulated behaviour of these instructions by adding an
additional check for this special case.
Presumably the result is undefined because the underlying cpu
instruction is used - and it's return value is implementation defined.
It is undefined because the result is undefined, and the compiler
optimises based on that. The return value of the builtin is undefined,
not implementation defined.
The patch is correct.
Segher
From: David Laight <hidden> Date: 2017-10-09 15:24:03
From: naveen.n.rao@linux.vnet.ibm.com
Sent: 09 October 2017 15:48
...
This is about the behavior of the gcc builtin being undefined, rather
than the actual cpu instruction itself.
I'd have hoped that the ggc builtin just generated the expected cpu instruc=
tion.
So is only undefined because it is very cpu dependant.
More problematic here would be any cpu flag register settings.
eg: x86 would set the 'Z' flag for zero input.
David