Hello,
In the new target I'm working on there are branch regs and gprs.
The loads and store instructions are only to/from the gprs, so if a
branch reg needs to be spilled it first needs to be moved to a gpr and
then stored to memory. I've implemented mov pattern in the machine
description file f
Hi,
someone told me that generated files should be not included in patches. It
would be nice if this is mentioned at
http://gcc.gnu.org/contribute.html
Have a nice day!
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80
On 24 June 2010 12:34, Sebastian Huber
wrote:
> Hi,
>
> someone told me that generated files should be not included in patches. It
> would be nice if this is mentioned at
>
> http://gcc.gnu.org/contribute.html
>
> Have a nice day!
Yes, it would be nice. Unfortunately, I know by experience that i
On 06/24/10 02:02, Revital1 Eres wrote:
Hello,
In the new target I'm working on there are branch regs and gprs.
The loads and store instructions are only to/from the gprs, so if a
branch reg needs to be spilled it first needs to be moved to a gpr and
then stored to memory. I've implemented mov
(I wrote:)
> > Can we similarly promise or say something for accesses of the
> > containing struct as a whole?
No takers?
> Date: Wed, 23 Jun 2010 11:34:04 -0400
> From: DJ Delorie
> Should be the same as before, I would think.
Primarily I want them similarly defined. I wasn't expecting
thos
On Thu, 2010-06-24 at 08:57 -0600, Jeff Law wrote:
> On 06/24/10 02:02, Revital1 Eres wrote:
> > Hello,
> >
> > In the new target I'm working on there are branch regs and gprs.
> > The loads and store instructions are only to/from the gprs, so if a
> > branch reg needs to be spilled it first needs
Hi,
Just wanted to give a heads up on what might be the biggest
compiler-upgrade-related performance difference we've seen at Mozilla.
We switched gcc4.3 for gcc4.5 and our automated benchmarking
infrastructure reported 4-19% slowdown on most of our performance
metrics on 32 and 64bit Linux.
On Jun 24, 2010, at 11:50 AM, Taras Glek wrote:
Hi,
Just wanted to give a heads up on what might be the biggest compiler-
upgrade-related performance difference we've seen at Mozilla.
We switched gcc4.3 for gcc4.5 and our automated benchmarking
infrastructure reported 4-19% slowdown on
On 6/24/10 3:06 PM, Andrew Pinski wrote:
Most of the code is compiled with -fPIC -fno-rtti -fno-exceptions -Os
Stop right there. You are compiling at -Os, that is tuned for size and
not speed. So the question is did the size go down? Not the speed
decreased. Try at -O2 and report back. I doubt
> In addition, it appears at first glance that GCC is either no longer
> inlining at -Os, even when it would be a size advantage to do so, or is
> making some very poor inlining choices.
>
> e.g. +72 nsTArray::nsTArray(nsTArray const&)
>
> We can turn some of these observations into bug report
On Thu, Jun 24, 2010 at 10:24 PM, Eric Botcazou wrote:
>> In addition, it appears at first glance that GCC is either no longer
>> inlining at -Os, even when it would be a size advantage to do so, or is
>> making some very poor inlining choices.
>>
>> e.g. +72 nsTArray::nsTArray(nsTArray const
Snapshot gcc-4.5-20100624 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100624/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 25/06/10 06:39, Richard Guenther wrote:
> There are btw. some bugs wrt accounting of functions called once
> being inlined in 4.5 which were fixed on trunk which allow extra
> inlining.
>
Are these changes likely to make it onto the 4.5 branch and into (say)
4.5.1?
j.
> Minus whitespace changes it seems to be
>
> ! if (lhs_free && (is_gimple_reg (rhs) ||
> is_gimple_min_invariant (rhs)))
> rhs_free = true;
>
> vs.
>
> ! if (lhs_free
> ! && (is_gimple_reg (rhs)
> ! || !is_gimple_reg_type (TREE_TYPE
14 matches
Mail list logo
