This would indicate that simplify-rtx inside fwprop is removing OR Rx,0
but not picking up the the additionally revealed forward propagation
oppertunities
This would seem to be an avoidable limitation.
Yes, can you send me your MD patch and a simple testcase? fwprop is
supposed to be "cas
> -Original Message-
> From: Joe Buck [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 20, 2008 3:31 PM
> To: Tim Prince
> Cc: Joel Sherrill; Tobias Burnus; GCC
> Subject: Re: RFC: GCC 4.4 criteria - add Fortran as primary language?
>
> Maybe there could be a "semi-primary" or "ex
[adding fortran list to CC]
According to the GCC 4.4 Release Criteria,
http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary
languages. And thus only C and C++ regressions can be release
critical.
I propose to add Fortran to these languages.
My first thought is does gfortran
I tried extra fwprop pass and got some very interesting results!
First "caveat" I just cut/pasted extra pass into list - nor worrying
about detail.
NEXT_PASS (pass_rtl_fwprop);
NEXT_PASS (pass_local_alloc);
To show effects here is assembler code dump (which is easier to read
than R
fwprop is a good suggestion. If that also simplifes substitutions, it
may be the magic bullet to collapse all of the code. I will try latter
tonite.
-Original Message-
From: Paolo Bonzini <[EMAIL PROTECTED]>
To: Andy H <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; gcc@g
Joe Buck wrote:
On Wed, Feb 20, 2008 at 02:27:27PM -0800, Tim Prince wrote:
Joel Sherrill wrote:
Tobias Burnus wrote:
According to the GCC 4.4 Release Criteria,
http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary
languages. And thus only C and C++ regressions can be release cr
Snapshot gcc-4.2-20080220 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080220/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Joe Buck wrote:
On Wed, Feb 20, 2008 at 02:27:27PM -0800, Tim Prince wrote:
Joel Sherrill wrote:
Tobias Burnus wrote:
According to the GCC 4.4 Release Criteria,
http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary
languages. And thus only C and C++ regressions ca
On Wed, Feb 20, 2008 at 02:27:27PM -0800, Tim Prince wrote:
> Joel Sherrill wrote:
> >Tobias Burnus wrote:
> >>According to the GCC 4.4 Release Criteria,
> >>http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary
> >>languages. And thus only C and C++ regressions can be release critic
Joel Sherrill wrote:
Tobias Burnus wrote:
According to the GCC 4.4 Release Criteria,
http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary
languages. And thus only C and C++ regressions can be release critical.
I propose to add Fortran to these languages. Reasons:
- Fortran is r
Tobias Burnus wrote:
According to the GCC 4.4 Release Criteria,
http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary
languages. And thus only C and C++ regressions can be release critical.
I propose to add Fortran to these languages. Reasons:
- Fortran is relatively widely used;
Hi,
> Michael, Jan,
>
> When aligning stack for those functions who have dynamic stack
> allocation, we must use an available callee-saved register in prologue.
> We named this hard register DRAP. It is worthwhile to emphasize that
> *free* here means "free in prologue". After prologue, a virtual
Splitters on MovMM are problematic.
One problem is that it creates issues with base pointers. AVR base
pointer are limited to 64 byte offsets - after that they are inline
additions (and perhaps subtractions). So splitting such a move in a
large mode is a world of hurt. A future endeavour perha
Yes - the other approach is to lower at RTL expand.
Unfortunately there is no practical way to lower arithmetic and compare
operations. reload can add arithmetic which messes the "carry"
handling attempts. So we end up with mixed higher level and lower level
RTL.
This mixture then causes ot
On 20 February 2008 18:05, [EMAIL PROTECTED] wrote:
> But it does seem that the missing piece is effective constant
> propagation + simplification after splits and subregs - which is
> currently ineffective in local-alloc (or any later pass)
Hmm, more questions: do you use splitters or insns
[EMAIL PROTECTED] wrote:
I still have to try extra fwprop pass to confirm this solves the issue.
But it does seem that the missing piece is effective constant
propagation + simplification after splits and subregs - which is
currently ineffective in local-alloc (or any later pass)
Adding extr
Dave Korn wrote:
On 20 February 2008 16:34, Jeff Law wrote:
Paolo Bonzini wrote:
Is there any particular function or pass that should be dealing with
IOR rx,0 - that I could trace thru and figure out why it does not
like it (or never gets there)?
I would be looking in combine and simplify-rtx
I still have to try extra fwprop pass to confirm this solves the issue.
But it does seem that the missing piece is effective constant
propagation + simplification after splits and subregs - which is
currently ineffective in local-alloc (or any later pass)
Adding extra pass indeed seems a po
On 20 February 2008 16:34, Jeff Law wrote:
> Paolo Bonzini wrote:
>>
Is there any particular function or pass that should be dealing with
IOR rx,0 - that I could trace thru and figure out why it does not
like it (or never gets there)?
>>> I would be looking in combine and simplify-
Paolo Bonzini wrote:
Propagating REG_EQUIV notes across register-register moves would seem
to a obviously simple way to fix this. Thoughts?
I am not sure local-alloc is the best place to address the overall
problem, I doubt it is intended to provide such optimizations.
An additional cse pass
Paolo Bonzini wrote:
Is there any particular function or pass that should be dealing with
IOR rx,0 - that I could trace thru and figure out why it does not
like it (or never gets there)?
I would be looking in combine and simplify-rtx (which is called by
combine). If your splitter triggers af
> "Philipp" == Philipp Marek <[EMAIL PROTECTED]> writes:
Philipp> I'm looking for a nice solution.
I think this note is off-topic for the gcc list. gcc-help may be more
appropriate.
Philipp> - I could try #define C(x) uncompress(buffer##__LINE__) and
Philipp> write some script that looks fo
On 19/02/2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
> Hello All,
>
> On my MELT branch http://gcc.gnu.org/wiki/MiddleEndLispTranslator
> I committed some code with badly formatted (really free form) logs.
>
> How can I correct the logs now to put them in ChangeLog format?
I don't thi
On Tue, Feb 19, 2008 at 05:44:27PM -0800, Janis Johnson wrote:
> On Mon, 2008-02-18 at 18:18 -0500, Jakub Jelinek wrote:
> > As I've mentioned last week, I've created branches/gcc-4_3-branch.
> > The trunk is now 4.4 stage 1, the branch is open for regression bugfixes
> > and documentation fixes on
According to the GCC 4.4 Release Criteria,
http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary
languages. And thus only C and C++ regressions can be release critical.
I propose to add Fortran to these languages. Reasons:
- Fortran is relatively widely used; while C/C++ is wide
On Feb 20, 2008 10:15 AM, Danny Smith <[EMAIL PROTECTED]> wrote:
>
> On Feb 20, 2008 10:02 PM, Danny Smith <[EMAIL PROTECTED]> wrote:
> > On Feb 18, 2008 10:59 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > >
> > > gcc/ChangeLog:
> > > 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
> > >
> >
On Feb 20, 2008 10:02 PM, Danny Smith <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 10:59 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> >
> > gcc/ChangeLog:
> > 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
> >
> > PR bootstrap/35218
> > * Makefile.in (build_file_translate): Ne
On Feb 18, 2008 10:59 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> gcc/ChangeLog:
> 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
>
> PR bootstrap/35218
> * Makefile.in (build_file_translate): New.
> (gcc-vers.texi): Use it for translating $(abs_srcdir).
> *
Propagating REG_EQUIV notes across register-register moves would seem
to a obviously simple way to fix this. Thoughts?
I am not sure local-alloc is the best place to address the overall
problem, I doubt it is intended to provide such optimizations.
An additional cse pass after split would see
As I understand it (perhaps wrongly), actual splitting only occurs
after combine pass (by split1 pass).
Combine has some limited splitting capabilities. For example it can
try to combine 3 insns, which might not match a pattern, but can match
a splitter which generates 2 insns. I don't recall
Is there any particular function or pass that should be dealing with
IOR rx,0 - that I could trace thru and figure out why it does not like
it (or never gets there)?
I would be looking in combine and simplify-rtx (which is called by
combine). If your splitter triggers after combine, then I'm
Hello everybody,
I'm looking for a nice solution.
One of my programs has a lot of strings in it; about 20% of binary size, or
something like that. Now most of them are rarely used - error messages
like "Cannot write to file", "No space left while allocating memory", etc.
I tried to compress ju
32 matches
Mail list logo
