On Wed, Nov 14, 2018 at 09:29:15AM +0100, Richard Biener wrote:
> On Wed, 14 Nov 2018, Jakub Jelinek wrote:
> > As mentioned in the PR, it is unclear if zero_extract is well defined
> > if the second argument is 0. x86 intrinsic require bzhi and bextr to be
> > well defined in those cases (extraction of 0 bits results in 0), but
> > e.g. combiner hapilly transforms that into << 64 >> 64, simplify-rtx.c,
> > while it folds it into 0, might invoke UB in the compiler etc.
>
> So where do the zero_extracts come from? Can we somehow avoid
> zero-sized bit-extracts at expansion time by folding them to zero?
That is what the patch does for tbm_bextri. Both the size and position
arguments must be constant in that instruction, so if for some reason
0 size or position >= bitsize makes it through (there is gimple folder to
optimize that), the expander will move 0 into the destination, plus
canonicalize if size + position > bitsize otherwise, so that
size + position == bitsize.
The patch can't do this for bzhi, where the operand is register_operand.
Even if we add a gimple folder to handle this (will do it, but didn't want
to test it together with the patch), the problematic constant can appear
there during RTL optimizations. Which is why I've used if_then_else,
so if constant appears there, we fold it right.
Jakub
