On May 12, 2016 6:02:47 PM GMT+02:00, Marc Glisse wrote:
>On Thu, 12 May 2016, Richard Biener wrote:
>
>> Yeah - note that VRP already calls set_range_info before simplifying
>> stmts. It's just that substitute_and_fold doesn't apply fold_stmt
>(and
>> thus match.pd) to all stmts but it only ap
On Thu, 12 May 2016, Richard Biener wrote:
Yeah - note that VRP already calls set_range_info before simplifying
stmts. It's just that substitute_and_fold doesn't apply fold_stmt (and
thus match.pd) to all stmts but it only applies the pass specific "fold"
(vrp_fold_stmt) to all stmts.
Just
On Wed, May 11, 2016 at 7:56 PM, Marc Glisse wrote:
> On Wed, 11 May 2016, Jeff Law wrote:
>
>>> We could also simplify (int)(_Bool)x to x using VRP information that x
>>> is in [0, 1], but apparently when VRP replaces x==0 with y=x^1,(_Bool)y,
>>> it does not compute a range for the new variable
On Wed, 11 May 2016, Jeff Law wrote:
On 05/11/2016 10:17 AM, Marc Glisse wrote:
The transformation seems right to me, but we are then missing another
transformation like ~X & Y -> X ^ Y when we know that X & ~Y is 0 (the 1
bits of X are included in those of Y). That may not be easy with the
lim
On Wed, 11 May 2016, Marc Glisse wrote:
We could also use set_range_info and make simplify_conversion_using_ranges
use get_range_info instead of get_value_range.
Something like this seems to fix the testcase. I'll try to submit it
properly, but I don't know when. (I also added the ~X&C transf
On Wed, 11 May 2016, Jeff Law wrote:
We could also simplify (int)(_Bool)x to x using VRP information that x
is in [0, 1], but apparently when VRP replaces x==0 with y=x^1,(_Bool)y,
it does not compute a range for the new variable y, and by the time the
next VRP pass comes, it is too late.
Seems
On 05/11/2016 10:17 AM, Marc Glisse wrote:
The transformation seems right to me, but we are then missing another
transformation like ~X & Y -> X ^ Y when we know that X & ~Y is 0 (the 1
bits of X are included in those of Y). That may not be easy with the
limited bit tracking we have. A version li
On Wed, 11 May 2016, H.J. Lu wrote:
* fold-const.c (fold_binary_loc) [(X ^ Y) & Y]: Remove and merge with...
* match.pd ((X & Y) ^ Y): ... this.
It caused:
FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp2 " & 1;" 0
on x86.
Ah, yes, logical_op_short_circuit so I didn
On Mon, May 9, 2016 at 11:11 PM, Marc Glisse wrote:
> On Fri, 6 May 2016, Marc Glisse wrote:
>
>> Here they are. I did (X&Y)&X and (X&Y)&(X&Z). The next one would be
>> ((X&Y)&Z)&X, but at some point we have to defer to reassoc.
>>
>> I didn't add the convert?+tree_nop_conversion_p to the existing
On Tue, May 10, 2016 at 8:11 AM, Marc Glisse wrote:
> On Fri, 6 May 2016, Marc Glisse wrote:
>
>> Here they are. I did (X&Y)&X and (X&Y)&(X&Z). The next one would be
>> ((X&Y)&Z)&X, but at some point we have to defer to reassoc.
>>
>> I didn't add the convert?+tree_nop_conversion_p to the existing
On Fri, 6 May 2016, Marc Glisse wrote:
Here they are. I did (X&Y)&X and (X&Y)&(X&Z). The next one would be
((X&Y)&Z)&X, but at some point we have to defer to reassoc.
I didn't add the convert?+tree_nop_conversion_p to the existing transform I
modified. I guess at some point we should make a p
On Fri, May 6, 2016 at 1:50 PM, Marc Glisse wrote:
> On Tue, 3 May 2016, Richard Biener wrote:
>
>> On Tue, May 3, 2016 at 3:26 PM, Marc Glisse wrote:
>>>
>>> On Tue, 3 May 2016, Richard Biener wrote:
>>>
On Tue, May 3, 2016 at 8:36 AM, Marc Glisse
wrote:
>
>
> This removes
On Fri, 6 May 2016, Marc Glisse wrote:
2016-05-06 Marc Glisse
gcc/
* fold-const.c (fold_binary_loc) [(X ^ Y) & Y]: Remove and merge with...
* match.pd ((X & Y) ^ Y): ... this.
((X & Y) & Y, (X | Y) | Y, (X ^ Y) ^ Y, (X & Y) & (X & Z), (X | Y)
| (X | Z), (X ^ Y
13 matches
Mail list logo
