Re: For those who want to automatically generate predicates.md...
Kazu Hirata wrote: I created a set of scripts that generates predicates.md based on PREDICATE_CODES in tm.h. Thank you! I had been planning to do this for the Xtensa port, but your scripts motivated me to do it sooner. I ended up rewriting most of the predicates in Lisp-style, but the scripts were still helpful. I'll post the patch soon. Thanks again. --Bob
Xtensa port maintainer
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: GCC 4.1.0 RC1
I ran the testsuite for an xtensa-elf target and it looks OK: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01243.html There are a few failures but they are not regressions. --Bob
Re: GCC 4.0.3 RC1
Looks OK for xtensa-elf: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00356.html --Bob
Re: Register windows implementation in Xtensa backend
"kernel coder" wrote: > I'm trying to understand the register windows > implementation in xtensa backend.I could not find much theory about > register windows in extensa.I am trying to understand the register > windows implementation by observing the assembly file generated by gcc > for a simple c file. This doesn't really have anything to do with GCC, so this list is not a good place to discuss how register windows work on Xtensa. I will send you a brief description off-list. --Bob
Re: help regarding suif
Vivek, GCC and the GNU project have nothing to do with SUIF. If you want to ask questions about SUIF, you should do so on a more appropriate mailing list. I suggest you look here: http://www-suif.stanford.edu/mailman/listinfo/suif-talk/ Good luck. --Bob
Re: GCC targets need updating for new register allocator
Joseph S. Myers wrote: The new Integrated Register Allocator is now in GCC trunk, and the old allocator is scheduled for removal on or shortly after 25 September. All GCC targets need updating for the new allocator; targets that have not been updated when the old allocator is removed will no longer work and will be added to the deprecation list for GCC 4.4. (After that date target maintainers may remove their targets from the deprecation list as part of the patches updating them for the new allocator; any remaining unconverted targets will be removed from trunk after GCC 4.4 branches along with the other targets deprecated in 4.4.) I have a patch for Xtensa but I'm still tracking down a problem related to the IRA code. I'm sure I'll get it sorted out soon.
Re: POINTER_PLUS branch status?
Andrew Pinski wrote: I cleaned up the code today so it basically ready to be merged, some (most?) of the target headers still need to be fixed for the change. The list of targets which need to be changed is: alpha ia64 mips pa s390sparcstormy16xtensa I don't have access to any of those targets (and I have not built a sim based compiler yet). I would like help converting those last 8, the patch should mirror what was done for rs6000, spu or sh. I'm happy to fix up the Xtensa port for this, but I might not get to it right away. Please don't let me hold you up. Go ahead and merge it whenever it's ready and I'll fix up the Xtensa port after the merge. --Bob
RFA: (dataflow?) testsuite regression since last week
I'm still seeing two testsuite regressions for Xtensa compared to last
Friday:
gcc.c-torture/execute/920501-6.c
gcc.c-torture/execute/930921-1.c
Both tests fail at -O3 with "internal compiler error: in get_biv_step,
at loop-iv.c:792". Neither the Xtensa port nor the loop-iv.c code has
changed since last week in a way that obviously affects this. I'm
suspecting it is somehow related to the dataflow merge, but I don't see any
obvious connections there, either.
I'm not very familiar with loop-iv.c so I would appreciate help
figuring out how to fix this.
Here is what appears to be happening for 930921-1.c. The test program is:
f (x)
unsigned x;
{
return (unsigned) (((unsigned long long) x * 0xAAAB) >> 32) >> 1;
}
main ()
{
unsigned i;
for (i = 0; i < 1; i++)
if (f (i) != i / 3)
abort ();
exit (0);
}
At -O3, function f is inlined into main and "x * 0xAAAB" is recognized as
a DImode induction variable. I'm pretty sure the problem is related
to the lack of an adddi3 pattern in xtensa.md. We rely on optabs.c to
expand DImode addition. If I dump the RTL file, the induction
variable increment looks like:
;; ivtmp$55 = ivtmp$55 + 0x0aaab
(insn 26 25 27 930921-1.c:4 (set (reg:DI 50)
(mem/u/c/i:DI (symbol_ref/u:SI ("*.LC1") [flags 0x2]) [2 S8 A64])) -1
(expr_list:REG_EQUAL (const_double -1431655765 [0xaaab] 0 [0x0] 0 [0x0] 0
[0x0] 0 [0x0] 0 [0x0])
(nil)))
(insn 27 26 28 930921-1.c:4 (clobber (reg:DI 51)) -1 (nil))
(insn 28 27 29 930921-1.c:4 (set (subreg:SI (reg:DI 51) 4)
(plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4)
(subreg:SI (reg:DI 50) 4))) -1 (nil))
(insn 29 28 30 930921-1.c:4 (set (reg:SI 52)
(const_int 1 [0x1])) -1 (nil))
(jump_insn 30 29 31 930921-1.c:4 (set (pc)
(if_then_else (ltu (subreg:SI (reg:DI 51) 4)
(subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4))
(label_ref 32)
(pc))) -1 (nil))
(insn 31 30 32 930921-1.c:4 (set (reg:SI 52)
(const_int 0 [0x0])) -1 (nil))
(code_label 32 31 33 6 "" [0 uses])
(insn 33 32 34 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
(plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 0)
(subreg:SI (reg:DI 50) 0))) -1 (nil))
(insn 34 33 35 930921-1.c:4 (set (reg:SI 53)
(plus:SI (reg:SI 52)
(subreg:SI (reg:DI 51) 0))) -1 (nil))
(insn 35 34 36 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
(reg:SI 53)) -1 (nil))
(insn 36 35 0 930921-1.c:4 (set (reg:DI 45 [ ivtmp$55 ])
(reg:DI 51)) -1 (expr_list:REG_EQUAL (plus:DI (reg:DI 45 [ ivtmp$55 ])
(reg:DI 50))
(nil)))
The failing assertion in get_biv_step() is:
gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
The outer_mode is DImode; the inner_mode is SImode; and extend is
UNKNOWN, since there are no SIGN_EXTEND or ZERO_EXTEND operations
involved here. Is this code intended to work for DImode IVs when
the machine doesn't directly support DImode operations? I don't know
if the problem is in this loop-iv.c code or whether it ought not
recognize the DImode induction variable in the first place.
Help?
Re: GCC 4.2 Branch Status: Slush
Mark Mitchell wrote: When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC 4.2 branch should now be considered slushy; please get my explicit approval before check-in. Obviously, there was no way anyone could have known that, so if things have been checked in since the announcement that's fine; I'll review what's happened and decide what to do. Sorry -- I didn't see your message until after I had applied a few Xtensa-specific patches on the branch yesterday. Anyway, I hope these patches can make it into 4.2.2; if you have concerns or questions about them, let me know if I can help by providing more information. --Bob
