Hi HJ,
The last-year patch is currently almost useless, as efforts needed for
its rebase seem to be almost the same as efforts needed for writing it
from scratch. I hoped to make a patch covering at least subset of
cases, but unfortunately haven't had time even for it yet.
What time do we have
On Mon, Dec 12, 2011 at 6:02 AM, Jan Hubicka hubi...@ucw.cz wrote:
Any update?
I will look into it today, but anyway I think it is stage1 material, so we
have some time to progress on it.
Honza
Hi Honza,
The old patch was reverted and the new patch was posted at
On Mon, Dec 12, 2011 at 6:02 AM, Jan Hubicka hubi...@ucw.cz wrote:
Any update?
I will look into it today, but anyway I think it is stage1 material, so we
have some time to progress on it.
Honza
Hi Honza,
The old patch was reverted and the new patch was posted at
Any update?
On 5 December 2011 15:14, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi Jan,
I debugged the changes, and I think I've hunted down all the bugs.
I slightly refactored the code - now all new SSE-related code is more
localized. Also, I fixed some alignment issues.
Any update?
I will look into it today, but anyway I think it is stage1 material, so we have
some time to progress on it.
Honza
On Wed, Nov 23, 2011 at 3:32 PM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
I found and fixed another problem in the latest memcpy/memest changes
- with this fix all the failing tests mentioned in #51134 started
passing. Bootstraps are also ok.
Though I still see fails in
On Wed, Nov 23, 2011 at 3:32 PM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
I found and fixed another problem in the latest memcpy/memest changes
- with this fix all the failing tests mentioned in #51134 started
passing. Bootstraps are also ok.
Though I still see fails in 32-bit
I found and fixed another problem in the latest memcpy/memest changes
- with this fix all the failing tests mentioned in #51134 started
passing. Bootstraps are also ok.
Though I still see fails in 32-bit make check, so probably, it'd be
better to revert the changes till these fails are fixed.
On
Hi,
Continuing investigation of fails on bootstrap I found next problem
(besides the problem with unknown alignment described above): there is
a mess with size_needed and epilogue_size_needed when we generate
epilogue loop which also use SSE-moves, but no unrolled - that's
probably the reason of
I found another bug in current implementation. A patch for it doesn't
cure i686-linux- bootstrap, but fixes fails on some tests (see
attached).
The problem was that we tried to add runtime tests for alignment even
if both SRC and DST had unknown alignment - in this case it could be
impossible to
I found another bug in current implementation. A patch for it doesn't
cure i686-linux- bootstrap, but fixes fails on some tests (see
attached).
The problem was that we tried to add runtime tests for alignment even
if both SRC and DST had unknown alignment - in this case it could be
Given that x86 memset/memcpy is still broken, I think we should revert
it for now.
Well, looking into the code, the SSE alignment issues needs work - the
alignment test merely tests whether some alignmnet is known not whether 16 byte
alignment is known that is the cause of failures in 32bit
On Mon, Nov 14, 2011 at 3:48 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is hopefully final variant of patch. The epilogue code was broken in
some
scenarios for memset, but should work safely now. I also fixed the tables
The current x86 memset/memcpy expansion is broken. It miscompiles
many programs, including GCC itself. Should it be reverted for now?
There was problem in the new code doing loopy epilogues.
I am currently testing the following patch that shold fix the problem.
We could either revert now and
The current x86 memset/memcpy expansion is broken. It miscompiles
many programs, including GCC itself. Should it be reverted for now?
There was problem in the new code doing loopy epilogues.
I am currently testing the following patch that shold fix the problem.
We could either revert
The current x86 memset/memcpy expansion is broken. It miscompiles
many programs, including GCC itself. Should it be reverted for now?
There was problem in the new code doing loopy epilogues.
I am currently testing the following patch that shold fix the problem.
We could either
Looks like we have a bootstrap issue, thus sorry if may message may appear
stupid nitpicking: why Zolotukhin Michael instead of Michael Zolotukhin in
the ChangeLog? Is Michael the family name?
Michael is the first name, Zolotukhin - last name. I probably swapped
them accidentally in the
On 11/15/2011 04:12 PM, Michael Zolotukhin wrote:
Looks like we have a bootstrap issue, thus sorry if may message may appear
stupid nitpicking: why Zolotukhin Michael instead of Michael Zolotukhin in the
ChangeLog? Is Michael the family name?
Michael is the first name, Zolotukhin - last name.
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is hopefully final variant of patch. The epilogue code was broken in some
scenarios for memset, but should work safely now. I also fixed the tables for
core/buldozer/amdfam10 chips.
But before it can be comitted, we
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is hopefully final variant of patch. The epilogue code was broken in
some
scenarios for memset, but should work safely now. I also fixed the tables
for
core/buldozer/amdfam10 chips.
But before it can be
2011/11/14 Jan Hubicka hubi...@ucw.cz:
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is hopefully final variant of patch. The epilogue code was broken in
some
scenarios for memset, but should work safely now. I also fixed the tables
for
On 14 Nov 2011, at 20:36, H.J. Lu wrote:
2011/11/14 Jan Hubicka hubi...@ucw.cz:
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is hopefully final variant of patch. The epilogue code was
broken in some
scenarios for memset, but should work safely now. I also
On Mon, Nov 14, 2011 at 12:40 PM, Iain Sandoe
develo...@sandoe-acoustics.co.uk wrote:
On 14 Nov 2011, at 20:36, H.J. Lu wrote:
2011/11/14 Jan Hubicka hubi...@ucw.cz:
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is hopefully final variant of patch. The
Hi,
2011-11-14 Zolotukhin Michael michael.v.zolotuk...@gmail.com
Jan Hubicka j...@suse.cz
Zolotukhin Michael works for Intel and has copyright assignment with FSF.
Looks like we have a bootstrap issue, thus sorry if may message may appear
stupid nitpicking: why Zolotukhin
On 14 Nov 2011, at 20:44, H.J. Lu wrote:
On Mon, Nov 14, 2011 at 12:40 PM, Iain Sandoe
develo...@sandoe-acoustics.co.uk wrote:
On 14 Nov 2011, at 20:36, H.J. Lu wrote:
2011/11/14 Jan Hubicka hubi...@ucw.cz:
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka hubi...@ucw.cz
wrote:
Hi,
this
bootstrap completed on i686-darwin9, so I've applied the following as
requested,
Thank you and my apologizes for the breakage!
Honza
Iain
gcc:
2011-11-14 Jan Hubicka j...@suse.cz
* config/i386/i386.c (core cost model): Correct pasto.
ndex: gcc/config/i386/i386.c
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is hopefully final variant of patch. The epilogue code was broken in some
scenarios for memset, but should work safely now. I also fixed the tables for
core/buldozer/amdfam10 chips.
But before it can be comitted, we
27 matches
Mail list logo
