[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-04-12
         AssignedTo|unassigned at gcc dot       |olegendo at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-04-12 06:31:06 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > Other than that, should we add another option '-mhard-atomic' (which would
> > enable the movco/movli atomics on SH4A and disable all atomic insns for
> > non-SH4A)?
> 
> I think so.
> 
> > Actually, I think the options should be '-msp-atomic' and '-mmp-atomic', where
> > '-msp-atomic' would be the current '-msoft-atomic'.
> 
> I don't think that -msp/mmp-atomic are good naming here.  SP/MP notion
> is not directory connected with the soft/hard implementation of atomics,
> even if soft atomics are impossible for real MP system.  Hard atomics
> should work with both SP and MP.  I guess that the point is the necessity
> of kernel (i.e. software) services.  If the atomics require kernel services,
> they are "soft" atomics even some of them utilize the LL/SC-like insns.
> If they don't require any kernel services, they are "hard" atomics.
> Using -msp-atomic for "soft" atomics looks a bit misleading, from this point
> of view.

Yeah, probably.  My idea behind -msp-atomic was that it would be allowed to do
anything that works safely on an SP system, be it soft atomics or hard atomics.

> Perhaps an unsupprising way would be enable movco/movli on SH4A with both
> -msoft-atomic/-mhard-atomic if we can.

OK, will do it then :)

One more thing regarding movco/movli ... do you think it's OK to use them also
to do atomics on types < SImode?  As far as I can see it should be safe to do
e.g. read SImode, modify QImode subreg, write-back SImode.