diff options
| author | Craig Topper <craig.topper@sifive.com> | 2021-05-26 09:31:01 -0700 |
|---|---|---|
| committer | Craig Topper <craig.topper@sifive.com> | 2021-05-26 09:56:20 -0700 |
| commit | b2c7ac874f516df38968d02636ecab7730ca9323 (patch) | |
| tree | 5a70d6cb5c922edee966e21ee56fe7124b9bde81 /llvm/lib/Analysis/LoopCacheAnalysis.cpp | |
| parent | a45877eea8c424cd91bc1f7749313c9cb3aab285 (diff) | |
| download | llvm-b2c7ac874f516df38968d02636ecab7730ca9323.zip llvm-b2c7ac874f516df38968d02636ecab7730ca9323.tar.gz llvm-b2c7ac874f516df38968d02636ecab7730ca9323.tar.bz2 | |
[RISCV] Don't propagate VL/VTYPE across inline assembly in the Insert VSETVLI pass.
It's conceivable someone could put a vsetvli in inline assembly
so its safer to consider them as barriers. The alternative would
be to trust that the user marks VL and VTYPE registers as clobbers
of the inline assembly if they do that, but hat seems error prone.
I'm assuming inline assembly in vector code is going to be rare.
Reviewed By: frasercrmck, HsiangKai
Differential Revision: https://reviews.llvm.org/D103126
Diffstat (limited to 'llvm/lib/Analysis/LoopCacheAnalysis.cpp')
0 files changed, 0 insertions, 0 deletions