On Thu, Jan 23, 2014 at 3:16 PM, Jan Hubicka wrote:
>> > * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
>> > for generic and recent AMD chips
>>
>> The ChangeLog reads:
>>
>> 2014-01-22 Jan Hubicka
>>
>> * config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGO
On Thu, Feb 06, 2014 at 06:25:16PM +0100, Jan Hubicka wrote:
> > The expr.[ch]/function.h/tree-tailcall.c bits are ok.
> > I see your changes clash with my PR60077 fix, does your patch make them
> > obsolete and you take care of using proper alignment info?
> > If so, at least the two tests from th
> On Thu, Feb 06, 2014 at 06:06:41PM +0100, Jan Hubicka wrote:
> > > Hi,
> > > this is improved patch I am testing. The basic idea is to remove push
> > > expanders for cases where we do not have push instruction anyway.
> > > emit_move_insns then resorts to unconditonally call move expander
> > >
On Thu, Feb 06, 2014 at 06:06:41PM +0100, Jan Hubicka wrote:
> > Hi,
> > this is improved patch I am testing. The basic idea is to remove push
> > expanders for cases where we do not have push instruction anyway.
> > emit_move_insns then resorts to unconditonally call move expander
> > with push o
> Hi,
> this is improved patch I am testing. The basic idea is to remove push
> expanders for cases where we do not have push instruction anyway.
> emit_move_insns then resorts to unconditonally call move expander
> with push operand. I expended ix86_expand_vector_move to handle
> it gracefully a
On Thu, Jan 30, 2014 at 10:28 AM, Jakub Jelinek wrote:
> On Wed, Jan 29, 2014 at 04:27:48PM +0100, Richard Biener wrote:
>> Actually best would be to avoid generating so many useless values
>> in the first place ... still, quadraticness is a complete no-go.
>
> Filed as PR59992. Though, we have b
On Wed, Jan 29, 2014 at 04:27:48PM +0100, Richard Biener wrote:
> Actually best would be to avoid generating so many useless values
> in the first place ... still, quadraticness is a complete no-go.
Filed as PR59992. Though, we have big issues in other parts of the compiler
too, before managing t
On Wed, Jan 29, 2014 at 4:24 PM, Richard Biener
wrote:
> On Wed, Jan 29, 2014 at 11:02 AM, Jakub Jelinek wrote:
>> On Tue, Jan 28, 2014 at 07:26:47AM +0100, Jakub Jelinek wrote:
>>> > I wonder if this is just some of --enable-checking tests in dwarf2out
>>> > going wild
>>> > or if it is just ex
On Wed, Jan 29, 2014 at 11:02 AM, Jakub Jelinek wrote:
> On Tue, Jan 28, 2014 at 07:26:47AM +0100, Jakub Jelinek wrote:
>> > I wonder if this is just some of --enable-checking tests in dwarf2out
>> > going wild
>> > or if it is just expensive sanity checking code?
>> > I used to have chroot envir
On Wed, Jan 29, 2014 at 11:02:05AM +0100, Jakub Jelinek wrote:
> So, most of the time seems to be spent in cselib.c remove_useless_values
> (both from Ctrl-C in gdb profiling, and callgrind). For callgrind I've
> actually built 64-bit cc1plus with --enable-checking=release, and still
> compiled
>
On Tue, Jan 28, 2014 at 07:26:47AM +0100, Jakub Jelinek wrote:
> > I wonder if this is just some of --enable-checking tests in dwarf2out going
> > wild
> > or if it is just expensive sanity checking code?
> > I used to have chroot environment for 32bit builds, I will need to
> > re-install it now
On Tue, Jan 28, 2014 at 12:56:28AM +0100, Jan Hubicka wrote:
> > On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote:
> > > > Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we
> > > > have separate tunables for 32-bit and 64-bit code)?
> > > > I admit I haven't perf
> On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote:
> > > Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we
> > > have separate tunables for 32-bit and 64-bit code)?
> > > I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing
> > > x86_64 and
On Mon, Jan 27, 2014 at 2:19 PM, Jakub Jelinek wrote:
> On Fri, Jan 24, 2014 at 10:11:20PM +0100, Jakub Jelinek wrote:
>> On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote:
>> > * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
>> > for generic and recent AMD c
On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote:
> > Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we
> > have separate tunables for 32-bit and 64-bit code)?
> > I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing
> > x86_64 and i686 boot
On Fri, Jan 24, 2014 at 10:11:20PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote:
> > * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
> > for generic and recent AMD chips
> > Index: config/i386/x86-tune.def
> > ===
> On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote:
> > * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
> > for generic and recent AMD chips
> > Index: config/i386/x86-tune.def
> > ===
> > --- co
On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote:
> * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
> for generic and recent AMD chips
> Index: config/i386/x86-tune.def
> ===
> --- config/i38
On Thu, Jan 23, 2014 at 4:54 PM, Jan Hubicka wrote:
>> This piece code is wrong for x32:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59929
>
> Though an independent bug ;)
>>
>> I am testing:
>>
>> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
>> index ddc3be6..92e8fd0 10064
> This piece code is wrong for x32:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59929
Though an independent bug ;)
>
> I am testing:
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index ddc3be6..92e8fd0 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i38
On Thu, Jan 23, 2014 at 4:39 PM, Jan Hubicka wrote:
> Hi,
> this is improved patch I am testing. The basic idea is to remove push
> expanders for cases where we do not have push instruction anyway.
> emit_move_insns then resorts to unconditonally call move expander
> with push operand. I expende
Hi,
this is improved patch I am testing. The basic idea is to remove push
expanders for cases where we do not have push instruction anyway.
emit_move_insns then resorts to unconditonally call move expander
with push operand. I expended ix86_expand_vector_move to handle
it gracefully and for that
> > * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
> > for generic and recent AMD chips
>
> The ChangeLog reads:
>
> 2014-01-22 Jan Hubicka
>
> * config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGOING_ARGS):
> Enable for generic and recent AMD tar
> * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
> for generic and recent AMD chips
The ChangeLog reads:
2014-01-22 Jan Hubicka
* config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGOING_ARGS):
Enable for generic and recent AMD targets.
Very co
24 matches
Mail list logo
