This is the mail archive of the gcc-patches@gcc.gnu.org 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] |
This patch adds support for using strongly-isolated HTMs with serial-irrevocable mode as fallback. Such HTMs can execute uninstrumented code transactionally, and eventually aborted transactions will cause no visible side effects. Data conflicts with nontransactional accesses lead to transactions being aborted. To keep runtime overheads low, this is implemented as a fastpath that gets executed early during transaction start and commit. If the uninstrumented code path is available, it will be used; otherwise, a minimal TM method will be used, which is similar to the one used for serial-irrevocable mode. This method is in a new method group to facilitate existing libitm infrastructure to switch between TM methods. In case the HTM cannot execute a certain transaction due to architectural limitations, or just to ensure forward progress, transactions will switch to the fallback mode after a certain number of aborts. The fallback is serial-irrevocable mode, which is a simplistic fallback but also simplifies the HTM fastpatch (ie, no complex hybrid STM/HTM scheme is necessary). Concurrent active hardware transactions monitor the writer flag in gtm_rwlock, so a start of a serial-irrevocable transaction will abort all of them and prevent concurrent hardware transactions to run as long as the serial-irrevocable transaction is present. The fastpath is only compiled if the target architecture supports a suitable HTM. Right now, only support for Intel RTM is implemented, but other strongly-isolated HTMs could use the fastpath as well. RTM is only used if the assembler supports the respective instructions. The fastpath is only enabled if the HTM method group is used and if the current CPU at runtime supports the HTM. The method group can be either enabled explicitly (ITM_DEFAULT_METHOD=htm) or will be enabled by default if more than one thread uses transaction and the CPU supports the HTM. Note that this is meant to be used in combination with the compiler support for generating uninstrumented code paths, for which Aldy and/or Richard will post a patch today. Without uninstrumented code paths, each transactional memory load and store will still result in a call to a libitm function, which is not necessary when using an HTM and will likely result in lower performance. OK for trunk? Torvald
Attachment:
patch1
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |