On 06/30/2015 01:45 AM, Richard Biener wrote:
On Mon, Jun 29, 2015 at 7:51 PM, Jeff Law wrote:
So do we want to restrict the new pattern on GENERIC, then rely on
phiopt to get smarter and catch this stuff for GIMPLE? Or drop the
pattern totally and do everything in phiopt on GIMPLE?
Note th
On Mon, Jun 29, 2015 at 7:51 PM, Jeff Law wrote:
> On 06/01/2015 04:55 AM, Richard Biener wrote:
>>
>> On Sat, May 30, 2015 at 11:11 AM, Marc Glisse
>> wrote:
>>>
>>> (only commenting on the technique, not on the transformation itself)
>>>
+(simplify
+ (cond @0 (convert @1) INTEGER_CST
On Mon, Jun 29, 2015 at 3:12 PM, Marc Glisse wrote:
> On Mon, 29 Jun 2015, Jeff Law wrote:
>
>>> That said - for this kind of patterns testcases that exercise the
>>> patterns
>>> on GIMPLE would be very appreciated.
>>
>> It may be the case that these patterns don't make a lot of sense on gimple
On Mon, 29 Jun 2015, Jeff Law wrote:
That said - for this kind of patterns testcases that exercise the patterns
on GIMPLE would be very appreciated.
It may be the case that these patterns don't make a lot of sense on gimple
and should be restricted to generic, at least with our current
infrast
On 06/01/2015 04:55 AM, Richard Biener wrote:
On Sat, May 30, 2015 at 11:11 AM, Marc Glisse wrote:
(only commenting on the technique, not on the transformation itself)
+(simplify
+ (cond @0 (convert @1) INTEGER_CST@2)
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
+ && COMPARISON_CLASS_P (@0
On Tue, Jun 2, 2015 at 7:33 PM, Jeff Law wrote:
> On 06/01/2015 05:07 AM, Richard Biener wrote:
>>>
>>> +(simplify
>>> + (cond @0 (convert @1) INTEGER_CST@2)
>>> + (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
>>> + && COMPARISON_CLASS_P (@0)
>>> + && int_fits_type_p (@2, TREE_TYPE (@1))
>>>
On 06/01/2015 04:55 AM, Richard Biener wrote:
On Sat, May 30, 2015 at 11:11 AM, Marc Glisse wrote:
(only commenting on the technique, not on the transformation itself)
+(simplify
+ (cond @0 (convert @1) INTEGER_CST@2)
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
+ && COMPARISON_CLASS_P (@0
On 06/01/2015 05:07 AM, Richard Biener wrote:
+(simplify
+ (cond @0 (convert @1) INTEGER_CST@2)
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
+ && COMPARISON_CLASS_P (@0)
+ && int_fits_type_p (@2, TREE_TYPE (@1))
+ && ((operand_equal_p (TREE_OPERAND (@0, 0), @2, 0)
+ && op
On 05/30/2015 02:33 AM, Bernhard Reutner-Fischer wrote:
On May 30, 2015 6:22:59 AM GMT+02:00, Jeff Law wrote:
+/* { dg-final { cleanup-tree-dump "original" } } */
Please drop this cleanup dg-final, trunk now does this automatically.
Yea, figured that'd need to be fixed up after your cleanups.
On Sat, May 30, 2015 at 6:22 AM, Jeff Law wrote:
>
> I was working on polishing some of Kai's work to eliminate shorten_compare
> and stumbled on this tiny missed optimization.
>
> Basically this change allows us to see something like this:
>
>n = (short unsigned int) mode_size[(unsigned int)
On Sat, May 30, 2015 at 11:11 AM, Marc Glisse wrote:
> (only commenting on the technique, not on the transformation itself)
>
>> +(simplify
>> + (cond @0 (convert @1) INTEGER_CST@2)
>> + (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
>> + && COMPARISON_CLASS_P (@0)
>
>
> If you add COMPARISON_CLASS
(only commenting on the technique, not on the transformation itself)
+(simplify
+ (cond @0 (convert @1) INTEGER_CST@2)
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
+ && COMPARISON_CLASS_P (@0)
If you add COMPARISON_CLASS_P to define_predicates, you could write:
(cond COMPARISON_CLASS_P@0 (c
On May 30, 2015 6:22:59 AM GMT+02:00, Jeff Law wrote:
+/* { dg-final { cleanup-tree-dump "original" } } */
Please drop this cleanup dg-final, trunk now does this automatically.
Thanks,
I was working on polishing some of Kai's work to eliminate
shorten_compare and stumbled on this tiny missed optimization.
Basically this change allows us to see something like this:
n = (short unsigned int) mode_size[(unsigned int) mode] * 8 <= 64 ?
(int) ((short unsigned int) mode_size[(
14 matches
Mail list logo
