This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] MIPS: Fix PR target/39079, __builtin___clear_cache() broken on SMP ISA_HAS_SYNCI systems.

Richard Sandiford wrote:
David Daney <> writes:
From the bug:

   We expand __builtin___clear_cache() to a 'synci' instruction on
   ISA_HAS_SYNCI systems, which invalidates the icache only on the
   local CPU.

   On an SMP system, the caches on all CPUs should be invalidated.  To
   achieve this we need to drop back to the old way of doing things by
   using the cache flush system call.

To fix this, I added a new command line option (-msynci/-mno-synci) that enables and disables the generation of the synci instruction for clearing the icache. The default is to disable synci, but the default can be overridden at configure time with the --with-synci option.

Thanks for doing this. My only real concern is that having an -msynci option and using it in this way might be confusing. Most other -m instruction options control whether the ISA supports an instruction, whereas here we care about whether an available instruction can be used in a certain way.

What do you think about having an -mmp/-mup pair of options instead?
If the idea's OK, suggestions for better names are welcome.

There are a several issues.

-msynci controls whether or not we emit synci instructions. -mmp says something about the memory architecture of the target, although exactly what is not well defined.

We could arbitrarily say that with -mmp that synci is not safe. But what about the 'sync' that is emitted at the start of all the atomic memory insns and the memory_barrier insn? Would it be safe to remove them under -mup?

Another issue is interlinking -mmp and -mup code. Should there be tagging of the objects and linker support to merge the tags?

In retrospect it seems like a mistake to have added __builtin___clear_cache(). Perhaps we should just revert it and have the only option be multiprocessor safe code.

I don't really have a preference, but something should be done.

David Daney

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]