[Buildroot] [PATCH 2/2] arch/arc: arc7x0 always needs -matomic

[Yann E. MORIN <yann.morin.1998@free.fr>]

Alexey, All,

On 2019-06-03 05:42 +0000, Alexey Brodkin spake thusly:
> > Alexey, last time I asked [0], you did not reply, so here goes again: what
> > variants of ARC really require -matomic, as you reported on [2] [3].
> > 
> > From [1], I understood that only arc700 was impacted, but the existing
> > condition to add -matomic for arc [4] is not the same.
> > 
> > So, quid?
> 
> That's indeed not super straight-forward.
> 
> As of today we have 2 families of cores capable of running full-scale OS,
> i.e. with MMU at least. These are ARC700 [1] and ARC HS [2].
> 
> And while all ARC HS cores have support of atomic instructions in their
> base configurations in case of ARC700 they were not included in base configs
> (I guess because back in the day in absence of SMP everybody was happy with
> compare-exchange). What's worse those atomic-less configurations really exist
> and that's why I'd still prefer to support them.
> 
> Speaking about atomics support in the toolchain we keep "-matomic" disabled
> for "-mcpu=arc700" and have it enabled for all ARC HS varieties
> (hs, hs38, hs38_linux etc), see:
> 
> | # arc-linux-gcc -mcpu=arc700 -Q --help=target | grep matomic
> |   -matomic                              [disabled]
> | #?arc-linux-gcc -mcpu=archs -Q --help=target | grep matomic
> |   -matomic                              [enabled]
> 
> I.e. passing "-matomic" for ARC HS makes not much sense - it's enabled already
> implicitly due to either "-mcpu" on GCC invocation or "--with-cpu" on GCC
> configuration.
> 
> Now answering your and Tomas' questions:
> 1. In theory ARC750 is exactly that legacy configuration w/o atomics so we
>    may just depend on "BR2_arc750d".
> 2. In practice given atomics might be disabled (or enabled) during core
>    configuration [while designing the chip based on ARC700 family] it
>    might still be a better option to rely on "BR2_ARC_ATOMIC_EXT" which:
>      a) Gets pre-set of !BR2_arc750d
>      b) Might be changed by a user
> 
> That said I don't have a firm preference here.
> 
> If you feel that dropping BR2_ARC_ATOMIC_EXT and relying on "BR2_arc750d"
> for disabling atomics makes BR code cleaner let's go that way.

Thank you very much for these detailed explanations.

However, I am still unsure what to do, and under which conditions we
want to force -matomic...

So, I'll respin this series with what I think I have understood. If I
still messed things up, then you'll have to grab the patches and fix
them.

Thanks again! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'