Re: [IRA] New register allocator question
Bingfeng Mei wrote:
I found if I define a new register class that covers both GR_REGS and PR_REGS, the issue can be solved. New IRA spill the predicate register to general regsister first instead of memory. Is this right approach?
#define IRA_COVER_CLASSES \
{ \
GRPR_REGS, M_REGS, BXBC_REGS, LIM_REG_CLASSES \
}
Sorry, I should have read all your emails before answering. You figured
out the solution by yourself. I pointed out the same solution in my
previous email.
Re: libmudflap and emutls question
Hi Frank,
Frank Ch. Eigler wrote:
Jie Zhang writes:
To break the recursive loop, one solution is to force emutls to call
the real calloc. [...]
If it were acceptable to change emutls on account of mudflap, this
sort of thing could work. Other alternatives would include having
emutls define something in addition to HAVE_TLS that activates the
!HAVE_TLS implementation in libmudflap/mf-hooks3.c.
Thanks for your help! How about the attached patch, which follows your
advice?
Regards,
Jie
libmudflap/
* mf-impl.h (__mf_get_state, __mf_set_state): Don't use
__thread when TLS support is emulated.
* mf-hooks3.c (__mf_get_state, __mf_set_state): Likewise.
* mf-runtime.c (__mf_state_1): Likewise.
* configure.ac: Use GCC_CHECK_EMUTLS.
* configure: Regenerate.
* config.h.in: Regenerate.
config/
* tls.m4 (GCC_CHECK_EMUTLS): Define.
Index: libmudflap/mf-impl.h
===
--- libmudflap/mf-impl.h (revision 143074)
+++ libmudflap/mf-impl.h (working copy)
@@ -244,7 +244,7 @@
#define UNLOCKTH() do {} while (0)
#endif
-#if defined(LIBMUDFLAPTH) && !defined(HAVE_TLS)
+#if defined(LIBMUDFLAPTH) && (!defined(HAVE_TLS) || defined(USE_EMUTLS))
extern enum __mf_state_enum __mf_get_state (void);
extern void __mf_set_state (enum __mf_state_enum);
#else
Index: libmudflap/mf-hooks3.c
===
--- libmudflap/mf-hooks3.c (revision 143074)
+++ libmudflap/mf-hooks3.c (working copy)
@@ -78,7 +78,7 @@
/* Multithreading support hooks. */
-#ifndef HAVE_TLS
+#if !defined(HAVE_TLS) || defined(USE_EMUTLS)
/* We don't have TLS. Ordinarily we could use pthread keys, but since we're
commandeering malloc/free that presents a few problems. The first is that
we'll recurse from __mf_get_state to pthread_setspecific to malloc back to
@@ -217,7 +217,7 @@
if (__mf_opts.heur_std_data)
__mf_unregister (&errno, sizeof (errno), __MF_TYPE_GUESS);
-#ifndef HAVE_TLS
+#if !defined(HAVE_TLS) || defined(USE_EMUTLS)
struct mf_thread_data *data = __mf_find_threadinfo (0);
if (data)
data->used_p = 0;
Index: libmudflap/configure.ac
===
--- libmudflap/configure.ac (revision 143074)
+++ libmudflap/configure.ac (working copy)
@@ -265,6 +265,7 @@
# See if we support thread-local storage.
GCC_CHECK_TLS
+GCC_CHECK_EMUTLS
AC_CONFIG_FILES([Makefile testsuite/Makefile testsuite/mfconfig.exp])
AC_OUTPUT
Index: libmudflap/mf-runtime.c
===
--- libmudflap/mf-runtime.c (revision 143074)
+++ libmudflap/mf-runtime.c (working copy)
@@ -178,7 +178,7 @@
int __mf_starting_p = 1;
#ifdef LIBMUDFLAPTH
-#ifdef HAVE_TLS
+#if defined(HAVE_TLS) && !defined(USE_EMUTLS)
__thread enum __mf_state_enum __mf_state_1 = reentrant;
#endif
#else
Index: config/tls.m4
===
--- config/tls.m4 (revision 143074)
+++ config/tls.m4 (working copy)
@@ -86,3 +86,20 @@
AC_DEFINE(HAVE_CC_TLS, 1,
[Define to 1 if the target assembler supports thread-local storage.])
fi])
+
+dnl Check whether TLS is emulated.
+AC_DEFUN([GCC_CHECK_EMUTLS], [
+ AC_CACHE_CHECK([whether the thread-local storage support is from emutls],
+ gcc_cv_use_emutls, [
+AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
+ [if grep __emutls_get_address conftest.$ac_objext >/dev/null ; then
+ gcc_cv_use_emutls=yes
+ else
+ gcc_cv_use_emutls=no
+ fi
+ ], [gcc_cv_use_emutls=no])]
+)
+ if test "$gcc_cv_use_emutls" = "yes" ; then
+AC_DEFINE(USE_EMUTLS, 1,
+ [Define to 1 if the target use emutls for thread-local storage.])
+ fi])
Re: [IRA] New register allocator question
Bingfeng Mei wrote:
Hello,
I recently ported our GCC to new IRA by following mainline development. The
only interface I added is IRA_COVER_CLASSES. Our architecture has predicate
register file. When predicate register has to be spilled, the new IRA produces
inferior code to the old register allocator. The old allocator first tries to
spill to general register file, which is far cheaper on our architecture than
spilling to memory. The IRA always spills the predicate register to memory
directly.
#define IRA_COVER_CLASSES \
{ \
GR_REGS, PR_REGS, M_REGS, BXBC_REGS, LIM_REG_CLASSES \
}
Apart from above macro, what other interfaces/parameters I can tune to change this behaviour in new IRA? Thanks in advance.
It is not necessary anymore to define macro IRA_COVER_CLASSES to use IRA
for a new target. But it is recommended for most targets to get a
better RA because without the macro only priority coloring will be
used. You could try priority coloring with defined IRA_COVER_CLASSES by
using option -fira-algorigthm=priority.
As for the problem about spilling predicate register to memory by IRA,
it seems to me that the old RA used union register class GR_REGS+PR_REGS
for the pseudos because reload pass does not spill into registers. So
to solve the problem, you could try
o to use union of GR_REGS and PR_REGS instead of separate GR_REGS and
PR_REGS in IRA_COVER_CLASSES
o to use priority coloring which can use the union classes automatically
Re: libmudflap and emutls question
On Tue, Jan 06, 2009 at 01:12:08AM +0800, Jie Zhang wrote: > >[...] Other alternatives would include having > >emutls define something in addition to HAVE_TLS that activates the > >!HAVE_TLS implementation in libmudflap/mf-hooks3.c. > > Thanks for your help! How about the attached patch, which follows your > advice? That makes sense to me, but I'd appreciate others' advice too (rth?). - FChE
Re: About Hazard Recognizer:DFA
daniel tian wrote: Hi Dr. Uday Khedker: Happy New Year! I met hazard problem. And I have debuged this error for a few days. I wrote DFA to avoid load hazard, but still it exists. I wonder whether in default the command './cc1 hazard.c' doesn't compile the file with DFA. And in default without any optimization there is no 'NOP' instruction after the 'LOAD' instruction. DFA pipeline hazard recognizer is used in GCC insn scheduler and the scheduler never inserts nop to avoid pipeline hazards (most architectures use locks to resolve conflicts and adding nops would only worsen insn cache locality). Insertion of nops is usually implemented in assembler for architectures without the locks or in machine-dependent parts of GCC compiler. You could look at machine dependent files of VLIW processors (like FRV or Itanium) to see how it can be made. I saw analogous question on gcc mailing lists, you could use them too.
How to define 2 bypasses for a single pair of insn_reservation
When I write schedule model for following instructions: Insn1: mov %r1, %r2 Insn2: mov %r1, %r3 Insn3: foo %r2, %r3 (foo is a 3 op insn, for example, %r3 = %r3 << %r2) Latency from insn1 to insn3 is x cycles, and latency from insn2 to insn3 is y cycles. x != y. Both insn1 and insn2 are insn_reservation_mov. Insn3 are insn_reservation_foo. When I define bypass for them I found I couldn't do it. I can only define one bypass from mov to foo, like this: (define_bypass x "insn_reservation_mov" "insn_reservation_foo" "condition1") If I define following bypass too, gcc will report error: (define_bypass y "insn_reservation_mov" "insn_reservation_foo" "condition2") genautomata: bypass `insn_reservation_lea - insn_reservation_foo' is already defined Anyone can help me through this please? Thanks - Joey
4.4 use static_assert or #warning for unimplemented c++0x std libs
Hi, I know that regex in c++0x was not implemented, but later I tried it anyway and my code compiled but did not do a match. I looked at the tr1_impl and the most functions have a \TODO implement and the function just returns a default "do nothing". Is it possible to have some sort of protocol in gcc, so that any unimplemented library function uses #warning or static_assert(0,"regex not implemented") to not to confuse any future users? I don't think gcc should provide headers that compile but don't do anything. Thank you for the existing c++0x, Love it, Chris
Re: Xtensa port maintainer
Could I ping on the issue described below? Bob can no longer maintain the Xtensa port for GCC, and I don't think he is even reading the GCC mailing list any more. For the forseeable future, I am responsible for the Xtensa port of GCC here at Tensilica. What should I do to move the process forward? Thanks, Sterling Bob Wilson wrote: I am moving to a new job and will no longer be able to serve as the Xtensa port maintainer for GCC. I would like to nominate Sterling Augustine to take my place. Sterling has done a lot of work on the GNU assembler and recently worked on GCC with me to use DWARF unwinding for Xtensa. I think he will do a good job. Would the steering committee please consider that nomination? I am working to hand over what I know to Sterling. If there is anything in particular that I can do to help with the transition, please let me know. It has been great to work with all of you. Working on GCC has been a relatively small part of my job for the last few years, and I would have liked to do more. I have really enjoyed seeing this team of developers from around the world collaborate so well. Thanks to everyone who has helped me out with reviews and suggestions over the years.
Re: 4.4 use static_assert or #warning for unimplemented c++0x std libs
On Mon, Jan 05, 2009 at 11:39:55AM -0800, Chris wrote: > Is it possible to have some sort of protocol in gcc, so that any > unimplemented library function uses #warning or static_assert(0,"regex > not implemented") to not to confuse any future users? I don't think > gcc should provide headers that compile but don't do anything. Yes, it will make it awful hard for autoconf users trying to determine if a feature is supported, if use of that feature produces functions that compile, link, and do nothing with a report of success.
Re: How to define 2 bypasses for a single pair of insn_reservation
Ye, Joey wrote: When I write schedule model for following instructions: Insn1: mov %r1, %r2 Insn2: mov %r1, %r3 Insn3: foo %r2, %r3 (foo is a 3 op insn, for example, %r3 = %r3 << %r2) Latency from insn1 to insn3 is x cycles, and latency from insn2 to insn3 is y cycles. x != y. Both insn1 and insn2 are insn_reservation_mov. Insn3 are insn_reservation_foo. When I define bypass for them I found I couldn't do it. I can only define one bypass from mov to foo, like this: (define_bypass x "insn_reservation_mov" "insn_reservation_foo" "condition1") If I define following bypass too, gcc will report error: (define_bypass y "insn_reservation_mov" "insn_reservation_foo" "condition2") genautomata: bypass `insn_reservation_lea - insn_reservation_foo' is already defined Anyone can help me through this please? It was supposed to have two latency definitions at most (one in define_insn_reservation and another one in define_bypass). That time it seemed enough for all processors supported by GCC. It also simplified semantics definition when two bypass conditions returns true for the same insn pair. If you really need more one bypass for insn pair, I could implement this. Please, let me know. In this case semantics of choosing latency time could be o time in first bypass occurred in pipeline description whose condition returns true o time given in define_insn_reservation
Re: How to define 2 bypasses for a single pair of insn_reservation
Vladimir Makarov wrote: Ye, Joey wrote: ... Anyone can help me through this please? It was supposed to have two latency definitions at most (one in define_insn_reservation and another one in define_bypass). That time it seemed enough for all processors supported by GCC. It also simplified semantics definition when two bypass conditions returns true for the same insn pair. If you really need more one bypass for insn pair, I could implement this. Please, let me know. In this case semantics of choosing latency time could be o time in first bypass occurred in pipeline description whose condition returns true o time given in define_insn_reservation I had a similar problem with ColdFire V4 scheduler model and the solution for me was using adjust_cost() target hook; it is a bit complicated, but it works fine. Search m68k.c for 'bypass' for more information, comments there describe the thing in sufficient detail. -- Maxim
RE: How to define 2 bypasses for a single pair of insn_reservation
Maxim and Vladimir Wrote: >>> Anyone can help me through this please? >>> >> It was supposed to have two latency definitions at most (one in >> define_insn_reservation and another one in define_bypass). That time it >> seemed enough for all processors supported by GCC. It also simplified >> semantics definition when two bypass conditions returns true for the >> same insn pair. >> >> If you really need more one bypass for insn pair, I could implement >> this. Please, let me know. In this case semantics of choosing latency >> time could be >> >> o time in first bypass occurred in pipeline description whose condition >> returns true >> o time given in define_insn_reservation > > I had a similar problem with ColdFire V4 scheduler model and the > solution for me was using adjust_cost() target hook; it is a bit > complicated, but it works fine. Search m68k.c for 'bypass' for more > information, comments there describe the thing in sufficient detail. Thanks Maxim and Vlad, I'd take a look at m68k.c before knowing it is really needed to extension the semantics. Thanks - Joey
Re: Tru64 non-virtual thunks multiply defined
Peter O'Gorman wrote: > > The problems start with r109149 - this patch: > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01905.html > > With this patch reverted we can build qt on Tru64 with gcc-4.2.4. > > I have not yet built trunk on this platform, when I tired bootstrap > failed, will try again now, but I don't believe this has changed much > from 4.2.4. > > Is this patch itself to blame, or does it simply expose a latent bug? It is exposing a latent bug. There was a bug where multiple logically-distinct thunks were emitted even though they all had the same effect, and hence the same names. > Will reverting this patch in the gcc that we ship cause any real > problems? Yes, it may cause the thunks to be placed far from the thunked-to function and hence have jump range problems. Perhaps that's not an issue on Tru64 though nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery
Re: Xtensa port maintainer
On Mon, 5 Jan 2009, Sterling Augustine wrote: > Could I ping on the issue described below? > > Bob can no longer maintain the Xtensa port for GCC, and I don't think he > is even reading the GCC mailing list any more. For the forseeable > future, I am responsible for the Xtensa port of GCC here at Tensilica. > > What should I do to move the process forward? > > Thanks, > Sterling Sorry I missed this back when it was originally posted, and the other SC members likely did also. I'll try and get you going. There are several steps to moving the process forward. They generally need to be done in the order I'm presenting them. 1. The first thing that you need to ensure gets done is copyright assignment papers for your contributions to GCC. Your employer will need to also assign its rights. (One or both of these may already be done). See here for legal and other contribution guidelines: http://gcc.gnu.org/contribute.html 2. Next you need to get write-after-approval access. More info here: http://gcc.gnu.org/svnwrite.html 3. After familiarizing yourself with the above and fulfilling the legal requirements, you can then fill out this form to get access. I guess you can use Bob as the reference who approved it: http://sourceware.org/cgi-bin/pdw/ps_form.cgi 4. Once these are done, the steering committee may decide to grant you maintainership. We generally prefer to see one submit a few patches and see how well they work together with other developers. However since Bob recommended you, the port is unmaintained at the moment and your maintainership perview would be localized to the xtensa subdir it may be possible to expedite this. Let me know the status of the above issues and I will forward your proposal to the SC. Regards, --Kaveh -- Kaveh R. Ghazi gh...@caip.rutgers.edu
