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 for
On Fri, Aug 31, 2012 at 1:54 AM, Jan Hubicka wrote:
>> On Mon, Dec 12, 2011 at 6:02 AM, Jan Hubicka 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 p
> On Mon, Dec 12, 2011 at 6:02 AM, Jan Hubicka 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
>
> http://
On Mon, Dec 12, 2011 at 6:02 AM, Jan Hubicka 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
http://gcc.gnu.org/ml/gcc-patches
> 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
Any update?
On 5 December 2011 15:14, Michael Zolotukhin
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.
> Please find the new patch in t
> On Wed, Nov 23, 2011 at 3:32 PM, Michael Zolotukhin
> 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 make check, so
On Wed, Nov 23, 2011 at 3:32 PM, Michael Zolotukhin
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 make check, so probably, it
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 2
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 t
> 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 bo
On Fri, Nov 18, 2011 at 6:18 AM, Jan Hubicka wrote:
>> 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 an
> 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
> i
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 m
> > >
> > > 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.
> >
> >
> > 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 eithe
>
> 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 a
On Mon, Nov 14, 2011 at 3:48 PM, H.J. Lu wrote:
> On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka 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
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.
> 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 cha
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka 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 need to
> 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
>
> * config/i386/i386.c (core cost model): Correct pasto.
>
> ndex: gcc/config/i386/i386.c
> =
On 14 Nov 2011, at 20:44, H.J. Lu wrote:
On Mon, Nov 14, 2011 at 12:40 PM, Iain Sandoe
wrote:
On 14 Nov 2011, at 20:36, H.J. Lu wrote:
2011/11/14 Jan Hubicka :
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka
wrote:
Hi,
this is hopefully final variant of patch. The epilogue code was
b
Hi,
2011-11-14 Zolotukhin Michael
Jan Hubicka
>>>
>>> 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 Michael instead of Mi
On Mon, Nov 14, 2011 at 12:40 PM, Iain Sandoe
wrote:
>
> On 14 Nov 2011, at 20:36, H.J. Lu wrote:
>
>> 2011/11/14 Jan Hubicka :
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka wrote:
>
> Hi,
> this is hopefully final variant of patch. The epilogue code was broken
> in some
On 14 Nov 2011, at 20:36, H.J. Lu wrote:
2011/11/14 Jan Hubicka :
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka 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/bu
2011/11/14 Jan Hubicka :
>> On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka 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 c
> On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka 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
On Mon, Nov 14, 2011 at 9:03 AM, Jan Hubicka 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 need to
29 matches
Mail list logo
