On Tue, Mar 25, 2014 at 8:24 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> Hi!
>
> The bootstrap-ubsan bootstrap revealed a problem with the
> {add,sub,mul}v<mode>4 patterns. The problem is that they
> accept CONST_INT operands (because the instructions do accept immediates),
> but to model what the instruction actually does, we need to have both
> the value of the operand itself and it's sign extended value to
> 2x wider mode, but say (sign_extend:DI (const_int 5)) in the pattern is
> invalid RTL (found about this because e.g. num_sign_bit_copies returns
> bogus return values on (sign_extend:DI (const_int 0)) ).
> The following patch attempts to fix this by using two different define_insns
> for each, one that accepts everything but VOIDmode operands (i.e. usually
> register, memory, some SYMBOL_REFs/LABEL_REFs/CONSTs where we do have mode),
> one that accepts only CONST_INTs. Hopefully at least the combiner will
> canonicalize the potential (sign_extend:DI (const_int N)) into
> just (const_int N) and thus the *v<mode>4_1 insns would match (plus the
> expander expands it that way too).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, tested with
> i686-linux --with-build-config=bootstrap-ubsan bootstrap. Ok for trunk?
It looks to me that you will also need a corresponding predicate,
similar to x86_64_zext_operand that rejects sign-extended VOIDmode
operands where We constraint is used. That will also solve the problem
with combiner, which will be prohibited from combining VOIDmode
operands.
Also, please use curly braces in multi-line preparation statements.
Uros,.
