On Fri, Mar 01, 2019 at 12:19:36AM +0100, Eric Botcazou wrote:
> > I know Eric has committed a tweak here, but I view this magic handling as
> > something meant for boolean types only (if it is correct at all and the
> > right fix wouldn't be avoid the BIT_NOT_EXPR for the prec > 1 booleans, I
> > believe the expansion of BIT_NOT_EXPR doesn't have any special case for
> > BOOLEAN_TYPE). This patch just restores previous behavior for non-boolean
> > types (basically inlines the first two cases from ssa_name_has_boolean_range
> > while leaving the problematic third one out, normal integral types with
> > just known value range of [0,1]).
>
> IMO you haven't justified why this is problematic in the BIT_NOT_EXPR case
> and
> not in the BIT_AND_EXPR case...
The BIT_AND_EXPR case is clearly correct for all possible values. The code
says that if the result of BIT_AND_EXPR is known to be a non-zero constant,
and one or both of the BIT_AND_EXPR arguments have known value ranges [0,1]
(or boolean or precision 1, not talking about those now), then that value
with the [0,1] range actually had to be 1, otherwise BIT_AND_EXPR result
would be 0.
The BIT_NOT_EXPR case is different, ~0 is -1 and ~1 is -2. If an SSA_NAME
has [0,1] range, then BIT_NOT_EXPR of that will be [-2,-1]. If value is one
of those two, then with your today's patch the assumption will be correct, 1
or 0. If value is some other one, which should hopefully happen only in dead
code that we haven't been able to optimize, then we'd replace different values
though.
Jakub
