On Wed, 19 Sep 2018, Richard Biener wrote:
>
> The second testcase in the above PR runs into our O(N) bitmap element
> search limitation and spends 8s (60%) of the compile-time in the SSA
> propagator
> engine (when optimizing). The patch improves that to 0.9s (15%). For the
> first testcase
On Wed, 19 Sep 2018, Steven Bosscher wrote:
> On Wed, Sep 19, 2018 at 3:06 PM Richard Biener wrote:
> > If we'd only had a O(log n) search sparse bitmap implementation ...
> > (Steven posted patches to switch bitmap from/to such one but IIRC
> > that at least lacked bitmap_first_set_bit).
>
>
On Wed, Sep 19, 2018 at 3:06 PM Richard Biener wrote:
> If we'd only had a O(log n) search sparse bitmap implementation ...
> (Steven posted patches to switch bitmap from/to such one but IIRC
> that at least lacked bitmap_first_set_bit).
But bitmap_first_set_bit would be easy to implement. Just
On Wed, 19 Sep 2018, Jakub Jelinek wrote:
> On Wed, Sep 19, 2018 at 03:06:30PM +0200, Richard Biener wrote:
> >
> > The second testcase in the above PR runs into our O(N) bitmap element
> > search limitation and spends 8s (60%) of the compile-time in the SSA
> > propagator
> > engine (when
On Wed, Sep 19, 2018 at 03:06:30PM +0200, Richard Biener wrote:
>
> The second testcase in the above PR runs into our O(N) bitmap element
> search limitation and spends 8s (60%) of the compile-time in the SSA
> propagator
> engine (when optimizing). The patch improves that to 0.9s (15%). For
The second testcase in the above PR runs into our O(N) bitmap element
search limitation and spends 8s (60%) of the compile-time in the SSA propagator
engine (when optimizing). The patch improves that to 0.9s (15%). For the
first testcase it isn't that bad but still the patch improves CCP from
On Wed, 18 Mar 2015, Richard Biener wrote:
On March 18, 2015 4:59:30 PM GMT+01:00, Alan Lawrence alan.lawre...@arm.com
wrote:
Following this patch (r221318), we're seeing what appears to be a
miscompile of
glibc on AArch64. This causes quite a bunch of tests to fail, segfaults
etc., if
Following this patch (r221318), we're seeing what appears to be a miscompile of
glibc on AArch64. This causes quite a bunch of tests to fail, segfaults etc., if
LD_LIBRARY_PATH leads to a libc.so.6 built with that patch vs without (same
glibc sources). We are still working on a reduced
On March 18, 2015 4:59:30 PM GMT+01:00, Alan Lawrence alan.lawre...@arm.com
wrote:
Following this patch (r221318), we're seeing what appears to be a
miscompile of
glibc on AArch64. This causes quite a bunch of tests to fail, segfaults
etc., if
LD_LIBRARY_PATH leads to a libc.so.6 built with
On Wed, Mar 18, 2015 at 8:59 AM, Alan Lawrence alan.lawre...@arm.com wrote:
Following this patch (r221318), we're seeing what appears to be a miscompile
of glibc on AArch64. This causes quite a bunch of tests to fail, segfaults
etc., if LD_LIBRARY_PATH leads to a libc.so.6 built with that patch
On Mon, 9 Mar 2015, Richard Biener wrote:
On Fri, 6 Mar 2015, Jeff Law wrote:
On 03/06/15 06:16, Richard Biener wrote:
This fixes PR63155 and reduces the memory usage at -O0 from reported
10GB (couldn't verify/update on my small box) to 350MB (still worse
compared to 4.8 which
On 03/09/15 03:42, Richard Biener wrote:
On Fri, 6 Mar 2015, Jeff Law wrote:
On 03/06/15 06:16, Richard Biener wrote:
This fixes PR63155 and reduces the memory usage at -O0 from reported
10GB (couldn't verify/update on my small box) to 350MB (still worse
compared to 4.8 which needs only
On 03/09/15 07:01, Richard Biener wrote:
Ok, like the following which adds a verify_ssa_coalescing () function
(which could in theory be called from IL verification like verify_ssa)
and calls it when ENABLE_CHECKING is defined.
Bootstrap regtest running on x86_64-unknown-linux-gnu.
It didn't
On Fri, 6 Mar 2015, Jeff Law wrote:
On 03/06/15 06:16, Richard Biener wrote:
This fixes PR63155 and reduces the memory usage at -O0 from reported
10GB (couldn't verify/update on my small box) to 350MB (still worse
compared to 4.8 which needs only 50MB).
It fixes this by no longer
This fixes PR63155 and reduces the memory usage at -O0 from reported
10GB (couldn't verify/update on my small box) to 350MB (still worse
compared to 4.8 which needs only 50MB).
It fixes this by no longer computing live info or building a conflict
graph for coalescing of SSA names flowing over
On 03/06/15 06:16, Richard Biener wrote:
This fixes PR63155 and reduces the memory usage at -O0 from reported
10GB (couldn't verify/update on my small box) to 350MB (still worse
compared to 4.8 which needs only 50MB).
It fixes this by no longer computing live info or building a conflict
graph
16 matches
Mail list logo
