On Tue, Sep 6, 2011 at 9:07 AM, Ilya Enkovich wrote:
> 2011/9/6 Uros Bizjak :
>>
>> OK.
>>
>> Thanks,
>> Uros.
>>
>
> Could please someone check it in for me?
>
I checked it in for you.
--
H.J.
2011/9/6 Uros Bizjak :
>
> OK.
>
> Thanks,
> Uros.
>
Could please someone check it in for me?
Thanks,
Ilya
On Tue, Sep 6, 2011 at 2:39 PM, Ilya Enkovich wrote:
>> I assume that you need to split tune attribute to int and FP part to
>> handle reassociation for other targets, since Atom handles both in the
>> same way.
>>
>> Please also describe function return value in the comment (and perhaps
>> in do
Hello,
2011/9/2 Uros Bizjak :
> I assume that you need to split tune attribute to int and FP part to
> handle reassociation for other targets, since Atom handles both in the
> same way.
>
> Please also describe function return value in the comment (and perhaps
> in documentation, too).
>
> OK with
2011/9/2 Richard Guenther :
> On Fri, Sep 2, 2011 at 3:45 PM, Ilya Enkovich wrote:
>> 2011/9/2 Richard Guenther :
>>>On Fri, Sep 2, 2011 at 2:52 PM, Uros Bizjak wrote:
I assume that you need to split tune attribute to int and FP part to
handle reassociation for other targets, since
On Fri, Sep 2, 2011 at 3:45 PM, Ilya Enkovich wrote:
> 2011/9/2 Richard Guenther :
>>On Fri, Sep 2, 2011 at 2:52 PM, Uros Bizjak wrote:
>>>
>>> I assume that you need to split tune attribute to int and FP part to
>>> handle reassociation for other targets, since Atom handles both in the
>>> same
2011/9/2 Richard Guenther :
>On Fri, Sep 2, 2011 at 2:52 PM, Uros Bizjak wrote:
>>
>> I assume that you need to split tune attribute to int and FP part to
>> handle reassociation for other targets, since Atom handles both in the
>> same way.
>>
>> Please also describe function return value in the
On Fri, Sep 2, 2011 at 2:52 PM, Uros Bizjak wrote:
> On Thu, Sep 1, 2011 at 12:27 PM, Ilya Enkovich wrote:
>>>
>>> this seems to not allow cycles_best to drop with lower width, but
>>> that it can't should be an implementation detail of get_required_cycles.
>>> To make it not so, can you add a co
On Thu, Sep 1, 2011 at 12:27 PM, Ilya Enkovich wrote:
>>
>> this seems to not allow cycles_best to drop with lower width, but
>> that it can't should be an implementation detail of get_required_cycles.
>> To make it not so, can you add a comment before the loop, like
>>
>> /* get_required_cycles
>
> this seems to not allow cycles_best to drop with lower width, but
> that it can't should be an implementation detail of get_required_cycles.
> To make it not so, can you add a comment before the loop, like
>
> /* get_required_cycles is monotonically increasing with lower width
> so we can
On Wed, Aug 31, 2011 at 2:17 PM, Ilya Enkovich wrote:
> Hello Richard,
>
> Thanks for the review!
>
>> The fact that you have to adjust gcc.dg/tree-ssa/pr38533.c looks problematic
>> to me. Can you investigate the problem report, look at the geneated
>> code with the atom default of the param and
Hello Richard,
Thanks for the review!
> The fact that you have to adjust gcc.dg/tree-ssa/pr38533.c looks problematic
> to me. Can you investigate the problem report, look at the geneated
> code with the atom default of the param and see whether it's still
> reasonably "fixed" (maybe you'd alread
On Wed, Aug 10, 2011 at 4:49 PM, Ilya Enkovich wrote:
> Hello,
>
> Here is a new version of the patch. Changes from the previous version
> (http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02240.html):
> - updated to trunk
> - TODO_remove_unused_locals flag was removed from todo_flags_finish
> of re
Double ping.
2011/8/19 Ilya Enkovich :
> Ping.
>
> 2011/8/10 Ilya Enkovich :
>> Hello,
>>
>> Here is a new version of the patch. Changes from the previous version
>> (http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02240.html):
>> - updated to trunk
>> - TODO_remove_unused_locals flag was removed f
Ping.
2011/8/10 Ilya Enkovich :
> Hello,
>
> Here is a new version of the patch. Changes from the previous version
> (http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02240.html):
> - updated to trunk
> - TODO_remove_unused_locals flag was removed from todo_flags_finish
> of reassoc pass
>
> Bootstr
Hello,
Here is a new version of the patch. Changes from the previous version
(http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02240.html):
- updated to trunk
- TODO_remove_unused_locals flag was removed from todo_flags_finish
of reassoc pass
Bootstrapped and checked on x86_64-linux.
Thanks,
Ilya
Hello Richard,
Thanks for reply!
>
> Well, it's enough to delay that to later passes that do this, so I'd prefer
> to not change this in this patch.
>
OK, I'll fix it in next patch version.
> I suppose yes. Maybe the cases are also obsoleted by the improved
> loop PHI handling.
>
I noticed that
On Tue, Jul 19, 2011 at 4:46 PM, Ilya Enkovich wrote:
> Hello Richard,
>
> Thanks a lot for the review!
>
>> it's not easy to follow the flow of this function, esp. I wonder
>>
>> + else
>> + {
>> + tree var = create_tmp_reg (TREE_TYPE (last_rhs1), "reassoc");
>> + add_r
Ping.
2011/7/26 Ilya Enkovich :
> Hello,
>
> Here is updated patch for tree reassoc phase. Update includes coding
> style fixes, comments update, target hook arguments change. I also
> moved a part of code from rewrite_expr_tree into separate function to
> reuse it in rewrite_expr_tree_parallel fo
Hello,
Here is updated patch for tree reassoc phase. Update includes coding
style fixes, comments update, target hook arguments change. I also
moved a part of code from rewrite_expr_tree into separate function to
reuse it in rewrite_expr_tree_parallel for grouping operands with the
same rank.
Boo
On Thu, 14 Jul 2011, Ilya Enkovich wrote:
> * doc/tm.texi.in (reassociation_width): New hook documentation.
Unless the documentation for a new hook is based on pre-existing GFDL-only
text, it should go in target.def not tm.texi.in, with the only thing added
to tm.texi.in being a single @h
Hello Richard,
Thanks a lot for the review!
> it's not easy to follow the flow of this function, esp. I wonder
>
> + else
> + {
> + tree var = create_tmp_reg (TREE_TYPE (last_rhs1), "reassoc");
> + add_referenced_var (var);
> + stmts[i] = build_and_add_sum (var,
On Thu, Jul 14, 2011 at 5:00 PM, Ilya Enkovich wrote:
>> 2011/7/14 Richard Guenther :
>>>
>>> But then how comes the option to override it is useful? It isn't dependent
>>> on the particular case. At least the option should be a --param.
>>>
>>> Richard.
>>>
>>
>> Option is still useful if you w
>
> You need the target hook that tells how big the reassociation based on the
> type. Machines have different numbers of functional units, for example, maybe
> 3 integer units and 2 floating point units. For example, in the PowerPC, I
> would set the basic integer and binary floating point types
On Thu, Jul 14, 2011 at 11:32:59AM +0200, Richard Guenther wrote:
> On Thu, Jul 14, 2011 at 11:31 AM, Richard Guenther
> wrote:
> > 2011/7/14 Michael Meissner :
> >> One minor note, you will need to update doc/invoke.texi to document the new
> >> switch before checkin: -ftree-reassoc-width=
> >
>
> 2011/7/14 Richard Guenther :
>>
>> But then how comes the option to override it is useful? It isn't dependent
>> on the particular case. At least the option should be a --param.
>>
>> Richard.
>>
>
> Option is still useful if you want to try feature on platform with no
> hook implemented and fo
2011/7/14 Richard Guenther :
>
> But then how comes the option to override it is useful? It isn't dependent
> on the particular case. At least the option should be a --param.
>
> Richard.
>
Option is still useful if you want to try feature on platform with no
hook implemented and for other perfo
> One minor note, you will need to update doc/invoke.texi to document the new
> switch before checkin: -ftree-reassoc-width=
>
> --
> Michael Meissner, IBM
Thanks for the note! Here is fixed patch.
Ilya
--
gcc/
2011-07-14 Enkovich Ilya
PR middle-end/44382
* target.def (reasso
On Thu, Jul 14, 2011 at 11:59 AM, Ilya Enkovich wrote:
> 2011/7/14 Richard Guenther :
>>
>> Btw, rather than a new target hook and an option I suggest to use
>> a --param which default you can modify in the backend.
>>
>> Richard.
>>
>
> Introduced target hook does not just define default value fo
2011/7/14 Richard Guenther :
>
> Btw, rather than a new target hook and an option I suggest to use
> a --param which default you can modify in the backend.
>
> Richard.
>
Introduced target hook does not just define default value for option.
It is meant to make decision in each particular case. For
On Thu, Jul 14, 2011 at 11:31 AM, Richard Guenther
wrote:
> 2011/7/14 Michael Meissner :
>> One minor note, you will need to update doc/invoke.texi to document the new
>> switch before checkin: -ftree-reassoc-width=
>
> You also need approval and somebody to review the patch before checkin.
Btw,
2011/7/14 Michael Meissner :
> One minor note, you will need to update doc/invoke.texi to document the new
> switch before checkin: -ftree-reassoc-width=
You also need approval and somebody to review the patch before checkin.
Richard.
> --
> Michael Meissner, IBM
> 5 Technology Place Drive, M/S
One minor note, you will need to update doc/invoke.texi to document the new
switch before checkin: -ftree-reassoc-width=
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
2011/7/13 Michael Meissner :
> I just ran a spec 2006 run on the powerpc (32-bit) last night setting the
> reassociation to 2. I do see a win in bwaves, but unfortunately it is not
> enough of a win, and it is still a regression to GCC 4.5. However, I see some
> regressions in 3 other benchmarks
I just ran a spec 2006 run on the powerpc (32-bit) last night setting the
reassociation to 2. I do see a win in bwaves, but unfortunately it is not
enough of a win, and it is still a regression to GCC 4.5. However, I see some
regressions in 3 other benchmarks (I tend to omit differences of less t
On Tue, 2011-07-12 at 11:50 -0500, William J. Schmidt wrote:
> Ilya, thanks for posting this! This patch is useful also on powerpc64.
> Applying it solved a performance degradation with bwaves due to loss of
> reassociation somewhere between 4.5 and 4.6 (still tracking it down).
> When we apply -f
On Wed, Jul 13, 2011 at 11:18 AM, Ilya Enkovich wrote:
> 2011/7/13 Jakub Jelinek :
>>
>> I disagree. Widening would result in worse code in most cases, as you need
>> to sign extend all the operands. On the other side, I doubt you can
>> actually usefully use the undefinedness of signed overflow
2011/7/13 Jakub Jelinek :
>
> I disagree. Widening would result in worse code in most cases, as you need
> to sign extend all the operands. On the other side, I doubt you can
> actually usefully use the undefinedness of signed overflow for a series of
> 3 or more operands of the associative opera
On Wed, Jul 13, 2011 at 01:01:59PM +0400, Ilya Enkovich wrote:
> > Well, if it is clearly a win to reassociate, you can always reassociate
> > them by doing arithmetics in corresponding unsigned type and afterwards
> > converting back to the signed type.
>
> You are right. But in this case we agai
>
> Well, if it is clearly a win to reassociate, you can always reassociate
> them by doing arithmetics in corresponding unsigned type and afterwards
> converting back to the signed type.
>
> Jakub
>
You are right. But in this case we again make all operands have
wrap-around type and thus d
On Wed, Jul 13, 2011 at 11:52:25AM +0400, Ilya Enkovich wrote:
> > However, it does not fix http://gcc.gnu.org/PR45671, which surprises me
> > as it was marked as a duplicate of this one. Any thoughts on why this
> > isn't sufficient to reassociate the linear chain of adds?
> >
> > Test case:
> >
> Ilya, please mention PR middle-end/44382
> in ChangeLog.
>
Thanks for notice. Here is corrected ChangeLog:
gcc/
2011-07-12 Enkovich Ilya
PR middle-end/44382
* target.def (reassociation_width): New hook.
* doc/tm.texi.in (reassociation_width): New hook documentation.
Hello William,
> However, it does not fix http://gcc.gnu.org/PR45671, which surprises me
> as it was marked as a duplicate of this one. Any thoughts on why this
> isn't sufficient to reassociate the linear chain of adds?
>
> Test case:
>
> int myfunction (int a, int b, int c, int d, int e, int f,
On Tue, 2011-07-12 at 11:50 -0500, William J. Schmidt wrote:
> Ilya, thanks for posting this! This patch is useful also on powerpc64.
> Applying it solved a performance degradation with bwaves due to loss of
> reassociation somewhere between 4.5 and 4.6 (still tracking it down).
> When we apply -f
On Tue, Jul 12, 2011 at 9:50 AM, William J. Schmidt
wrote:
> Ilya, thanks for posting this! This patch is useful also on powerpc64.
> Applying it solved a performance degradation with bwaves due to loss of
> reassociation somewhere between 4.5 and 4.6 (still tracking it down).
> When we apply -ft
Ilya, thanks for posting this! This patch is useful also on powerpc64.
Applying it solved a performance degradation with bwaves due to loss of
reassociation somewhere between 4.5 and 4.6 (still tracking it down).
When we apply -ftree-reassoc-width=2 to bwaves, the more optimal code
generation retu
Hello,
Here is a patch related to missed optimization opportunity in tree
reassoc phase.
Currently tree reassoc phase always generates a linear form which
requires the minimum registers but has the highest tree height and
does not allow computation to be performed in parallel. It may be
critical
47 matches
Mail list logo
