Re: stringification of PREFIX etc...
On Tue, 27 Sep 2011 21:56:12 + (UTC)
"Joseph S. Myers" wrote:
> On Mon, 26 Sep 2011, Basile Starynkevitch wrote:
>
> > Hello All,
> >
> > It seems to me (file gcc/Makefile.in, definition of DRIVER_DEFINES) that
> > the configure-d PREFIX is wired inside gcc.o (hence inside the gcc
> > driver executable) without precautions.
> >
> > In particular, I don't understand if someone can configure gcc with a
> > prefix containing weird characters, such as double-quotes " or
> > backslashes \ or perhaps even spaces.
> >
> > My intuition is that GCC won't even build if the prefix contains such
> > naughty characters. If it is the case, should we document that.?
>
> In general it's hard to support this in full generality because of
> difficulty escaping things for "make" (and you have "make" - multiple
> levels thereof - the shell and C escaping to consider at least). If the
> paths to the source and build directories contain special characters it's
> particularly problematic (configure scripts get involved as well; some
> past autoconf versions had their own problems in this regard, although
> this may have been fixed).
I do know that and I have been bitten by the multiple levels of escaping in
MELT.
Actually, for the MELT branch (and the just released MELT 0.9 plugin for GCC
4.6), I came
up adding a trivial C generator which produces code like const char foo[]="bar";
even when the bar string contain naughty characters.
In MELT it is even a little bit worse, since I do need to stringify the default
CFLAGS
for the compilation of the C code generated by MELT, and that default string
obviously
contain spaces. (the MELT plugin runs "make" sometimes, to compile the
generated *.c
files into a *.so). See
http://groups.google.com/group/gcc-melt/browse_thread/thread/74c36fae50a2b47d
for more
details.
The generator is simple and self-contained, on
http://gcc.gnu.org/viewcvs/branches/melt-branch/gcc/melt-make-string.c?view=log
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
gcc-4.4-20110927 is now available
Snapshot gcc-4.4-20110927 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110927/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 179294 You'll find: gcc-4.4-20110927.tar.bz2 Complete GCC MD5=c82ddd3e339184aae4c2bd2e303154d1 SHA1=a005293cbd78dc3c26bf4568210aebac76f14075 Diffs from 4.4-20110920 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: stringification of PREFIX etc...
On Mon, 26 Sep 2011, Basile Starynkevitch wrote: > Hello All, > > It seems to me (file gcc/Makefile.in, definition of DRIVER_DEFINES) that > the configure-d PREFIX is wired inside gcc.o (hence inside the gcc > driver executable) without precautions. > > In particular, I don't understand if someone can configure gcc with a > prefix containing weird characters, such as double-quotes " or > backslashes \ or perhaps even spaces. > > My intuition is that GCC won't even build if the prefix contains such > naughty characters. If it is the case, should we document that.? In general it's hard to support this in full generality because of difficulty escaping things for "make" (and you have "make" - multiple levels thereof - the shell and C escaping to consider at least). If the paths to the source and build directories contain special characters it's particularly problematic (configure scripts get involved as well; some past autoconf versions had their own problems in this regard, although this may have been fixed). You may be able to get spaces working, but the other characters are likely harder. There is or was a proposal going through the Austin Group (POSIX) to disallow newlines in filenames (the hardest case of all to handle in shell scripts using standard POSIX utilities), but I haven't followed the exact status of that proposal. -- Joseph S. Myers jos...@codesourcery.com
Re: ARRAY_RANGE_REF
On 09/27/2011 11:45 AM, Iyer, Balaji V wrote: > Hello Everyone, > Is there a test-case which emits the ARRAY_RANGE_REF tree node for C or > C++ Compiler? Can someone tell me an example (or even a line of code) that > will make the compiler create/emit this tree node? I'm pretty sure this can only be generated by the Ada front end. r~
Re: ARRAY_RANGE_REF
On Tue, Sep 27, 2011 at 11:45 AM, Iyer, Balaji V wrote: > Hello Everyone, > Is there a test-case which emits the ARRAY_RANGE_REF tree node for C > or C++ Compiler? Can someone tell me an example (or even a line of code) that > will make the compiler create/emit this tree node? C or C++, no. Ada on the other hand it will emit it. There are a few testcases in the Ada testsuite which will emit it. Thanks, Andrew Pinski
ARRAY_RANGE_REF
Hello Everyone, Is there a test-case which emits the ARRAY_RANGE_REF tree node for C or C++ Compiler? Can someone tell me an example (or even a line of code) that will make the compiler create/emit this tree node? Thanks, Balaji V. Iyer.
Re: A case that PRE optimization hurts performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/27/11 09:00, Richard Guenther wrote: >> The thing to remember is jump threading is tasked detecting >> cases where the control statement has a predetermined destination >> utilizing path sensitive information. Expanding it to do >> general path sensitive optimizations is possible, but at even >> greater cost. > > Yeah, I realize that. It's just this case is the non-cfg form of > > if (pretmp) if (D.1234) ... > > where jump-threading would probably handle the CFG variant just > fine. Possibly. I haven't looked at the RTL version in a long long time, but it's still around cfgcleanup::thread_jump. I've been meaning to do some final experiments and declare that code as effectively dead (yes, it still does stuff, but not much, at least not last time I looked). WRT generalized path sensitive optimizations, the best work I've seen in the space is from Bodik. I've been wanting to play with some of his ideas for path isolation to simplify our current jump threading implementation. In theory, if that experiment works out we could utilize that infrastructure to implement other path sensitive analysis and optimization. Obviously, that's a ways out. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOgefZAAoJEBRtltQi2kC7JDEH+gOr0BWdN/Ru9oE7Fng1SJvX adH9HnT0PhVhvbZQuF9Ag3HYYFOZumNgEI5HU2s3gPaFNU/KuUMcCBAD7V/1748P L4soNu/dyHVZnKFtjx8MKEe9Jc+UMIvfdjewlsGHjzyBoXDIDaqzqQGmBLtM9MjK gV/tKzdeYz0TB4QMKb27RIBtrZn+l6Ur6IC/PJBxB6qrimvxbet8qxgj+0RDf5XE QSvCTS77QbfSw8k/5X1ag2lRKSZqX15w+p2b7S60XdvVd4pcIcyYKvyMDUcGy2hl PEay76+XyFsO8bCcLg69i+UirBrfceE2CVzYYkMfsPxh2RgBViluTveeybblkLs= =kkAA -END PGP SIGNATURE-
Re: A case that PRE optimization hurts performance
On Tue, Sep 27, 2011 at 4:56 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/27/11 01:30, Richard Guenther wrote: > >> >>> It knows something about prephitmp.6_1 and thus could simplify >>> D.2734_9 = prephitmp_6.1 & D.2732_7; to D.2734_9 = D.2732_7; But >>> admittedly I have no idea if DOM tries to simplify things other >>> than comparisons within the jump threading machinery ... (the >>> above block basically ends in if (D.2729_6 != 0 && >>> prephitmp_6.1), so I'd guess it's worth to simplify the (complex) >>> conditional expression). > Jump threading will enter simplified expressions into the hash tables > for every statement in the block in an effort to utilize any > information available to determine the result of the comparison. > However, those simplifications aren't ever reflected back into the IL. > > The thing to remember is jump threading is tasked detecting cases > where the control statement has a predetermined destination utilizing > path sensitive information. Expanding it to do general path > sensitive optimizations is possible, but at even greater cost. Yeah, I realize that. It's just this case is the non-cfg form of if (pretmp) if (D.1234) ... where jump-threading would probably handle the CFG variant just fine. Oh well ;) Richard.
Re: A case that PRE optimization hurts performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/27/11 01:30, Richard Guenther wrote: > >> It knows something about prephitmp.6_1 and thus could simplify >> D.2734_9 = prephitmp_6.1 & D.2732_7; to D.2734_9 = D.2732_7; But >> admittedly I have no idea if DOM tries to simplify things other >> than comparisons within the jump threading machinery ... (the >> above block basically ends in if (D.2729_6 != 0 && >> prephitmp_6.1), so I'd guess it's worth to simplify the (complex) >> conditional expression). Jump threading will enter simplified expressions into the hash tables for every statement in the block in an effort to utilize any information available to determine the result of the comparison. However, those simplifications aren't ever reflected back into the IL. The thing to remember is jump threading is tasked detecting cases where the control statement has a predetermined destination utilizing path sensitive information. Expanding it to do general path sensitive optimizations is possible, but at even greater cost. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOgeQGAAoJEBRtltQi2kC7xX8H/1odgAgNVKdbWk4FtsNPx9xl +xHtQdB2zycD0o0TMdQ+PcllXHaIK+ScIZEcxys1lN9HoEEyhyHPmQi7FZbD807y oTswglsX7hnTM3fMCN62BTFwk6P0QNrbeZ4bsVxF5DkBmMLXbArQ7UEYD9mSHnDv ixi06cUc/x5CXCAbcrAdUQI/9uF9d83myLs3rS3T0g2nPm+chGRN94Bm6ZbrB0hA PjyKiZ4j3z6Yc5bs2GF19Rh7vfjD/9NhKF9t9YwuBky4luLv4RPFsT1JQM3+1yuT tW5xk0et3eUnGFgiLUrF1mkHO/TkSv5iTsDI2tbbCkLCdH3w8Runj21/5qMWXxY= =X10i -END PGP SIGNATURE-
Re: added_clobbers_hard_reg_p and FLAGS_REGNUM
On 26/09/11 17:23, Ian Lance Taylor wrote: The function added_clobbers_hard_reg_p is a generated function. So another approach would be some sort of attribute which directs the generator (genemit) to ignore certain hard registers. This definitely sounds like the best approach for my specific case. I understand that for such a change to be integrated in GCC there might be other implications due to the vast number of different backends supported by GCC. Thanks, -- PMatos
Ann: GCC MELT plugin 0.9 release (for gcc 4.6)
Hello
It is my pleasure to announce the release of GCC MELT plugin 0.9 for GCC 4.6
The release of MELT plugin 0.9 for gcc 4.6 is available, as a gzipped source
tar archive,
from http://gcc-melt.org/melt-0.9-plugin-for-gcc-4.6.tgz of size 3785599 bytes,
and
md5sum 739cf34c19aade37092dd9b9601ebc2d (september 27th 2011).
It is extracted from MELT branch svn revision 179266.
The version number 0.9 of the MELT plugin is unrelated to
the version of the GCC compiler (4.6) for which it is supposed to work.
Bug reports and patches are welcome (to the gcc-m...@googlegroups.com list).
###
NEWS for 0.9 MELT plugin for gcc-4.6
September 27th, 2011: Release of MELT plugin 0.9 for gcc-4.6
New features:
Documentation is generated
The PLUGIN_PRE_GENERICIZE event is interfaced.
The build machinery and the binary module loading has been
significantly updated. Modules shared objects are like
warmelt-macro.3461497d8ef7239dc1f2f132623e6dd5.quicklybuilt.so and
they contain the md5sum of the catenation of all C files. They
also come in various flavor: quicklybuilt (the generated C is
compiled with -O0 -DMELT_HAVE_DEBUG), optimized (the generated C
is compiled with -01 and without -DMELT_HAVE_DEBUG), debugnoline
(the generated C is compiled with -g and -DMELT_HAVE_DEBUG but no
#line directives).
Conceptually, a module is loaded by loading its +meltdesc.c
file. That file (e.g. warmelt-macro+meltdesc.c corresponding to
warmelt-macro.melt) should never be moved or even edited. It is
parsed at module load time, and contains the various md5sum of
real generated C files.
New option -fplugin-arg-melt-workdir= for the work directory,
where every .c or .so files are generated.
The DISCR_BOX discriminant has been removed. Use containers instead.
Containers, that is instances of class_container having one single field
:container_value, are supported by syntactic macros and sugar & function.
(container V)
=equivalent= (instance class_container :container_value V)
(content C)
=equivalent= (get_field :container_value C)
(set_content C V)
=equivalent= (put_fields C :container_value V)
You can write exclaim instead of content, and there is a new syntactic
sugar
!X
is the same as (content X) - the exclamation mark should be
followed by spaces, letters, or left parenthesis to be parsed as
exclaim -that is as the content macro above.
In patterns, ?(container ?v) means
?(instance class_container :container_value ?v)
Fields can be accessed by their name, so
(:F C)
is the same as (get_field :F C)
Hence (:container_value foo) is the same as !foo or
(get_field :container_value foo)
Experimental syntactic sugar: inside an s-expr, a macro string
written ##{...}# is expanded as several components, not a single
list.
Experimental: ability to (define ...) values like in Scheme.
Ability to create gimple-s and to modify gimple_seq.
Slow boxed arithmetic operations are available (e.g. +iv gets two
boxed integer and gives the boxed integer of their sum).
Many bug fixes.
The build system has been revamped. The generated .c files should be
available when running MELT.
Thanks to Pierre Vittet, Alexandre Lissy, Romain Geissler for
feedback, patches, suggestions.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Information on SCoP coverage by GRAPHITE
Anyone on this? Please? cheers, Simone On 09/26/2011 03:05 PM, Simone Pellegrini wrote: Dear all, I would like to know if GCC exposes any flag to collect static information related to the code coverage by the GRAPHITE framework. I have seen this information published on several papers and I am wondering how can I get the same information. What I would like to know is how many SCoPs are identified within a program and what percentage of the input program is a SCoP. thanks for the help. Regards, S. Pellegrini
missing conditional propagation in cprop.c pass
Hi,
I ran into a case and found conditional (const) propagation is
mishandled in cprop pass.
With following insn sequence after cprop1 pass:
(note 878 877 880 96 [bb 96] NOTE_INSN_BASIC_BLOCK)
(insn 882 881 883 96 (set (reg:CC 24 cc)
(compare:CC (reg:SI 684 [ default_num_contexts ])
(const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
(nil))
(jump_insn 883 882 886 96 (set (pc)
(if_then_else (ne (reg:CC 24 cc)
(const_int 0 [0]))
(label_ref:SI 905)
(pc))) core_main.c:265 223 {*arm_cond_branch}
(expr_list:REG_DEAD (reg:CC 24 cc)
(expr_list:REG_BR_PROB (const_int 9100 [0x238c])
(nil)))
-> 905)
(note 886 883 49 97 [bb 97] NOTE_INSN_BASIC_BLOCK)
(insn 49 886 0 97 (set (reg/v:SI 291 [ total_errors ])
(reg:SI 684 [ default_num_contexts ])) core_main.c:265 709
{*thumb2_movsi_insn}
(expr_list:REG_DEAD (reg:SI 684 [ default_num_contexts ])
(expr_list:REG_EQUAL (const_int 0 [0])
(nil
..
(code_label 905 54 904 47 54 "" [1 uses])
(note 904 905 46 47 [bb 47] NOTE_INSN_BASIC_BLOCK)
(insn 46 904 47 47 (set (reg/v:SI 291 [ total_errors ])
(const_int 0 [0])) core_main.c:265 709 {*thumb2_movsi_insn}
(nil))
The insn49 should be propagated with conditional const from insn882
and jump_insn883, optimized into "r291<-0" as following code, then let
pre do redundancy elimination work.
(note 878 877 880 96 [bb 96] NOTE_INSN_BASIC_BLOCK)
(insn 882 881 883 96 (set (reg:CC 24 cc)
(compare:CC (reg:SI 684 [ default_num_contexts ])
(const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
(nil))
(jump_insn 883 882 886 96 (set (pc)
(if_then_else (ne (reg:CC 24 cc)
(const_int 0 [0]))
(label_ref:SI 905)
(pc))) core_main.c:265 223 {*arm_cond_branch}
(expr_list:REG_DEAD (reg:CC 24 cc)
(expr_list:REG_BR_PROB (const_int 9100 [0x238c])
(nil)))
-> 905)
(note 886 883 49 97 [bb 97] NOTE_INSN_BASIC_BLOCK)
(insn 49 886 0 97 (set (reg/v:SI 291 [ total_errors ])
(const_int 0 [0])) core_main.c:265 709 {*thumb2_movsi_insn}
(expr_list:REG_DEAD (reg:SI 684 [ default_num_contexts ])
(expr_list:REG_EQUAL (const_int 0 [0])
(nil
..
(code_label 905 54 904 47 54 "" [1 uses])
(note 904 905 46 47 [bb 47] NOTE_INSN_BASIC_BLOCK)
(insn 46 904 47 47 (set (reg/v:SI 291 [ total_errors ])
(const_int 0 [0])) core_main.c:265 709 {*thumb2_movsi_insn}
(nil))
The problem is function one_cprop_pass does local const/copy
propagation pass first, then the global pass, which only handles
global opportunities.
Though conditional const information "r684 <- 0" is collected by
find_implicit_sets, the conditional information is recorded as local
information of bb 97, and it is not recorded in avout of bb 96, so not
in avin of bb 97 either.
Unfortunately, the global pass only considers potential opportunities
from avin of each basic block in function cprop_insn and
find_avail_set.
That's why the conditional propagation opportunity in bb 97 is missed.
I worked a patch to fix this, and wanna hear more suggestions on this topic.
Is it a bug or I missed something important?
Thanks
BTW, I'm using gcc mainline which configured for arm-none-eabi target.
Re: A case that PRE optimization hurts performance
On Mon, Sep 26, 2011 at 6:42 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/26/11 05:00, Richard Guenther wrote: >> On Mon, Sep 26, 2011 at 9:39 AM, Jiangning Liu >> wrote: > * Without PRE, > > Path1: movl $2, %eax cmpl $1, %eax je .L3 > > Path2: movb $3, %al cmpl $1, %eax je .L3 > > Path3: cmpl $1, %eax jne .L14 > > * With PRE, > > Path1: movl $1, %ebx movl $2, %eax testb %bl, %bl je > .L3 > > Path2: movl $1, %ebx movb $3, %al testb %bl, %bl je > .L3 > > Path3: cmpl $1, %eax setne %bl testb %bl, %bl jne > .L14 > > Do you have any more thoughts? It seems to me that with PRE all the testb %bl, %bl should be evaluated at compile-time considering the preceeding movl $1, %ebx. Am I missing something? >>> >>> Yes. Can this be done by PRE or any other optimizations in middle >>> end? >> >> Hm, the paths as you quote them are obfuscated by missed >> jump-threading. On the tree level we have >> >> # s_2 = PHI <2(5), 3(4), 2(6), s_25(7)> # prephitmp.6_1 = PHI >> <1(5), 1(4), 1(6), prephitmp.6_3(7)> : t_14 = t_24 + 1; >> D.2729_6 = MEM[base: t_14, offset: 0B]; D.2732_7 = D.2729_6 != 0; >> D.2734_9 = prephitmp.6_1 & D.2732_7; if (D.2734_9 != 0) >> >> where we could thread the cases with prephitmp.6_1 == 1, >> ultimately removing the & and forwarding the D.2729_6 != 0 test. >> Which would of course cause some code duplication. >> >> Jeff, you recently looked at tree jump-threading, can you see if >> we can improve things on this particular testcase? > There's nothing threading can do here because it doesn't know anything > about the value MEM[t14]. It knows something about prephitmp.6_1 and thus could simplify D.2734_9 = prephitmp_6.1 & D.2732_7; to D.2734_9 = D.2732_7; But admittedly I have no idea if DOM tries to simplify things other than comparisons within the jump threading machinery ... (the above block basically ends in if (D.2729_6 != 0 && prephitmp_6.1), so I'd guess it's worth to simplify the (complex) conditional expression). Richard. > > Jeff > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOgKuLAAoJEBRtltQi2kC75aIH/iikuOQXrMrQJFbQw0COXznB > OGq8iXdGwTJGH13vxdItTE0upJp7RgUVLzuhdqj1elTLHv/ujYygMsQRNGKcc8tb > GMLECmWDhZqQTFXcTJCgJNZiv7MH1PNELXSdIkkSnxY+pwyn9AX5D3+HcTSjGU6B > 51AdUNVph/VSaVboAgcrFpu9S0pX9HVTqFy4JI83Lh613zDVSmPo14DDy7vjBvE9 > 2Srlvlw0srYup97bGmRqN8wT4ZLLlyYSB2rjEFc6jmgXVncxiteQYIUZpy0lcC0M > q3j80aXjZ57/iWyAbqDr1jI5tbVKDBkRa9LL1jvn9534adiG4GrnSMPhoog0ibA= > =azr5 > -END PGP SIGNATURE- >
