On Tue, 10 Feb 2015, Jeff Law wrote:
> I think the way to go is to always convert the inner operands to an unsigned
> type. In fact, everything except the outer convert should be using an
> unsigned type of the same size/precision as @0's type. The outer convert
> should, of course, be the final
On Wed, Feb 11, 2015 at 08:56:20AM -0700, Jeff Law wrote:
> On 02/11/15 04:16, Richard Biener wrote:
> >>
> >>Application of this pattern (and the one I posted for 47477) is a concern
> >>for targets that don't do sub-word arithmetic/logicals. But I just did a
> >>sniff test of one such target (v8
On 02/11/15 04:16, Richard Biener wrote:
Application of this pattern (and the one I posted for 47477) is a concern
for targets that don't do sub-word arithmetic/logicals. But I just did a
sniff test of one such target (v850-elf because it was handy) and I couldn't
spot a change in the end code
On Wed, Feb 11, 2015 at 7:43 AM, Jeff Law wrote:
> On 02/03/15 05:23, Joseph Myers wrote:
>>
>>
>>> +&& TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE
>>> (@1))
>>> +&& TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE
>>> (@1))
>>> +&& TYPE_PRECISION
On 02/03/15 05:23, Joseph Myers wrote:
+&& TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1))
+&& TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE (@1))
+&& TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0)))
+ (convert (bit_and (inner
On 02/09/15 06:42, Richard Biener wrote:
On Mon, Feb 9, 2015 at 8:15 AM, Jeff Law wrote:
On 02/03/15 04:39, Richard Biener wrote:
I found that explicit types were ignored in some cases. It was
frustrating to say the least.
Huh, that would be a bug. Do you have a pattern where that happen
On Mon, Feb 9, 2015 at 8:15 AM, Jeff Law wrote:
> On 02/03/15 04:39, Richard Biener wrote:
>>>
>>> I found that explicit types were ignored in some cases. It was
>>> frustrating to say the least.
>>
>>
>> Huh, that would be a bug. Do you have a pattern where that happens?
>
> I'll have to recrea
On 02/03/15 04:39, Richard Biener wrote:
I found that explicit types were ignored in some cases. It was
frustrating to say the least.
Huh, that would be a bug. Do you have a pattern where that happens?
I'll have to recreate them. In the mean time consider something else
I'm playing with tha
On 02/03/15 05:23, Joseph Myers wrote:
On Tue, 3 Feb 2015, Jeff Law wrote:
+/* Given a bit-wise operation performed in mode P1 on operands
+ in some narrower type P2 that feeds an outer masking operation.
+ See if the mask turns off all the bits outside P2, and if so
+ perform the all the
On Tue, 3 Feb 2015, Jeff Law wrote:
> +/* Given a bit-wise operation performed in mode P1 on operands
> + in some narrower type P2 that feeds an outer masking operation.
> + See if the mask turns off all the bits outside P2, and if so
> + perform the all the operations in P2 and just convert
On February 2, 2015 7:32:15 PM CET, Jeff Law wrote:
>On 02/02/15 01:57, Richard Biener wrote:
>>>
>>> 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 the
On 02/02/15 11:04, Jeff Law wrote:
On 02/02/15 09:59, Joseph Myers wrote:
On Sat, 31 Jan 2015, Jeff Law wrote:
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
On 02/02/15 01:57, Richard Biener wrote:
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 b
On 02/02/15 09:59, Joseph Myers wrote:
On Sat, 31 Jan 2015, Jeff Law wrote:
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
On Sat, 31 Jan 2015, Jeff Law wrote:
> 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
On Sun, Feb 1, 2015 at 6:46 AM, Jeff Law 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 teste
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 o
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.
So I've gone round and round with BZ39726.
The basic idea here is we have an operation on widened operands that
feeds a narrow comparison. ie, the two inputs are QImode, extended to
SImode, subtracted, then we want to conditionally branch on the result
of sign bit of QImode.
If we could ju
19 matches
Mail list logo
