Dynamic macro expansion through a pipe?
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 just the help texts in the binary - and saved 11k
without any other modification.
Now I'd like to wrap that in some magic macro, so that it looks like that:
char *text=C("text");
Then there could be
#if USE_COMPRESSED_TEXT
#define C(x) ...
#else
#define C(x) x
#endif
but that's where I'm stuck.
It's easy to write a function that takes a pointer to some compressed space
and returns a pointer to the uncompressed data (re-entry is no problem).
I don't know how to get the transformation while compiling.
- I could try #define C(x) uncompress(buffer##__LINE__) and write some
script that looks for the C() calls and generates a C file with the
buffer constants - which means parsing (some of) C.
- Or these texts get put in some special segment, that gets compressed into
another before linking, and the original segment gets removed.
- Or, what I'd like best: Is there some way to tell GCC "whenever this
macro is used, call program X, and substitute the macro value with the
output"? That would be the easiest way for me.
Now you might say that it isn't that interesting - just use a compressed
filesystem, or whatever. But these are all different tradeoffs; I'd just
like to reduce the storage (and typical memory) footprint of my application
by storing rarely used data compressed. I'd imagine that other projects
would use that too, if it's easily available - and then the space needed
for a small installation would decrease by some non-trivial amount.
And, not at least, allowing dynamic macro expansion would allow some neat
hacks :-)
Please keep me CC:ed; thank you for all ideas, tips and other feedback.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
Re: Redundant logical operations left after early splitting
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 the other cases where combine splits, nor do I offhand recall if the split insns are ever simplified. Search for "split" in combine.c I think Andy is closer in its description to what actually happens. More precisely: - if you use define_insn_and_split, it can try to combine 3 insns into 1 and later use a splitter to create multiple instruction out of it. But the splits are not simplified. - after combining 3 instructions into 1 (fully simplified), if it does not match it can try to make 2 instructions out of the complex 1 which did not match. See find_split_point. Paolo
Re: Redundant logical operations left after early splitting
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 seem a better way perhaps? You could try adding another fwprop run after splitting. I wouldn't like a third instance of the pass, but it could help. Paolo
Re: Redundant logical operations left after early splitting
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 not
immediately sure where to look -- I'm not offhand aware of a pass
after combine which would call into simplify-rtx to perform this
optimization.
Me neither, but this
if (flag_expensive_optimizations)
{
/* Pass pc_rtx so no substitutions are done, just
simplifications. */
if (i1)
{
subst_low_luid = DF_INSN_LUID (i1);
i1src = subst (i1src, pc_rtx, pc_rtx, 0, 0);
}
else
{
subst_low_luid = DF_INSN_LUID (i2);
i2src = subst (i2src, pc_rtx, pc_rtx, 0, 0);
}
}
could be a place where it is done.
Paolo
Re: bootstrap broken on mingw
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). > * config.build (build_file_translate): Set to `CMD //c' on MinGW. > * configure.ac (build_file_translate): Substitute it. > * configure: Regenerate. > This patch breaks native bootstrap on mingw systems that use cygwin1.dll-dependent bash and development tools. As such, that would be a regression against all versions of gcc since at least 2.95.3 The ' CMD //c' (with 2 slashes preceding the switch rather than the one documented for cmd by Micrsosoft) is a MSYS-ism that causes problems with non-MSYS shells (including the one provided by MS in its SFU package) GCC corrently bootstaps just fine (with or without the earlier abs_srcdir patch) on mingw using the cygwin bash shell, make and configure. Using cygwin shell rather than the MSYS shell means that DejaGnu testsuite can be run. The last time I checked this was not possible. with MSYS. Danny
Re: bootstrap broken on mingw
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]> > > > > > > PR bootstrap/35218 > > > * Makefile.in (build_file_translate): New. > > > (gcc-vers.texi): Use it for translating $(abs_srcdir). > > > * config.build (build_file_translate): Set to `CMD //c' on MinGW. > > > * configure.ac (build_file_translate): Substitute it. > > > * configure: Regenerate. > > > > > > > This patch breaks native bootstrap on mingw systems that use > > cygwin1.dll-dependent bash and development tools. As such, that would > > be a regression against all versions of gcc since at least 2.95.3 > > > > The ' CMD //c' (with 2 slashes preceding the switch rather than the > > one documented for cmd by Micrsosoft) is a MSYS-ism that causes > > problems with non-MSYS shells (including the one provided by MS in > > its SFU package) > > > > > > GCC corrently bootstaps just fine (with or without the earlier > > abs_srcdir patch) on mingw using the cygwin bash shell, make and > > configure. Using cygwin shell rather than the MSYS shell means that > > DejaGnu testsuite can be run. The last time I checked this was not > > possible. with MSYS. > > > > > > I just noticed that this has been committed. Should I open a new bug > report? The use of 'CMD //c' should be restricted to those systems > that understand it. Yes please. Richard.
Re: bootstrap broken on mingw
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): New. > > (gcc-vers.texi): Use it for translating $(abs_srcdir). > > * config.build (build_file_translate): Set to `CMD //c' on MinGW. > > * configure.ac (build_file_translate): Substitute it. > > * configure: Regenerate. > > > > This patch breaks native bootstrap on mingw systems that use > cygwin1.dll-dependent bash and development tools. As such, that would > be a regression against all versions of gcc since at least 2.95.3 > > The ' CMD //c' (with 2 slashes preceding the switch rather than the > one documented for cmd by Micrsosoft) is a MSYS-ism that causes > problems with non-MSYS shells (including the one provided by MS in > its SFU package) > > > GCC corrently bootstaps just fine (with or without the earlier > abs_srcdir patch) on mingw using the cygwin bash shell, make and > configure. Using cygwin shell rather than the MSYS shell means that > DejaGnu testsuite can be run. The last time I checked this was not > possible. with MSYS. > I just noticed that this has been committed. Should I open a new bug report? The use of 'CMD //c' should be restricted to those systems that understand it. > Danny >
RFC: GCC 4.4 criteria - add Fortran as primary language?
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 wider used, distributions and to a lesser users compile also libraries such as BLAS, LAPACK etc. which are written in Fortran - gfortran has few (known;-) regressions. Currently, PR33296 and PR32841. - It is actively maintained - the RM can still downgrade regressions to P4 to P6. Regards, Tobias
Re: GCC 4.3 branch created, 4.4 opens for stage1
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 only, but additionally all checkings require
> > RM approval in addition to normal approval.
> > Before the release candidate is cut, it would be good to fix the 4 P1
> > bugs we have now:
>
> > and:
>
> > ppc-linux -maltivec stuff - assuming a solution is agreed on quickly
>
> See http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00802.html for
> tested version of latest (final?) patch.
If David approves it, ok with me, though perhaps a few words in
gcc-4.3/changes.html about this wouldn't hurt, including a warning that
some vectors are passed as arguments/retval differently depending on if
the chosen -mcpu supports Altivec ISA or not (and depending on
-m{no-}altivec).
Jakub
Re: how to correct logs on my MELT branch?
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 think you can correct logs with the curren svn setup. At least they are not corrected in trunk either when someone makes a mistake. Cheers, Manuel.
Re: Dynamic macro expansion through a pipe?
> "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 for the C() calls and generates Philipp> a C file with the buffer constants - which means parsing Philipp> (some of) C. Aside from the compression this is what xgettext does, more or less. You could modify it to suit your needs. Philipp> - Or, what I'd like best: Is there some way to tell GCC Philipp> "whenever this macro is used, call program X, and substitute Philipp> the macro value with the output"? That would be the easiest Philipp> way for me. This is very unlikely to happen, sorry. Tom
Re: Redundant logical operations left after early splitting
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 after combine, then I'm not
immediately sure where to look -- I'm not offhand aware of a pass
after combine which would call into simplify-rtx to perform this
optimization.
Me neither, but this
if (flag_expensive_optimizations)
{
/* Pass pc_rtx so no substitutions are done, just
simplifications. */
if (i1)
{
subst_low_luid = DF_INSN_LUID (i1);
i1src = subst (i1src, pc_rtx, pc_rtx, 0, 0);
}
else
{
subst_low_luid = DF_INSN_LUID (i2);
i2src = subst (i2src, pc_rtx, pc_rtx, 0, 0);
}
}
could be a place where it is done.
I'm still looking at this, but I don't see much of a chance to attack
this specific problem in the combiner.
I'm thinking this is going to need to be attacked along one of three
lines:
1. Having split_all_insns conditionally run a cleanup pass if
it's likely to be profitable (constant propagation &
rtl simplification)
2. Make local smarter about propagating constants and find
somewhere to simplify to eliminate the nops. Final could
do it much like it used to eliminate nop-moves and the like.
3. Investigate emitting better code in the splitters.
Jeff
RE: Redundant logical operations left after early splitting
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 (which is called by >>> combine). If your splitter triggers after combine, then I'm not >>> immediately sure where to look -- I'm not offhand aware of a pass >>> after combine which would call into simplify-rtx to perform this >>> optimization. >> >> Me neither, but this >> could be a place where it is done. >> > I'm still looking at this, but I don't see much of a chance to attack > this specific problem in the combiner. > > I'm thinking this is going to need to be attacked along one of three > lines: > In the meantime, Andy's quickest and safest option is probably to use peepholes to eliminate the redundant insns altogether, rather than having to replace them with nops. cheers, DaveK -- Can't think of a witty .sigline today
Re: Redundant logical operations left after early splitting
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 after split would seem a better way perhaps? You could try adding another fwprop run after splitting. I wouldn't like a third instance of the pass, but it could help. I think we should at least look at how ugly it would be to do the propagation in local. I don't particularly like either solution -- extending local to do something other passes do quite well is duplication, but adding another pass isn't ideal either. Jeff
Re: Redundant logical operations left after early splitting
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 poor route - BUT this would suggest no need for any constant propagation in local-alloc. Thus avoid duplication of function. As for workaround, Nops are nothing already. I just split the instruction into (const_in 0) and it's gone. The split instruction pattern explicitely match on constant. Peephole would do the same thing - but latter Of course I will also have to add all the other variants that can be created: AND Rx,0 AND Rx,0xff etc Leaving only the limited constant propagation issue. Andy More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com
Re: Redundant logical operations left after early splitting
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 (which is called by combine). If your splitter triggers after combine, then I'm not immediately sure where to look -- I'm not offhand aware of a pass after combine which would call into simplify-rtx to perform this optimization. Me neither, but this could be a place where it is done. I'm still looking at this, but I don't see much of a chance to attack this specific problem in the combiner. I'm thinking this is going to need to be attacked along one of three lines: In the meantime, Andy's quickest and safest option is probably to use peepholes to eliminate the redundant insns altogether, rather than having to replace them with nops. Probably true. Jeff
Re: Redundant logical operations left after early splitting
[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 extra pass indeed seems a poor route - BUT this would suggest no need for any constant propagation in local-alloc. Thus avoid duplication of function. We need to look at the tradeoffs involved -- adding more passes is always possible, but that comes with a cost and it's unclear how many ports are going to benefit and how big those benefits might be. You're going to see this kind of problem raise its ugly head anytime a port chooses keep operations at a higher level early in the RTL optimizers, then lower them to their component operations in the split_all_insns pass. Jeff
RE: Redundant logical operations left after early splitting
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 for your movMM patterns? Do you implement all the movMM patterns? Just checking if we've covered every angle ... cheers, DaveK -- Can't think of a witty .sigline today
Re: Redundant logical operations left after early splitting
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 other miss optimisations - which historically have been very significant but grow less with time. The splitting after combine allows existing optimisations to be kept largely intact. The ports that benefit would be any that split operations - after expand (eg combine onwards). How much - who knows! Unfortunately there is no way a target can hook into pass management to make this more specfic. but I'm still thinking about it! Andy More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com
Re: [discuss] When is RBX used for base pointer?
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 register > will be used instead. I am bit confused here. If I wanted a free register in prologue only, I would probably look at the caller saved ones. But I gues it is just typo. I don't see much value in making the register callee-saved especially if you say that virtual reg (pseudo?) is used afterward. > > Given the definition of free, we can fix the DRAP register to simplify > the implementation. Original GCC only have limited cases that use > callee-saved register in prologue, such as setting GOT pointer as far as > I know. So choosing the DRAP register is easy: just avoid GOT pointer > register, which is EBX in i386 and RBX in x86_64. As HJ said, R12 is a > good candiate. When you just need a temporary in prologue, I think you can go with RAX in most cases getting shortest code. It is used by x86-64 stdargs prologue and by i386 regparm. You can improve bit broken ix86_eax_live_at_start_p to test this. Using alternative choice if RAX is taken. > > It will be more complicated if GOT pointer register is not fixed. In > this case, the DRAP candidate must be avoid using GOT register, or vice > versa. When will current GCC decide the register to use as GOT pointer? See ix86_select_alt_pic_regnum it is done in prologue too. There are few cases 64bit prologues needs temporary already. (when stack frame is gigantic). I never attempted to optimize those at all, but if you will have more cureful way of chosing temporary around, you might consider looking for cases R11_REG is used and update them. Honza > > Thanks - Joey
Re: Redundant logical operations left after early splitting
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 perhaps may solve this - but for now, it's on the "too difficult pile" I dont think it is relevant here. The missing optimisation of the testcase is more closely related to the arithmetic than to the moves. The output move is already "split" by subreg lowering. After that there are not any pure large mode moves of significance left. Other (non move) splitters can create moves - but these are small and will not be split further. Andy -Original Message- From: Dave Korn <[EMAIL PROTECTED]> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: gcc@gcc.gnu.org Sent: Wed, 20 Feb 2008 2:15 pm Subject: RE: Redundant logical operations left after early splitting 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 for your movMM patterns? Do you implement all the movMM patterns? Just checking if we've covered every angle ... cheers, DaveK -- Can't think of a witty .sigline today More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com
Re: RFC: GCC 4.4 criteria - add Fortran as primary language?
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; while C/C++ is wider used, distributions and to a lesser users compile also libraries such as BLAS, LAPACK etc. which are written in Fortran - gfortran has few (known;-) regressions. Currently, PR33296 and PR32841. My first thought is does gfortran support and have similarly good test results on all primary and secondary platforms. - It is actively maintained - the RM can still downgrade regressions to P4 to P6. Regards, Tobias -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: RFC: GCC 4.4 criteria - add Fortran as primary language?
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 relatively widely used; while C/C++ is wider used, distributions and to a lesser users compile also libraries such as BLAS, LAPACK etc. which are written in Fortran - gfortran has few (known;-) regressions. Currently, PR33296 and PR32841. My first thought is does gfortran support and have similarly good test results on all primary and secondary platforms. How would anyone judge this, except by referring to gcc-testresults? gfortran developers have cleared up a number of secondary platform problems whose counterparts have been allowed to remain in the "primary" language. In my experience, this supports the "actively maintained" point.
Re: RFC: GCC 4.4 criteria - add Fortran as primary language?
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 critical. > >> > >>I propose to add Fortran to these languages. Reasons: > >> > >>- Fortran is relatively widely used; while C/C++ is wider used, > >>distributions and to a lesser users compile also libraries such as BLAS, > >>LAPACK etc. which are written in Fortran > >> > >>- gfortran has few (known;-) regressions. Currently, PR33296 and > >>PR32841. > >> > >My first thought is does gfortran support and have > >similarly good test results on all primary and secondary > >platforms. > How would anyone judge this, except by referring to gcc-testresults? > gfortran developers have cleared up a number of secondary platform > problems whose counterparts have been allowed to remain in the "primary" > language. In my experience, this supports the "actively maintained" point. Maybe there could be a "semi-primary" or "experimental primary" status; a feature could be treated as primary, but with the understanding that the requirement will be waived if it causes excessive delay. The "experimental" label could be dropped after a few successful releases.
gcc-4.2-20080220 is now available
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/gcc-4_2-branch revision 132498 You'll find: gcc-4.2-20080220.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080220.tar.bz2 C front end and core compiler gcc-ada-4.2-20080220.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080220.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080220.tar.bz2 C++ front end and runtime gcc-java-4.2-20080220.tar.bz2 Java front end and runtime gcc-objc-4.2-20080220.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080220.tar.bz2The GCC testsuite Diffs from 4.2-20080213 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: RFC: GCC 4.4 criteria - add Fortran as primary language?
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 critical. I propose to add Fortran to these languages. Reasons: - Fortran is relatively widely used; while C/C++ is wider used, distributions and to a lesser users compile also libraries such as BLAS, LAPACK etc. which are written in Fortran - gfortran has few (known;-) regressions. Currently, PR33296 and PR32841. My first thought is does gfortran support and have similarly good test results on all primary and secondary platforms. How would anyone judge this, except by referring to gcc-testresults? gfortran developers have cleared up a number of secondary platform problems whose counterparts have been allowed to remain in the "primary" language. In my experience, this supports the "actively maintained" point. Maybe there could be a "semi-primary" or "experimental primary" status; a feature could be treated as primary, but with the understanding that the requirement will be waived if it causes excessive delay. The "experimental" label could be dropped after a few successful releases. What is the real purpose of being a primary language? In practice, the release managers seem to give quite a bit of weight to regressions in non-primary languages. As long as the Fortran maintainers continue their good work, we will have excellent Fortran support on many of GCC's targets. The only benefit I can really see is that it makes good PR (Public Relations). gcj and libgcj, in my opinion, are in similarly good shape. Should java be made a primary language as well? Many of the same arguments would apply. Also there are several 'Primary Platforms' that are bare-metal elf targets. How well does gfortran run on those? I am not against changing gfortran's status, I am just trying to understand what the real benefits would be. David Daney
Re: RFC: GCC 4.4 criteria - add Fortran as primary language?
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 critical. I propose to add Fortran to these languages. Reasons: - Fortran is relatively widely used; while C/C++ is wider used, distributions and to a lesser users compile also libraries such as BLAS, LAPACK etc. which are written in Fortran - gfortran has few (known;-) regressions. Currently, PR33296 and PR32841. My first thought is does gfortran support and have similarly good test results on all primary and secondary platforms. How would anyone judge this, except by referring to gcc-testresults? gfortran developers have cleared up a number of secondary platform problems whose counterparts have been allowed to remain in the "primary" language. In my experience, this supports the "actively maintained" point. Maybe there could be a "semi-primary" or "experimental primary" status; a feature could be treated as primary, but with the understanding that the requirement will be waived if it causes excessive delay. The "experimental" label could be dropped after a few successful releases. I think that sounds reasonable. This won't be the last language, library, etc that will want to move up in status. --joel -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Redundant logical operations left after early splitting
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@gcc.gnu.org Sent: Wed, 20 Feb 2008 3:26 am Subject: Re: Redundant logical operations left after early splitting 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 seem a better way perhaps? You could try adding another fwprop run after splitting. I wouldn't like a third instance of the pass, but it could help. Paolo More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com
Re: Redundant logical operations left after early splitting
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 RTL) (1)Just splitters - normal passes for O3 - no attempt to remove Or rx,0 (without splitters its almost 2x bigger) 23 /* prologue: function */ 24 /* frame size = 0 */ 25 FC01 movw r30,r24 26 .LM2: 27 0002 9181 ldd r25,Z+1 28 0004 80E0 ldi r24,lo8(0) 29 .LVL1: 30 0006 60E0 ldi r22,lo8(0) 31 0008 2281 ldd r18,Z+2 32 000a 30E0 ldi r19,lo8(0) 33 000c 6060 ori r22,lo8(0) 34 000e 762F mov r23,r22 35 0010 822B or r24,r18 36 0012 932B or r25,r19 37 0014 2481 ldd r18,Z+4 38 0016 622B or r22,r18 39 0018 7060 ori r23,lo8(0) 40 001a 8060 ori r24,lo8(0) 41 001c 9060 ori r25,lo8(0) 42 001e 2381 ldd r18,Z+3 43 0020 40E0 ldi r20,lo8(0) 44 0022 6060 ori r22,lo8(0) 45 0024 722B or r23,r18 46 0026 832B or r24,r19 47 0028 942B or r25,r20 48 /* epilogue start */ 49 .LM3: 50 002a 0895 ret (2)Same code but now with fwprop: 23 /* prologue: function */ 24 /* frame size = 0 */ 25 FC01 movw r30,r24 26 .LM2: 27 0002 4181 ldd r20,Z+1 28 0004 942F mov r25,r20 29 0006 70E0 ldi r23,lo8(0) 30 0008 3281 ldd r19,Z+2 31 000a 832F mov r24,r19 32 .LVL1: 33 000c 9060 ori r25,lo8(0) 34 000e 2481 ldd r18,Z+4 35 0010 622F mov r22,r18 36 0012 8060 ori r24,lo8(0) 37 0014 2381 ldd r18,Z+3 38 0016 722B or r23,r18 39 /* epilogue start */ 40 .LM3: 41 0018 0895 ret Much better! But note we still have OR rx,0 created. (There were none before fwprop pass.) As there are still obvious propagation oppertunities I suspect that these are being added by local-alloc propagation after imperfect fwprop. (4)Now with fwprop and NOP splitter for OR rx,0 23 /* prologue: function */ 24 /* frame size = 0 */ 25 FC01 movw r30,r24 26 .LM2: 27 0002 4181 ldd r20,Z+1 28 0004 942F mov r25,r20 29 0006 70E0 ldi r23,lo8(0) 30 0008 3281 ldd r19,Z+2 31 000a 832F mov r24,r19 32 .LVL1: 33 000c 2481 ldd r18,Z+4 34 000e 622F mov r22,r18 35 0010 2381 ldd r18,Z+3 36 0012 722B or r23,r18 37 /* epilogue start */ 38 .LM3: 39 0014 0895 ret No diference apart from OR Rx,0 removal. (I expected that) (5) And just for the hell of it 2 passes of fwprop before local-alloc. No NOP splitter. NEXT_PASS (pass_rtl_fwprop); NEXT_PASS (pass_rtl_fwprop); NEXT_PASS (pass_local_alloc); 23 /* prologue: function */ 24 /* frame size = 0 */ 25 FC01 movw r30,r24 26 .LM2: 27 0002 9181 ldd r25,Z+1 28 0004 8281 ldd r24,Z+2 29 .LVL1: 30 0006 6481 ldd r22,Z+4 31 0008 7381 ldd r23,Z+3 32 /* epilogue start */ 33 .LM3: 34 000a 0895 ret Which is optimal. TADA! 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. Andy
Re: RFC: GCC 4.4 criteria - add Fortran as primary language?
[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 support and have
similarly good test results on all primary and secondary
platforms.
I'm trying here to summarize our testresults on primary and secondary
platforms.
Primary platforms:
* arm-eabi: don't know, can't find testresults posted for
gfortran; last time arm-unknown-elf was reported, it had 8000+
failures, most of them due to PR33947 (not Fortran specific) that was
fixed since.
* i386-unknown-freebsd: 1 FAIL / 23522 PASS (compared to C: 80
FAIL / 3 XPASS / 47658 PASS)
* i686-pc-linux-gnu: clean (compared to C: 7 FAIL / 48648 PASS)
* i686-apple-darwin: clean (compared to C: 7 XPASS)
* mipsisa64-elf: 32 failures reported; clean on mipsel-unknown-
linux-gnu, relatively clean on mips-sgi-irix6.5 (72 FAIL, most of
them due to the same, IRIX-specific complex support problem)
* powerpc64-linux: 7 FAIL / 23641 PASS; the 7 FAILs are on the
same testcase, a glibc issue, they should be XFAILed
* sparc-sun-solaris: 58 FAIL / 23606 PASS; of the 8 testcases
failing, 4 will be xfailed (denormal I/O not handled by system libc),
and 2 are probably not actually a problem (gfortran.dg/stat_
{1,2}.f90, usually due to testsuite running under root or other
priviledged id)
* x86_64-unknown-linux-gnu: clean
Secondary platforms:
* hppa2.0w-hp-hpux11.11: 1 FAIL, probably libc bug
* powerpc-ibm-aix5.2.0.0: 53 FAIL, half of them suspected to be libc
bugs; lack of AIX access has prevented us working on getting this one
better
* powerpc-apple-darwin: 32 FAIL, 16 of them due to libc bugs
* i686-pc-cygwin: 13 FAIL, including 8 libc bugs
* i686-mingw32: no testing posted; gfortran is believed to be fairly
good on mingw, since this is probably one of our most used targets,
large number of people download prebuilt binaries linked from the GCC
wiki
* ia64-unknown-linux-gnu: 2 FAIL (compared to C: 32 FAIL)
* s390-linux-gnu: clean
As you can see, the gfortran testsuite stresses dark corners of the
libc (I/O and math of denormalized fp numbers, I/O of very large fp
numbers, ...). More of these should be marked as XFAIL, but different
versions of system's libc (and limited access to some targets)
sometimes make it hard to know what exactly is to be XFAILed.
Some more progress could be made on bare metal targets, but that
requires some help from people who actually have access or simulators
set up. Some newlib targets are relatively clean, though: sh-elf has
no failure at all, mipsisa64-elf has 32 failures, cris-elf has 231.
Hans-Peter Nilsson started helping me progressing on these (PR 21185
tracks these efforts), specifically on arm-elf, cris-elf, frv-elf,
mipsisa64-elf and v850-elf.
As a Fortran maintainer, I don't feel strongly about being or not
being listed as a primary language.
Thanks,
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
RE: RFC: GCC 4.4 criteria - add Fortran as primary language?
> -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 "experimental > primary" status; > a feature could be treated as primary, but with the understanding that > the requirement will be waived if it causes excessive delay. The > "experimental" label could be dropped after a few successful releases. Well, why not mirror the Primary and Secondary Platform lists on the back end, and have Primary Languages and Secondary Languages on the front end, with separate criteria for each category? For examples, Primary Languages would be C and C++, and put Ada, Java, and Fortran in the Secondary Languages group. Eric Weddington
Re: Redundant logical operations left after early splitting
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 "cascading", and some bugs in cascading were already revealed by the AVR port. It might be even more worthwhile to try *moving* fwprop2 after combine, then. Paolo
