Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

[Segher Boessenkool <segher@kernel.crashing.org>]

On Mon, Feb 27, 2023 at 09:54:06PM +0100, Jakub Jelinek wrote:
> Even if the target-independent code doesn't know what the target dependent
> code will do, I don't see how it could emit it safely.

I always understood RTL to not have anything like C "undefined
behavior", but be closer in general (exceptions are integer division by
zero etc.) to C's "unspecified value".  This is quite close to what on
Power we call "boundedly undefined":
  The results of executing a given instruction are said to be boundedly
  undefined if they could have been achieved by executing an arbitrary
  finite sequence of instructions (none of which yields boundedly
  undefined results) in the state the processor was in before
  executing the given instruction. Boundedly undefined results may
  include the presentation of inconsistent state to the system error
  handler as described in Section 1.8.1 of Book II. Boundedly undefined
  results for a given instruction may vary between implementations, and
  between different executions on the same implementation.
So no trapping, everything writes all bits in all registers always, etc.

C undefined behaviour makes the *whole program* undefined, always: it
can have effects reaching unlimitedly far into the future, but also
unboundedly far into the past (well, not further back then program
start, there is that :-) ).  RTL unspecified stuff is way more limited
than that.  It also has a very different goal: C UB is to allow
compilers to optimise more programs and to optimise them better, while
for RTL we simply do not specify the operation result in some cases.
This does not mean such cases cannot happen!

And of course there are TARGET_SHIFT_COUNT_TRUNCATED and
TARGET_SHIFT_TRUNCATION_MASK, which allow to make more inputs result in
known (to the compiler) outputs.


Segher