|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4 |
|
| #
9067070d |
| 16-Apr-2024 |
Craig Topper <craig.topper@sifive.com> |
[RISCV] Re-separate unaligned scalar and vector memory features in the backend. (#88954)
This is largely a revert of commit
e81796671890b59c110f8e41adc7ca26f8484d20.
As #88029 shows, there exist
[RISCV] Re-separate unaligned scalar and vector memory features in the backend. (#88954)
This is largely a revert of commit
e81796671890b59c110f8e41adc7ca26f8484d20.
As #88029 shows, there exists hardware that only supports unaligned
scalar.
I'm leaving how this gets exposed to the clang interface to a future
patch.
show more ...
|
|
Revision tags: llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
| #
e8179667 |
| 01-Dec-2023 |
Philip Reames <preames@rivosinc.com> |
[RISCV] Collapse fast unaligned access into a single feature [nfc-ish] (#73971)
When we'd originally added unaligned-scalar-mem and
unaligned-vector-mem, they were separated into two parts under th
[RISCV] Collapse fast unaligned access into a single feature [nfc-ish] (#73971)
When we'd originally added unaligned-scalar-mem and
unaligned-vector-mem, they were separated into two parts under the
theory that some processor might implement one, but not the other. At
the moment, we don't have evidence of such a processor. The C/C++ level
interface, and the clang driver command lines have settled on a single
unaligned flag which indicates both scalar and vector support unaligned.
Given that, let's remove the test matrix complexity for a set of
configurations which don't appear useful.
Given these are internal feature names, I don't think we need to provide
any forward compatibility. Anyone disagree?
Note: The immediate trigger for this patch was finding another case
where the unaligned-vector-mem wasn't being properly serialized to IR
from clang which resulted in problems reproducing assembly from clang's
-emit-llvm feature. Instead of fixing this, I decided getting rid of the
complexity was the better approach.
show more ...
|
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1 |
|
| #
b83a1ed5 |
| 18-Sep-2023 |
Piyou Chen <piyou.chen@sifive.com> |
[RISCV] Only emit .option when extension is supported
It maybe emit the .option directive without any follow up. Only emit the .option push/pop when there are supported extension difference between
[RISCV] Only emit .option when extension is supported
It maybe emit the .option directive without any follow up. Only emit the .option push/pop when there are supported extension difference between function and module.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D159399
show more ...
|
|
Revision tags: llvmorg-17.0.0 |
|
| #
d861b318 |
| 18-Sep-2023 |
Piyou Chen <piyou.chen@sifive.com> |
[RISCV][NFC] precommit for D159399
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D159400
|
|
Revision tags: llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3 |
|
| #
8901eb28 |
| 10-Aug-2023 |
Jianjian GUAN <jacquesguan@me.com> |
[RISCV] Fix zihintntl test
|
|
Revision tags: llvmorg-17.0.0-rc2 |
|
| #
05041b78 |
| 03-Aug-2023 |
Piyou Chen <piyou.chen@sifive.com> |
[RISCV] emit .option directive for functions with target features which differ from module default
When function has different attributes from module, emit the .option <attribute> before the functio
[RISCV] emit .option directive for functions with target features which differ from module default
When function has different attributes from module, emit the .option <attribute> before the function body. This allows non-integrated assemblers to properly assemble the functions (which may contain instructions dependent on the extra target features).
Reviewed By: craig.topper, reames
Differential Revision: https://reviews.llvm.org/D155155
show more ...
|