Repository: quantumlib/qsim (language: python)

Issue:
Can't import qsimcirq on MacOS ARM64
`pip install qsimcirq` works on my Mac with the M1 chip but then `import qsimcirq` gives the following error
```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/honamnguyen/miniconda3/envs/qcircuit/lib/python3.9/site-packages/qsimcirq/__init__.py", line 17, in <module>
    from qsimcirq import qsim_decide
ImportError: dlopen(/Users/honamnguyen/miniconda3/envs/qcircuit/lib/python3.9/site-packages/qsimcirq/qsim_decide.cpython-39-darwin.so, 0x0002): tried: '/Users/honamnguyen/miniconda3/envs/qcircuit/lib/python3.9/site-packages/qsimcirq/qsim_decide.cpython-39-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/local/lib/qsim_decide.cpython-39-darwin.so' (no such file), '/usr/lib/qsim_decide.cpython-39-darwin.so' (no such file)
```
I found these threads [here](https://github.com/nmwsharp/robust-laplacians-py/issues/7) and [here](https://github.com/nmwsharp/robust-laplacians-py/pull/8) that seem to have a solution which is way over my head but might be useful. If not, I'd also appreciate any suggestion for a work-around. Thanks!


Discussion / hints:
I have the same problem where I could install the package but encounter the below error when importing it. 
`ImportError: dlopen(/Users/akimasaihara/opt/anaconda3/lib/python3.8/site-packages/qsimcirq/qsim_decide.cpython-38-darwin.so, 0x0002): Library not loaded: /usr/local/opt/libomp/lib/libomp.dylib
  Referenced from: /Users/akimasaihara/opt/anaconda3/lib/python3.8/site-packages/qsimcirq/qsim_decide.cpython-38-darwin.so
  Reason: tried: '/usr/local/opt/libomp/lib/libomp.dylib' (no such file), '/usr/local/lib/libomp.dylib' (no such file), '/usr/lib/libomp.dylib' (no such file), '/opt/homebrew/Cellar/libomp/13.0.1/libomp.dylib' (no such file), '/usr/local/lib/libomp.dylib' (no such file), '/usr/lib/libomp.dylib' (no such file)`

When I tried using a virtual environment I got the following error during installation.
`note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure
× Encountered error while trying to install package.
╰─> qsimcirq`

Has anyone found any fixes?
Bumping -- Same issue on Monterey 12.3 on an M1. 
This is currently held back by https://github.com/actions/virtual-environments/issues/2187 - in short, we use Github Actions to build and release wheels for each platform, but Github Actions has no M1 runners.

In theory, it should still be possible to install qsimcirq from source (e.g. by downloading and using `make`), but there may be some additional effort needed to get everything to play nicely together.
Investigated with @aasfaw and @mpharrigan, and found that building locally on an M1 is blocked for all versions of qsim except `qsim_basic`. This is because ARM64 does not support the SSE or AVX instruction sets qsim uses for vector optimization, which constitute a significant portion of the performance advantages of qsim.

As a result, we won't be prioritizing an M1 build for qsim in the immediate future. If you use an M1 and would still like to simulate Cirq circuits, you have a few options:
- Install Cirq and qsimcirq in a free [Google Colab](https://colab.research.google.com/) instance. Colab instances are limited to ~28 qubits due to RAM constraints, but otherwise this will provide the full performance of qsim. I recommend this for many users, even those not on M1s.
- Run simulations on a paid GCP VM, following the [provided tutorial](https://quantumai.google/qsim/tutorials/gcp_cpu). GCP offers improved performance over Colab and (depending on the VM type selected) supports up to 40-qubit simulations. This option is best if you absolutely need the performance, but I still recommend running tests in Colab first.
- Fall back on Cirq's built-in simulators. These simulators have improved over the past year, and provide performance approaching that of `qsim_basic`. I don't generally recommend this option, but if you _must_ run simulations on an M1 instance this will do the job.
We should make it clear that our wheels aren't `universal2` so they don't seemingly install successfully but then fail to load

Fix patch:
diff --git a/.github/workflows/release_wheels.yml b/.github/workflows/release_wheels.yml
index abf5c7a1..33550cb7 100644
--- a/.github/workflows/release_wheels.yml
+++ b/.github/workflows/release_wheels.yml
@@ -15,12 +15,7 @@ jobs:
           - os: macos-10.15
             name: mac
             cibw:
-              build: "cp36* cp37* cp38*"
-          - os: macos-10.15
-            name: mac-arm
-            cibw:
-              arch: universal2
-              build: "cp39*"
+              build: "cp36* cp37* cp38* cp39*"
           - os: ubuntu-20.04
             name: manylinux2014
             cibw:


Test patch:
diff --git a/.github/workflows/testing_wheels.yml b/.github/workflows/testing_wheels.yml
index 55dd237a..916f728b 100644
--- a/.github/workflows/testing_wheels.yml
+++ b/.github/workflows/testing_wheels.yml
@@ -20,12 +20,7 @@ jobs:
           - os: macos-10.15
             name: mac
             cibw:
-              build: "cp36* cp37* cp38*"
-          - os: macos-10.15
-            name: mac-arm
-            cibw:
-              arch: universal2
-              build: "cp39*"
+              build: "cp36* cp37* cp38* cp39*"
           - os: ubuntu-20.04
             name: manylinux2014
             cibw: