(People, please don't use my @gcc.gnu.org address if you need to ping me; not sure why Steven used that. I also changed the other CC'ed addresses to the corresponding relevant one from MAINTAINERS.
Looks like I'm month+ behind on reading the lists again... On the plus side, maybe a reply-bump rekindles interest in this rewrite-reorg.c work; go Steven!) > From: Jeff Law <l...@redhat.com> > Date: Thu, 18 Apr 2013 06:22:35 +0200 > On 04/17/2013 03:52 PM, Steven Bosscher wrote: > > First of all: What is still important to handle? > > > > It's clear that the expectations in reorg.c are "anything goes" but > > modern RISCs (everything since the PA-8000, say) probably have some > > limitations on what is helpful to have, or not have, in a delay slot. > > According to the comments in pa.h about MASK_JUMP_IN_DELAY, having > > jumps in delay slots of other jumps is one such thing: They don't > > bring benefit to the PA-8000 and they don't work with DWARF2 CFI. As > > far as I know, SPARC and MIPS don't allow jumps in delay slots, SH > > looks like it doesn't allow it either, and CRIS can do it for short > > branches but doesn't do because the trade-off between benefit and > > machine description complexity comes out negative. That might be a stale comment in cris.md. I think the ISA grew to simply disallow branches (modifying PC) in delay-slots. I guess I should find references for such statements... Anyway, no interest for branches in delay-slots in this port. > > What about multiple delay slots? It looks like reorg.c has code to > > handle insns with multiple delay slots, but there currently are no GCC > > targets in the FSF tree that have insns with multiple delay slots and > > that use define_delay. > Ping Hans, I think he was the last person who tried to deal with reorg > and multiple delay slots (c4x?). I certainly wouldn't lose any sleep if > we killed the limit support for multiple delay slots. By "Hans" do you mean me? No, I didn't do anything serious here besides trying to get the people submitting the port interested in keeping it alive (and failing: "it's a mature port", in the pre-3.0 era IIRC, sheesh). The goal was to get the port maintained, so we'd have *something* keeping the bugs out of the non-8-bit-byte and multiple-insn-delay-slot support. I have a vague recollection (some people would say "know") there are bugs with multiple delay-slots i reorg.c and I agree with previous replies: just point any potential future interest in the direction of Bernd's C6X work. Depending on scheduling is a new dependency, but ok with me. I'd even be happy with some performance regression in filling delay-slot, just to get rid of reorg.c and resource.c! Go Steven! brgds, H-P
