On Sun, Feb 1, 2015 at 6:46 AM, Jeff Law <l...@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
>
