[Bug target/50457] SH2A atomic functions

["olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457

--- Comment #16 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-11-12 20:57:12 UTC ---
Another thing that might be useful for dealing with atomics on SH1* and SH2*
targets is to make the compiler generate the rewind sequences in interrupt
handler functions.

On SH3* and SH4* targets, the interrupt handling jump table is usually designed
in such a way, that it can contain (small) setup code before a user specified
interrupt handling function is invoked.
However, on SH1* and SH2* targets, the processor directly jumps to the user
specified interrupt handling function via the interrupt jump table.  It would
be possible to have two such jump tables, where code in the first table handles
atomic sequence rewinding and then jumps to the second (actual) interrupt
handling function specified by the user.  This is not necessary, if the
compiler can insert the atomic sequence rewind code snippet (according to the
currently selected atomic model) at the beginning of an interrupt handler
function.  Moreover, the compiler can omit the atomic rewind sequence if...
* an ISR doesn't call any other (non-inlined) functions
* an ISR doesn't contain any atomic sequences itself

For example, a very simple timer ISR that just increments the high word of the
system's free running timer doesn't need to handle any atomics.

Another example would be an SCI/SCIF ISR that receives/sends data to/from a
buffer.  In this case, the ISR probably has two code execution paths.  While
the receive/send operation is still in progress the code path is probably very
short and updates only a few internal variables, which doesn't need any atomic
handling.  When the receive/send operation has completed, the completion
condition has to be propagated to user code and most likely requires calling
other functions and thus handling atomic sequences.  Ideally, the compiler
would insert atomic handling code in the ISR only to those paths, which
actually need it.  This would reduce interrupt handling time.

I'd propose to add a new function attribute 'handle_atomics' that can be used
in combination with the 'interrupt_handler' function attribute for this.
SH3* and SH4* targets could also benefit from this.