[RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing

[Richard Biener]

On Sun, Feb 1, 2015 at 6:46 AM, Jeff Law <law@redhat.com> wrote:
> On 01/31/15 17:47, Joseph Myers wrote:
>>
>> On Fri, 30 Jan 2015, Jeff Law wrote:
>>
>>> +/* If we are testing a single bit resulting from a binary
>>> +   operation in precision P1 where the operands were widened
>>> +   precision P2 and the tested bit is the sign bit for
>>> +   precision P2.  Rewrite so the binary operation is in
>>> +   precision P2.  */
>>
>>
>> To avoid introducing undefined behavior, if the operation is arithmetic
>> rather than bitwise and the original type with precision P2 is signed then
>> you need to convert the operands to the corresponding unsigned type.
>
> Yea, probably so.
>
>
>>
>> (I'm not sure how you avoid needing to convert the final result back to
>> the original type of the expression to avoid type mismatches in the
>> containing expression, but such a conversion back to the original type
>> would need to be a zero-extension not a sign-extension and so for that I'd
>> suppose the inner type should be unsigned even for bitwise operations.
>
> So I think the way to go to solve both issues is to wrap the result inside a
> convert.  Right now by working on generic, we're relying on implicit type
> conversions, which feels wrong.
>
> The nice thing about wrapping the result inside a convert is the types for
> the inner operations will propagate from the type of the inner operands,
> which is exactly what we want.  We then remove the hack assigning type and
> instead the original type will be used for the outermost convert.

It's not even a hack but wrong ;)  Correct supported syntax is

+     (with { tree type0 = TREE_TYPE (@0); }
+      (convert:type0 (bit_and (inner_op @0 @1) (convert @3)))))))

Thus whenever the generator cannot auto-guess a type (or would guess
the wrong one) you can explicitely specify a type to convert to.

Why do you restrict this to GENERIC?  On GIMPLE you'd eventually
want to impose some single-use constraints as the result with all
the conversions won't really be unconditionally "better"?

(reminds me of thinking of a nicer way for all this single-use stuff
for next stage1)

> That seems to DTRT in some initial sniff testing.
>
> And FWIW, there's no reason to restrict the pattern to just masking off the
> sign bit.  That's what the PR complains about, but we can do considerably
> better here.  That's part of the reason why I put in the iterators -- to
> generalize this to more cases.

Indeed.

Richard.

> jeff
>