On Sun, 2022-05-01 at 18:09 +0800, WANG Xuerui wrote: > > +cflags-y += $(call as-option,-Wa$(comma)-mno-fix-loongson3-llsc,) > Unfortunately we're still working around the LL/SC hardware issue even > after migrating to LoongArch... might be better to add a comment too. > (something along the line of "we work around the issue manually in the > handwritten assembly, so no automatic workarounds should kick in") There is no LoongArch assembler which is publicly available and has a - m(no)?fix-loongson3-llsc option. The people writing assembly have to add the workarounds manually. This line should be removed for a upstream patch. If you need to support "unpublic" toolchains with this option, keep it in a seperate git repo or branch. Regarding LL/SC workaround, GCC is using a different pattern: (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/loongarch/sync.md;h=0c4f1983;hb=HEAD#l132) 132 return "%G5\\n\\t" 133 "1:\\n\\t" 134 "ll.<amo>\\t%0,%1\\n\\t" 135 "bne\\t%0,%z2,2f\\n\\t" 136 "or%i3\\t%6,$zero,%3\\n\\t" 137 "sc.<amo>\\t%6,%1\\n\\t" 138 "beq\\t$zero,%6,1b\\n\\t" 139 "b\\t3f\\n\\t" 140 "2:\\n\\t" 141 "dbar\\t0x700\\n\\t" 142 "3:\\n\\t"; Note that the dbar instruction has "hint" 0x700 instead of 0 (using a special number was proposed by me, so an updated LoongArch implementation can recognize and ignore this instruction when the workaround is unneeded). And the instruction is "skipped" by the previous "b" instruction. I guess it's enough to "force" LA464 to behave correctly for the LL/SC loop w/o really inserting a barrier. GCC LoongArch port maintainers have not publicly explained the rational of this pattern, but it works fine in userspace on a 3A5000 processor. Maybe the kernel could also benefit from this "new" pattern but I'm not sure. I suggest to discuss this with your compiler team and hardware team. -- Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
