Richard Biener wrote:
>
> >
> >>
> >> On the llvm test-suite, I have seen one ICE with my fsm jump-thread
> >patch.
> >> This patch fixes the problem:
> >>
> >> diff --git a/gcc/tree-ssa-threadupdate.c
> >b/gcc/tree-ssa-threadupdate.c
> >> index 12f83ba..f8c736e 100644
> >> --- a/gcc/tree-ssa-thre
On Dec 9, 2014, at 10:39 AM, Jeff Law wrote:
> Also, a test for the GCC testsuite would be good. I have no idea what
> license covers the LLVM testsuite. But given a good analysis of the problem
> we may be able to write a suitable test independent of the LLVM test.
So, the usual engineerings
On 12/09/14 12:43, Richard Biener wrote:
This seems to be indicating that we have with no edge from the latch
block to the header block. I'd like to know better how we got into
that
state.
It Also returns null for loops with multiple latches. So the patch looks OK for
me.
Ah, OK.
Jeff
On December 9, 2014 7:39:48 PM CET, Jeff Law wrote:
>On 12/09/14 10:38, Sebastian Pop wrote:
>> Richard Biener wrote:
>>> On Mon, Dec 8, 2014 at 10:49 PM, Steve Ellcey
>wrote:
expected? Should this test also check flag_thread_jumps? Or
>should
that be getting checked somewhere else?
>
On 12/09/14 10:38, Sebastian Pop wrote:
Richard Biener wrote:
On Mon, Dec 8, 2014 at 10:49 PM, Steve Ellcey wrote:
expected? Should this test also check flag_thread_jumps? Or should
that be getting checked somewhere else?
-fthread-jumps is an RTL optimization flag and ignored on GIMPLE.
Richard Biener wrote:
> On Mon, Dec 8, 2014 at 10:49 PM, Steve Ellcey wrote:
> > expected? Should this test also check flag_thread_jumps? Or should
> > that be getting checked somewhere else?
>
> -fthread-jumps is an RTL optimization flag and ignored on GIMPLE.
Does it make sense to add a -f[n
On Mon, Dec 8, 2014 at 10:49 PM, Steve Ellcey wrote:
> On Sat, 2014-12-06 at 19:21 +, Sebastian Pop wrote:
>
>> > I think it does not make sense to duplicate paths at -Os: I disabled the
>> > FSM
>> > jump-threading when optimizing for size like this.
>> >
>> > diff --git a/gcc/tree-ssa-threa
On Sat, 2014-12-06 at 19:21 +, Sebastian Pop wrote:
> > I think it does not make sense to duplicate paths at -Os: I disabled the FSM
> > jump-threading when optimizing for size like this.
> >
> > diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
> > index 29b20c8..ce70311 100
On 12/06/14 06:47, Sebastian Pop wrote:
Jeff Law wrote:
OK to commit. Thanks for your patience.
Can you follow-up with a change which throttles this optimization
when -Os is in effect. You can check optimize_function_for_size_p
(cfun) and simply avoid the backward traversal or you could allow
Sebastian Pop wrote:
> Jeff Law wrote:
> > OK to commit. Thanks for your patience.
> >
> > Can you follow-up with a change which throttles this optimization
> > when -Os is in effect. You can check optimize_function_for_size_p
> > (cfun) and simply avoid the backward traversal or you could allow
Jeff Law wrote:
> OK to commit. Thanks for your patience.
>
> Can you follow-up with a change which throttles this optimization
> when -Os is in effect. You can check optimize_function_for_size_p
> (cfun) and simply avoid the backward traversal or you could allow it
> in that case if the amount
On 12/04/14 07:29, Sebastian Pop wrote:
Sebastian Pop wrote:
Jeff Law wrote:
I'm a bit worried about compile-time impacts of the all the
recursion
I will also restrict the recursion to the loop in which we look for the FSM
thread.
The attached patch includes this change. It passed bootstra
On 12/04/14 02:14, Sebastian Pop wrote:
Sebastian Pop wrote:
a fail I have not seen in the past:
FAIL: gcc.c-torture/compile/pr27571.c -Os (internal compiler error)
I am still investigating why this fails: as far as I can see for now this is
because in copying the FSM path we create an inte
Sebastian Pop wrote:
> Jeff Law wrote:
> > I'm a bit worried about compile-time impacts of the all the
> > recursion
>
> I will also restrict the recursion to the loop in which we look for the FSM
> thread.
The attached patch includes this change. It passed bootstrap and regression
test on x86_6
Jeff Law wrote:
> I'm a bit worried about compile-time impacts of the all the
> recursion
I will also restrict the recursion to the loop in which we look for the FSM
thread, like this:
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index a6fb361..9a153bb 100644
--- a/gcc/tree-
Sebastian Pop wrote:
> Sebastian Pop wrote:
> > a fail I have not seen in the past:
> >
> > FAIL: gcc.c-torture/compile/pr27571.c -Os (internal compiler error)
> >
> > I am still investigating why this fails: as far as I can see for now this is
> > because in copying the FSM path we create an
Sebastian Pop wrote:
> a fail I have not seen in the past:
>
> FAIL: gcc.c-torture/compile/pr27571.c -Os (internal compiler error)
>
> I am still investigating why this fails: as far as I can see for now this is
> because in copying the FSM path we create an internal loop that is then
> discov
Jeff Law wrote:
> >+@item max-fsm-thread-path-insns
> >+Maximum number of instructions to copy when duplicating blocks on a
> >+finite state automaton jump thread path. The default is 100.
> >+
> >+@item max-fsm-thread-length
> >+Maximum number of basic blocks on a finite state automaton jump thre
On 12/02/14 03:15, Richard Biener wrote:
I'm a bit worried about compile-time impacts of the all the recursion, but
I'm willing to wait and see if it turns out to be a problem in practice.
Please consider restricting it to -fexpensive-optimizations (-O2+).
Yea, let's go ahead and do that.
je
On Mon, Dec 1, 2014 at 10:06 PM, Jeff Law wrote:
> On 11/25/14 14:16, Sebastian Pop wrote:
>>
>> Sebastian Pop wrote:
>>>
>>> >I will bootstrap and regression test this patch on x86_64-linux and
>>> >powerpc64-linux. I will also run it on our internal benchmarks,
>>> > coremark, and
>>> >the llvm
On 11/25/14 14:16, Sebastian Pop wrote:
Sebastian Pop wrote:
>I will bootstrap and regression test this patch on x86_64-linux and
>powerpc64-linux. I will also run it on our internal benchmarks, coremark, and
>the llvm test-suite.
>
>I will also include a longer testcase that makes sure we do n
Sebastian Pop wrote:
> I will bootstrap and regression test this patch on x86_64-linux and
> powerpc64-linux. I will also run it on our internal benchmarks, coremark, and
> the llvm test-suite.
>
> I will also include a longer testcase that makes sure we do not regress on
> coremark.
Done all th
Jeff Law wrote:
> On 11/24/14 21:55, Jeff Law wrote:
> >On 11/24/14 18:09, Sebastian Pop wrote:
> >>Sebastian Pop wrote:
> >>>I removed the return -1 and started a bootstrap on powerpc64-linux.
> >>
> >>Bootstrap passed on top of the 4 previous patches on powerpc64-linux.
> >>
> >>>I will report th
On 11/24/14 21:55, Jeff Law wrote:
On 11/24/14 18:09, Sebastian Pop wrote:
Sebastian Pop wrote:
I removed the return -1 and started a bootstrap on powerpc64-linux.
Bootstrap passed on top of the 4 previous patches on powerpc64-linux.
I will report the valgrind output.
The output from valg
On 2014.11.24 at 22:05 +, Sebastian Pop wrote:
> I got my scripts installed on the gcc-farm. I first used an x86_64 gcc75 and
> valgrind was crashing not recognizing how to decode an instruction. Then I
> moved to gcc112 a powerpc64-linux where I got this data from stage2 cc1plus
> compiling
On Mon, Nov 24, 2014 at 11:05 PM, Sebastian Pop wrote:
> Jeff Law wrote:
>> On 11/23/14 15:22, Sebastian Pop wrote:
>> >The second patch attached limits the search for FSM jump threads to loops.
>> >With
>> >that patch, we are now down to 470 jump threads in an x86_64-linux bootstrap
>> >(and 42
On 11/24/14 18:09, Sebastian Pop wrote:
Sebastian Pop wrote:
I removed the return -1 and started a bootstrap on powerpc64-linux.
Bootstrap passed on top of the 4 previous patches on powerpc64-linux.
I will report the valgrind output.
The output from valgrind looks closer to the output of m
Sebastian Pop wrote:
> I removed the return -1 and started a bootstrap on powerpc64-linux.
Bootstrap passed on top of the 4 previous patches on powerpc64-linux.
> I will report the valgrind output.
The output from valgrind looks closer to the output of master with no other
patches: still 1M more
Jeff Law wrote:
> On 11/23/14 15:22, Sebastian Pop wrote:
> >Jeff Law wrote:
> >>>PS: I have run some perf analysis with the patch:
> >>>- on a bootstrap of GCC I see 3209 FSM jump threads
> >>>- libpng and libjpeg contain FSM jump threads, the perf increase is in the
> >>>1%
> >>> (measured on
On 11/23/14 15:22, Sebastian Pop wrote:
Jeff Law wrote:
PS: I have run some perf analysis with the patch:
- on a bootstrap of GCC I see 3209 FSM jump threads
- libpng and libjpeg contain FSM jump threads, the perf increase is in the 1%
(measured on simulators and reduced data sets)
- coremark
On 11/24/14 15:05, Sebastian Pop wrote:
I did an experiment around these lines over the week-end, and now that you
mention it, I feel less shy to speak about; well the patch does not yet pass
bootstrap, and there still are about 20 failing test-cases. I feel better
reading the code generation p
Sebastian Pop wrote:
> > Using a SEME region copier is also something I really wanted to do
> > long term. In fact, I believe a lot of tree-ssa-threadupdate.c
> > ought to be ripped out and replaced with a SEME based copier.
>
> I did an experiment around these lines over the week-end, and now th
Jeff Law wrote:
> On 11/23/14 15:22, Sebastian Pop wrote:
> >The second patch attached limits the search for FSM jump threads to loops.
> >With
> >that patch, we are now down to 470 jump threads in an x86_64-linux bootstrap
> >(and 424 jump threads on powerpc64-linux bootstrap.)
> >
> Yea, that w
On 11/23/14 15:22, Sebastian Pop wrote:
The second patch attached limits the search for FSM jump threads to loops. With
that patch, we are now down to 470 jump threads in an x86_64-linux bootstrap
(and 424 jump threads on powerpc64-linux bootstrap.)
Yea, that was one of the things I was going t
Jeff Law wrote:
> >PS: I have run some perf analysis with the patch:
> >- on a bootstrap of GCC I see 3209 FSM jump threads
> >- libpng and libjpeg contain FSM jump threads, the perf increase is in the 1%
> > (measured on simulators and reduced data sets)
> >- coremark gets jump threaded (as expe
On 11/18/14 15:19, Sebastian Pop wrote:
The regions that we duplicate start inside a loop and stay inside the same loop,
and the jump threading path is not allowed to go in deeper nested loops.
The reason why we need to modify the sese duplication function is that the sese
region that we need to
On 10/26/14 15:34, Sebastian Pop wrote:
I have tried to understand why the code generation part ICEs on coremark: the
first problem that I have seen is that tree-ssa-threadupdate.c does not handle
more than a joiner block per path to be threaded, so we would not be able to
jump thread accross th
Richard Biener wrote:
> On Tue, Nov 11, 2014 at 2:14 AM, Sebastian Pop wrote:
> > Hi Jeff,
> >
> > I have adapted the code generation part from James' patch to current trunk,
> > and
> > the resulting patch gets the 30% speedup on coremark and passes bootstrap
> > of GCC.
> >
> > Ok for trunk?
>
On 11/18/14 12:25, Steve Ellcey wrote:
On Mon, 2014-11-17 at 09:24 +, James Greenhalgh wrote:
For what it is worth, I've bootstrapped and tested this patch on
aarch64-none-linux-gnu and arm-none-linux-gnueabi with no issues, and
both targets get the expected speedup in the interesting bench
On Mon, 2014-11-17 at 09:24 +, James Greenhalgh wrote:
> For what it is worth, I've bootstrapped and tested this patch on
> aarch64-none-linux-gnu and arm-none-linux-gnueabi with no issues, and
> both targets get the expected speedup in the interesting benchmark.
> I've also thrown some of the
On Tue, Nov 11, 2014 at 2:14 AM, Sebastian Pop wrote:
> Hi Jeff,
>
> I have adapted the code generation part from James' patch to current trunk,
> and
> the resulting patch gets the 30% speedup on coremark and passes bootstrap of
> GCC.
>
> Ok for trunk?
In addition to missing documentation for
On Tue, Nov 11, 2014 at 01:14:04AM +, Sebastian Pop wrote:
> Hi Jeff,
>
> I have adapted the code generation part from James' patch to current trunk,
> and
> the resulting patch gets the 30% speedup on coremark and passes bootstrap of
> GCC.
For what it is worth, I've bootstrapped and teste
Hi Jeff,
I have adapted the code generation part from James' patch to current trunk, and
the resulting patch gets the 30% speedup on coremark and passes bootstrap of
GCC.
Ok for trunk?
Thanks,
Sebastian
Sebastian Pop wrote:
> Sebastian Pop wrote:
> > Jeff Law wrote:
> > > On 08/21/14 04:30, Ri
Sebastian Pop wrote:
> Jeff Law wrote:
> > On 08/21/14 04:30, Richard Biener wrote:
> > >>It turns Jeff's jump-threading code in to a strange franken-pass of bits
> > >>and
> > >>pieces of detection and optimisation, and would need some substantial
> > >>reworking to fit in with Jeff's changes las
44 matches
Mail list logo
