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.
