* CLZ when CLZ_DEFINED_VALUE_AT_ZERO is false
@ 2023-08-31 13:56 Krister Walfridsson
2023-09-01 8:13 ` Richard Biener
0 siblings, 1 reply; 4+ messages in thread
From: Krister Walfridsson @ 2023-08-31 13:56 UTC (permalink / raw)
To: gcc
My translation validation tool reports some miscompilations related to the
internal call CLZ(0) when CLZ_DEFINED_VALUE_AT_ZERO is false, but I am not
sure I use the correct semantics...
I started by modeling CLZ(0) as undefined behavior, but that made the tool
report a miscompilation for gcc.c-torture/execute/920501-6.c where sccp
changes a loop to
_36 = t_10(D) != 0;
_35 = .CLZ (t_10(D));
_34 = 63 - _35;
_33 = (unsigned int) _34;
_32 = (long long unsigned int) _33;
_31 = _32 + 1;
b_38 = _36 ? _31 : 1;
This may call CLZ with 0, but the value is not used, so it seems
reasonable to allow this. I therefore changed my tool to treat CLZ(0) as
returning an undefined value instead (by generating it as a symbolic
value, which then makes the tool test that the IR is valid for all
values).
This still makes this optimization fail because the calculation of _34 may
overflow... :( This could be a bug in the sccp pass (which could have
done the calculation as unsigned), but fixing this would still make the
tool report a miscompilation as the ranges calculated during the dom3 pass
claims that _35 has a range:
_35 : [irange] int [0, 63]
So what is the correct semantics for CLZ when CLZ_DEFINED_VALUE_AT_ZERO is
false?
/Krister
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: CLZ when CLZ_DEFINED_VALUE_AT_ZERO is false
2023-08-31 13:56 CLZ when CLZ_DEFINED_VALUE_AT_ZERO is false Krister Walfridsson
@ 2023-09-01 8:13 ` Richard Biener
2023-09-01 8:27 ` Jakub Jelinek
2023-09-03 23:30 ` Krister Walfridsson
0 siblings, 2 replies; 4+ messages in thread
From: Richard Biener @ 2023-09-01 8:13 UTC (permalink / raw)
To: Krister Walfridsson, Andrew MacLeod; +Cc: gcc
On Thu, Aug 31, 2023 at 3:58 PM Krister Walfridsson via Gcc
<gcc@gcc.gnu.org> wrote:
>
> My translation validation tool reports some miscompilations related to the
> internal call CLZ(0) when CLZ_DEFINED_VALUE_AT_ZERO is false, but I am not
> sure I use the correct semantics...
>
> I started by modeling CLZ(0) as undefined behavior, but that made the tool
> report a miscompilation for gcc.c-torture/execute/920501-6.c where sccp
> changes a loop to
>
> _36 = t_10(D) != 0;
> _35 = .CLZ (t_10(D));
> _34 = 63 - _35;
> _33 = (unsigned int) _34;
> _32 = (long long unsigned int) _33;
> _31 = _32 + 1;
> b_38 = _36 ? _31 : 1;
>
> This may call CLZ with 0, but the value is not used, so it seems
> reasonable to allow this. I therefore changed my tool to treat CLZ(0) as
> returning an undefined value instead (by generating it as a symbolic
> value, which then makes the tool test that the IR is valid for all
> values).
>
> This still makes this optimization fail because the calculation of _34 may
> overflow... :( This could be a bug in the sccp pass (which could have
> done the calculation as unsigned), but fixing this would still make the
> tool report a miscompilation as the ranges calculated during the dom3 pass
> claims that _35 has a range:
> _35 : [irange] int [0, 63]
>
> So what is the correct semantics for CLZ when CLZ_DEFINED_VALUE_AT_ZERO is
> false?
The value of .CLZ (0) is undefined then. I belive your analysis is correct in
that both 63 - _35 might overflow and that dom3 (thus ranger) mis-computes
the range for _35. I wonder why we don't elide _36 ? _31 : 1 with that info
(possibly no range-op for .CLZ?), of course it would be wrong to do so.
Can you open a bugreport please?
Richard.
>
> /Krister
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: CLZ when CLZ_DEFINED_VALUE_AT_ZERO is false
2023-09-01 8:13 ` Richard Biener
@ 2023-09-01 8:27 ` Jakub Jelinek
2023-09-03 23:30 ` Krister Walfridsson
1 sibling, 0 replies; 4+ messages in thread
From: Jakub Jelinek @ 2023-09-01 8:27 UTC (permalink / raw)
To: Richard Biener; +Cc: Krister Walfridsson, Andrew MacLeod, gcc
On Fri, Sep 01, 2023 at 10:13:40AM +0200, Richard Biener via Gcc wrote:
> The value of .CLZ (0) is undefined then. I belive your analysis is correct in
> that both 63 - _35 might overflow and that dom3 (thus ranger) mis-computes
> the range for _35. I wonder why we don't elide _36 ? _31 : 1 with that info
> (possibly no range-op for .CLZ?), of course it would be wrong to do so.
>
> Can you open a bugreport please?
Seems similar to https://gcc.gnu.org/pipermail/gcc-patches/2023-February/thread.html#612214
except that case is at RTL level.
But arguably, I think at least at GIMPLE level we should just emit here
GIMPLE_COND + separate bb around it rather than COND_EXPR.
Jakub
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: CLZ when CLZ_DEFINED_VALUE_AT_ZERO is false
2023-09-01 8:13 ` Richard Biener
2023-09-01 8:27 ` Jakub Jelinek
@ 2023-09-03 23:30 ` Krister Walfridsson
1 sibling, 0 replies; 4+ messages in thread
From: Krister Walfridsson @ 2023-09-03 23:30 UTC (permalink / raw)
To: Richard Biener; +Cc: Andrew MacLeod, gcc
On Fri, 1 Sep 2023, Richard Biener wrote:
> The value of .CLZ (0) is undefined then. I belive your analysis is correct in
> that both 63 - _35 might overflow and that dom3 (thus ranger) mis-computes
> the range for _35. I wonder why we don't elide _36 ? _31 : 1 with that info
> (possibly no range-op for .CLZ?), of course it would be wrong to do so.
>
> Can you open a bugreport please?
PR 111280.
/Krister
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-09-03 23:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-31 13:56 CLZ when CLZ_DEFINED_VALUE_AT_ZERO is false Krister Walfridsson
2023-09-01 8:13 ` Richard Biener
2023-09-01 8:27 ` Jakub Jelinek
2023-09-03 23:30 ` Krister Walfridsson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).