diff options
| author | Craig Topper <craig.topper@intel.com> | 2018-06-19 18:06:52 +0000 |
|---|---|---|
| committer | Craig Topper <craig.topper@intel.com> | 2018-06-19 18:06:52 +0000 |
| commit | 0b7936737b0488d06a8a3ce3c37a4836309bc08d (patch) | |
| tree | f724580a498b41556913d0a847ebf4f44cc95ecf /lldb/packages/Python/lldbsuite/test/python_api/signals/TestSignalsAPI.py | |
| parent | 456699ddd1eddad07e3e85ae082e54b6a6221a6d (diff) | |
| download | bcm5719-llvm-0b7936737b0488d06a8a3ce3c37a4836309bc08d.tar.gz bcm5719-llvm-0b7936737b0488d06a8a3ce3c37a4836309bc08d.zip | |
[X86] Initialize FMA3Info directly in its constructor instead of relying on std::call_once
FMA3Info only exists as a managed static. As far as I know the ManagedStatic construction proccess is thread safe. It doesn't look like we ever access the ManagedStatic object without immediately doing a query on it that would require the map to be populated. So I don't think we're ever deferring the calculation of the tables from the construction of the object.
So I think we should be able to just populate the FMA3Info map directly in the constructor and get rid of all of the initGroupsOnce stuff.
Differential Revision: https://reviews.llvm.org/D48194
llvm-svn: 335064
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/signals/TestSignalsAPI.py')
0 files changed, 0 insertions, 0 deletions
