This is the mail archive of the
mailing list for the GCC project.
Re: Support for architectures without hardware interlocks
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Claudiu Zissulescu <claziss at gmail dot com>
- Cc: gcc at gcc dot gnu dot org, David Kang <dkang at isi dot edu>
- Date: Thu, 08 Jan 2015 16:01:10 +0100
- Subject: Re: Support for architectures without hardware interlocks
- Authentication-results: sourceware.org; auth=none
- References: <1804367521 dot 968343 dot 1414782044572 dot JavaMail dot root at zm dot isi dot edu> <1486967563 dot 968382 dot 1414782209571 dot JavaMail dot root at zm dot isi dot edu> <CAL0iMy1ruKdOwsU5nT1cvH10BeVcO7KqPQeH9C_hcSHtcNbbzQ at mail dot gmail dot com>
> 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.