Machine description question
Hello all, Picochip has communication instructions that allow one array element to pass data to another. There are 3 such instructions PUT/GET/TSTPORT. Currently, all three of these use UNSPEC_VOLATILE side-effect expressions to make sure they don't get reordered. But, i wonder if it is an overkill to use UNSPEC_VOLATILE for this purpose and whether i should use UNSPEC instead. The only thing we care here is that they don't reordered with respect to each other. It is okay for other instructions to move around the communication instructions (as long as normal scheduler dependencies are taken care of). There are possibly one of two things i can do. 1. Introduce an implicit dependency between all communication instructions by adding a use/clobber of an imaginary register. 2. Introduce explicit dependency between them by using some target hook to add dependency links. I have not found any appropriate target hook to do this. Can you tell me which one i should try? Has anyone tried doing anything similar? Any pointers/suggestions on this will be greatly appreciated. Thanks Hari
Re: Build Error
On 05/11/2010 02:00 PM, Diego Novillo wrote: checking libelf.h usability... yes checking libelf.h presence... yes checking for libelf.h... yes checking gelf.h usability... yes checking gelf.h presence... yes checking for gelf.h... yes checking libelf/libelf.h usability... yes checking libelf/libelf.h presence... yes checking for libelf/libelf.h... yes checking libelf/gelf.h usability... yes checking libelf/gelf.h presence... yes checking for libelf/gelf.h... yes checking for the correct version of libelf... yes checking for elf_getshdrstrndx... no checking for elf_getshstrndx... yes Hmm, it did not detect elf_getshdrstrndx and yet it tried to use it later on. I think that's the bug. Yes, please file a bug. I believe it's going to be easy to fix, though. There should be an unguarded use of that function somewhere, it needs to be changed. My config.log and build log looks just like this except that it doesn't check for elf_getshdrstrndx at all but then I get an unresolved reference to elf_getshdrstrndx at link time in stage 2. Is this the same problem? Should I add it to the bug form? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44079 Thanks, Mike
RE: Machine description question
Our architecture has the similar resource, and we use the first approach by creating an imaginary register and dependency between these instructions, i.e., every such instruction reads and write to the special register to create artificial dependency. You may need to add a (unspec:..) as an independent expression in your pattern to prevent some wrong optimizations. Cheers, Bingfeng > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On > Behalf Of Hariharan > Sent: 12 May 2010 11:18 > To: gcc@gcc.gnu.org > Subject: Machine description question > > Hello all, > Picochip has communication instructions that allow one array > element to > pass data to another. There are 3 such instructions PUT/GET/TSTPORT. > Currently, all three of these use UNSPEC_VOLATILE side-effect > expressions to make sure they don't get reordered. But, i > wonder if it > is an overkill to use UNSPEC_VOLATILE for this purpose and whether i > should use UNSPEC instead. The only thing we care here is that they > don't reordered with respect to each other. It is okay for other > instructions to move around the communication instructions > (as long as > normal scheduler dependencies are taken care of). There are > possibly one > of two things i can do. > > 1. Introduce an implicit dependency between all communication > instructions by adding a use/clobber of an imaginary register. > 2. Introduce explicit dependency between them by using some > target hook > to add dependency links. I have not found any appropriate > target hook to > do this. > > Can you tell me which one i should try? Has anyone tried > doing anything > similar? Any pointers/suggestions on this will be greatly appreciated. > > Thanks > Hari > >
libgcc2
Hi all, is it possible to translate the libgcc2 when i only have 4 registers which are 32 bits long. One of the four Registers is defined as Basepointer and another as Stackpointer. The other two can be used to calculate. Reegards Egge
Re: C++0x Memory model and gcc
Miles Bader wrote: Andrew MacLeod writes: -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right? Right. Its just a single processor memory model, so it doesn't limit any optimizations. Hmm, though now that I think about it, I'm not exactly sure what I mean by "explicit synchronization". Standard libraries (boost threads, the upcoming std::thread) provide things like mutexes and conditional-variables, but does using those guarantee that the right things happen with any shared data-structures they're used to coordinate...? Well, you get the same thing you get today. Any synchronization done via a function call will tend to be correct since we never move shared memory operations across calls. Depending on your application, the types of data races the options deal with may not be an issue. Using the options will eliminate having to think whether they are issues or not at a (hopefully) small cost. Since the atomic operations are being built into the compiler, the intent is to eventually optimize and inline them for speed... and in the best case, simply result in a load or store. That's further work of course, but these options are laying some of the groundwork. Andrew
Re: libgcc2
Eggenmüller Bernd writes: > is it possible to translate the libgcc2 when i only have 4 registers > which are 32 bits long. > One of the four Registers is defined as Basepointer and another as > Stackpointer. > The other two can be used to calculate. libgcc2 is intended to be machine independent. If you have a working compiler, then no translation of libgcc2 should be needed. Perhaps I misunderstand your question. Ian
Freescale hc11/12 port extension to s12x / xgate
Announce. I have posted some patches to gcc and binutils to better support Freescale S12X and XGATE cores. See: http://www.msextra.com/tools/s12x-20100504.zip This contains rolled up patches against. gcc-3.3.6 binutils-2.18 newlib-1.16-0 The patches include Stephane Carrez' patches and add binutils support for the S12X instructions and XGATE core. gcc contains a hand coded S12X assembler version of udivsi32 which is faster than the original C version. gcc/binutils modified to allow the m9s12x xgate CPU target flags to be passed but do not otherwise use them. Typical Makefile likes would be: CFLAGS = -g -Wall -Werror -O -fomit-frame-pointer -m9s12x -mshort -msoft-reg-count=5 -mauto -incdec -fsigned-char -DGCC_BUILD -Wa,-mm9s12x XFLAGS = -g -Wall -Werror -O -fomit-frame-pointer -m9s12xg -mshort -msoft-reg-count=5 -maut o-incdec -fsigned-char -DGCC_BUILD -Wa,-mxgate XGATE assembly appears functional. Probably best discussed on http://tech.groups.yahoo.com/group/gnu-m68hc11 regards James
Re: Draft SH uClinux FDPIC ABI
On Tue, 25 Mar 2008, Joseph S. Myers wrote: > Following comments on these lists and from Renesas, the revised ABI we > will be implementing is now available. (Further changes may be made for > issues found in the course of implementation.) > > http://www.codesourcery.com/public/docs/sh-fdpic/sh-fdpic-abi.txt The ABI is now at version 1.0 and has been implemented; we expect to be contributing the changes to binutils, GCC, uClibc and GDB fairly soon, starting with binutils. -- Joseph S. Myers jos...@codesourcery.com
Re: Machine description question
Thanks for your help BingFeng. I gave this a go and ended up with worse code (and worse memory usage) than before. I started with this experiment because of the compilers "All virtual registers are assumed to be used and clobbered by unspec_volatile" rule. The get/put instructions read/write to registers and the virtual register assigned for them interferes with all the virtual registers in the function. So, they were highly likely to be spilled and use stack instead. I wanted to try to avoid this by the introduction of unspec's and use of imaginary registers. But, the virtual registers that are involved in unspec patterns with these imaginary registers still seem to be marked to interfere with all the virtual registers. Is that to be expected? Am i missing something obvious here? Regards Hari Bingfeng Mei wrote: Our architecture has the similar resource, and we use the first approach by creating an imaginary register and dependency between these instructions, i.e., every such instruction reads and write to the special register to create artificial dependency. You may need to add a (unspec:..) as an independent expression in your pattern to prevent some wrong optimizations. Cheers, Bingfeng -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Hariharan Sent: 12 May 2010 11:18 To: gcc@gcc.gnu.org Subject: Machine description question Hello all, Picochip has communication instructions that allow one array element to pass data to another. There are 3 such instructions PUT/GET/TSTPORT. Currently, all three of these use UNSPEC_VOLATILE side-effect expressions to make sure they don't get reordered. But, i wonder if it is an overkill to use UNSPEC_VOLATILE for this purpose and whether i should use UNSPEC instead. The only thing we care here is that they don't reordered with respect to each other. It is okay for other instructions to move around the communication instructions (as long as normal scheduler dependencies are taken care of). There are possibly one of two things i can do. 1. Introduce an implicit dependency between all communication instructions by adding a use/clobber of an imaginary register. 2. Introduce explicit dependency between them by using some target hook to add dependency links. I have not found any appropriate target hook to do this. Can you tell me which one i should try? Has anyone tried doing anything similar? Any pointers/suggestions on this will be greatly appreciated. Thanks Hari
Clobbering two registers
Hi all, How can I say in the machine architecture that to generate code for a particular insn I need any two registers for intermediate operations? To get one I think that (clobber (match_operand ...)) will work but what if I want two? Can I add two clobbers on the same define_insn rule? Cheers, -- PMatos
RE: Machine description question
How do you define your imaginary register in target.h? Can you post one example of your instruction pattern? Bingfeng > -Original Message- > From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com] > Sent: 12 May 2010 16:40 > To: Bingfeng Mei > Cc: gcc@gcc.gnu.org > Subject: Re: Machine description question > > Thanks for your help BingFeng. > > I gave this a go and ended up with worse code (and worse > memory usage) > than before. I started with this experiment because of the compilers > "All virtual registers are assumed to be used and clobbered by > unspec_volatile" rule. The get/put instructions read/write to > registers > and the virtual register assigned for them interferes with all the > virtual registers in the function. So, they were highly likely to be > spilled and use stack instead. I wanted to try to avoid this by the > introduction of unspec's and use of imaginary registers. > > But, the virtual registers that are involved in unspec patterns with > these imaginary registers still seem to be marked to > interfere with all > the virtual registers. Is that to be expected? Am i missing something > obvious here? > > Regards > Hari > > Bingfeng Mei wrote: > > Our architecture has the similar resource, and we use the > first approach > > by creating an imaginary register and dependency between > these instructions, > > i.e., every such instruction reads and write to the special > register to > > create artificial dependency. You may need to add a > (unspec:..) as an > > independent expression in your pattern to prevent some > wrong optimizations. > > > > > > Cheers, > > Bingfeng > > > > > >> -Original Message- > >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On > >> Behalf Of Hariharan > >> Sent: 12 May 2010 11:18 > >> To: gcc@gcc.gnu.org > >> Subject: Machine description question > >> > >> Hello all, > >> Picochip has communication instructions that allow one array > >> element to > >> pass data to another. There are 3 such instructions > PUT/GET/TSTPORT. > >> Currently, all three of these use UNSPEC_VOLATILE side-effect > >> expressions to make sure they don't get reordered. But, i > >> wonder if it > >> is an overkill to use UNSPEC_VOLATILE for this purpose and > whether i > >> should use UNSPEC instead. The only thing we care here is > that they > >> don't reordered with respect to each other. It is okay for other > >> instructions to move around the communication instructions > >> (as long as > >> normal scheduler dependencies are taken care of). There are > >> possibly one > >> of two things i can do. > >> > >> 1. Introduce an implicit dependency between all communication > >> instructions by adding a use/clobber of an imaginary register. > >> 2. Introduce explicit dependency between them by using some > >> target hook > >> to add dependency links. I have not found any appropriate > >> target hook to > >> do this. > >> > >> Can you tell me which one i should try? Has anyone tried > >> doing anything > >> similar? Any pointers/suggestions on this will be greatly > appreciated. > >> > >> Thanks > >> Hari > >> > >> > >> > >
Re: Coverage of backend rules
On Tue, May 11, 2010 at 3:26 PM, Ian Lance Taylor wrote: > For define_insn you can use the -da option, and scan the debug files > for the matched insn names. For define_expand you can reliably use > profiling information to look for calls to gen_NAME. > > This approach won't tell you whether you are testing all alternatives > of all define_insns. I don't know of a reasonable way to do that. > Thanks for the tips. I will give it a go at trying to automate this. Cheers, -- PMatos
Re: Clobbering two registers
"Paulo J. Matos" writes: > How can I say in the machine architecture that to generate code for a > particular insn I need any two registers for intermediate operations? > To get one I think that (clobber (match_operand ...)) will work but > what if I want two? Can I add two clobbers on the same define_insn > rule? Yes. Also look at match_scratch. Ian
Different flags for building plugins and gcc.
On darwin (powerpc only at present, but potentially i686 too) we use "-
mdynamic-no-pic" to build the compiler.
config/mh-ppc-darwin:
# The -mdynamic-no-pic ensures that the compiler executable is built
without
# position-independent-code -- the usual default on Darwin. This fix
speeds
# compiles by 3-5%.
BOOT_CFLAGS += -mdynamic-no-pic
This is fine until we try to build plugins.
plugins need fPIC which is overridden by mdynamic-no-pic (with a
warning message emitted).
This means that the autoconfigury machinery defaults to deciding that
ppc can't do plugins.
one cannot force the issue with --enable-plugins.
I've proved to myself that ppc makes and runs the plugins code
perfectly OK (by hacking mh-ppc-darwin off).
=
However trying to find where exactly I need to patch the autoconfigury
bits is proving more tricky - and I'd welcome some comments;
firstly:
in gcc/configure.ac:
# Check that we can build shared objects with -fPIC -shared
saved_LDFLAGS="$LDFLAGS"
case "${host}" in
*-*-darwin*)
LDFLAGS="$LDFLAGS -fPIC -shared -undefined dynamic_lookup"
;;
*)
LDFLAGS="$LDFLAGS -fPIC -shared"
;;
esac
AC_MSG_CHECKING([for -fPIC -shared])
.. this seems a bit strange : -fPIC is not a ld flag...
maybe something like:
# Check that we can build shared objects with -fPIC -shared
saved_LDFLAGS="$LDFLAGS"
saved_CFLAGS="$CFLAGS"
case "${host}" in
*-*-darwin*)
CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
CFLAGS="$CFLAGS -fPIC"
LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
CFLAGS="$CFLAGS -fPIC"
LDFLAGS="$LDFLAGS -shared"
;;
esac
AC_MSG_CHECKING([for -fPIC -shared])
===
then Makefile.in has:
PLUGINCFLAGS = @CFLAGS@
I wonder if we need to propagate a PLUGINCFLAGS ?
or put some target-specific stuff there too .. ?
===
Are there any other places I need to look?
(I've only achieved partial success with the changes above ).
cheers,
Iain
PING -- MicroBlaze target support patches
Could someone please review these patches? Add support for Xilinx MicroBlaze processor: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01903.html http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01905.html http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01908.html http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01907.html http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01906.html -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Different flags for building plugins and gcc.
IainS writes: > .. this seems a bit strange : -fPIC is not a ld flag... LDFLAGS is flags that are passed to the compiler when linking. It is not flags passed directly to the linker. I don't know why -fPIC is there, but it shouldn't do any harm. The Makefile fragment config/mh-ppc-darwin is selected in configure.ac. I think the simplest approach would be to select different config files based on whether --enable-plugins is used. Ian
Re: Different flags for building plugins and gcc.
Hi Ian, On 12 May 2010, at 21:00, Ian Lance Taylor wrote: IainS writes: .. this seems a bit strange : -fPIC is not a ld flag... LDFLAGS is flags that are passed to the compiler when linking. It is not flags passed directly to the linker. I don't know why -fPIC is there, but it shouldn't do any harm. it's more that it's *not* force-added to CFLAGS that was a surprise - since that's one thing the code says it's testing. The Makefile fragment config/mh-ppc-darwin is selected in configure.ac. I think the simplest approach would be to select different config files based on whether --enable-plugins is used. Agreed - it's the simplest .. but.. (a) that means we don't auto-detect the ability to use plugins - not a major bind, but a shame. (b) if we believe that the comment in mh-ppc-darwin is up to date, we are sacrificing 3..5% compile performance if we build a compiler able to use plugins. .. (b) also applies to the other simple approach - just nuke mh-ppc- darwin [which, incidentally, restores auto-detect of plugin capability] ;-) Iain
mips secondary reload question
Hi: as to page http://gcc.gnu.org/ml/gcc/2010-05/msg00091.html, If the fpu register can not copied to/from memory directly, I have to use intermediate GPR registers. In fact, I return GP_REGS if copying x to a register in class FP_REGS in any mode(including CCmode), this results in infinite recursive calling of memory_move_secondary_cost. After tracing cc1, I found the calling sequence is like: memory_move_secondary_cost (CCmode, ST_REGS, 1) --> memory_move_secondary_cost (CCmode, FP_REGS, 1) --> memory_move_secondary_cost (CCmode, ST_REGS, 1) --> memory_move_secondary_cost (CCmode, FP_REGS, 1) --> ... infinite recursive It seems function default_secondary_reload always use ST_REGS as intermediate register for FP_REGS:CCmode according to reload_incc pattern. This is all what i found, and I have totally no idea about how reload pass works . any explanation? Thanks. -- Best Regards.
