-----Original Message----- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Joel Sherrill Sent: Thursday, January 08, 2015 8:59 PM To: Eric Botcazou; Claudiu Zissulescu Cc: gcc@gcc.gnu.org; David Kang Subject: Re: Support for architectures without hardware interlocks
On 1/8/2015 9:01 AM, Eric Botcazou wrote: >> I've worked on a gcc target that was porting an architecture without >> hardware interlock support. Basically, you need to emit nop >> operations to avoid possible hw conflicts. At the moment, this was >> done by patching the gcc scheduler to do so, Another issue to keep is >> to check for hardware conflicts across basic-block boundaries. And >> not the last, is to prohibit/avoid any instruction stream >> modification after scheduler (e.g., peephole optimizations etc.). > That's an overly complex approach, this usually can be done in a > simpler way with a machine-specific pass that runs at the end of the RTL > pipeline. > >>Isn't this similar to needing to fill a delay slot after a branch >>instruction? My recollection is that some SPARC and MIPS have to deal with >>that. I think this can be done at the machine description md file level with define_delay where the delay slot description can be described. Thanks & Regards Ajit -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
