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
46 matches
Mail list logo
