On Mon, Sep 25, 2017 at 7:14 PM, Prathamesh Kulkarni
wrote:
> On 18 September 2017 at 15:40, Prathamesh Kulkarni
> wrote:
>> On 15 September 2017 at 22:09, Marc Glisse wrote:
>>> On Fri, 15 Sep 2017, Wilco Dijkstra wrote:
>>>
Marc Glisse wrote:
> The question is whether, having com
On 18 September 2017 at 15:40, Prathamesh Kulkarni
wrote:
> On 15 September 2017 at 22:09, Marc Glisse wrote:
>> On Fri, 15 Sep 2017, Wilco Dijkstra wrote:
>>
>>> Marc Glisse wrote:
>>>
The question is whether, having computed c=a/b, it is cheaper to test a>>> or c!=0.
I think it is usu
Richard Sandiford wrote:
> I don't think it's literally always. Testing the inputs instead of a
> multi-use result tends to mean that all three are live at once. If the
> == 0 condition is only one component of a more complex condition that
> relies on the result of division regardless, then it'
On 15 September 2017 at 22:09, Marc Glisse wrote:
> On Fri, 15 Sep 2017, Wilco Dijkstra wrote:
>
>> Marc Glisse wrote:
>>
>>> The question is whether, having computed c=a/b, it is cheaper to test a>> or c!=0.
>>> I think it is usually the second one, but not for all types on all
>>> targets. Altho
Wilco Dijkstra writes:
> Marc Glisse wrote:
>
>> The question is whether, having computed c=a/b, it is cheaper to test
>> a> I think it is usually the second one, but not for all types on all
>> targets. Although since
>> you mention VRP, it is easier to do further optimizations using the
>> infor
On Fri, 15 Sep 2017, Wilco Dijkstra wrote:
Marc Glisse wrote:
The question is whether, having computed c=a/b, it is cheaper to test a
No, a
This would indicate that we do not need to check for single-use, makes the
patch simpler, thanks.
(let's ignore -Os)
--
Marc Glisse
Marc Glisse wrote:
> The question is whether, having computed c=a/b, it is cheaper to test a c!=0.
> I think it is usually the second one, but not for all types on all targets.
> Although since
> you mention VRP, it is easier to do further optimizations using the
> information a
On 09/15/2017 09:55 AM, Marc Glisse wrote:
> On Fri, 15 Sep 2017, Jeff Law wrote:
>
>> On 09/15/2017 07:09 AM, Marc Glisse wrote:
>>> On Fri, 15 Sep 2017, Prathamesh Kulkarni wrote:
>>>
>>> +/* (X / Y) == 0 -> X < Y if X, Y are unsigned. */
>>> +(simplify
>>> + (eq (trunc_div @0 @1) integer_zero
On Fri, 15 Sep 2017, Jeff Law wrote:
On 09/15/2017 07:09 AM, Marc Glisse wrote:
On Fri, 15 Sep 2017, Prathamesh Kulkarni wrote:
+/* (X / Y) == 0 -> X < Y if X, Y are unsigned. */
+(simplify
+ (eq (trunc_div @0 @1) integer_zerop)
+ (if (TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TY
On 09/15/2017 07:09 AM, Marc Glisse wrote:
> On Fri, 15 Sep 2017, Prathamesh Kulkarni wrote:
>
> +/* (X / Y) == 0 -> X < Y if X, Y are unsigned. */
> +(simplify
> + (eq (trunc_div @0 @1) integer_zerop)
> + (if (TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE (@1)))
> +(lt @0 @1)))
On Fri, 15 Sep 2017, Prathamesh Kulkarni wrote:
+/* (X / Y) == 0 -> X < Y if X, Y are unsigned. */
+(simplify
+ (eq (trunc_div @0 @1) integer_zerop)
+ (if (TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE (@1)))
+(lt @0 @1)))
+
+/* (X / Y) != 0 -> X >= Y, if X, Y are unsigned. */
Hi,
This patch adds the transforms mentioned in $subject.
Bootstrap+test in progress on x86_64-unknown-linux-gnu.
OK to commit if passes ?
Thanks,
Prathamesh
2017-09-15 Prathamesh Kulkarni
* match.pd ((X / Y) == 0 -> X < Y): New pattern.
((X / Y) != 0 -> X >= Y): Likewise.
tes
12 matches
Mail list logo