- User Since
- Oct 20 2016, 2:25 AM (222 w, 1 d)
In the mean time I will park this change, and add 'v' implying its subfeatures in clang, since this would catch most cases we expect users to use (I don't think manually enabling features is a common use case). I can then later look at a more detailed/complete fix when enabling features directly with -mattr.
@jrtc27 just let you know I have same concern too, that's one major reason why we don't upstream those extension on GNU toolchain... we are intend to introduce an internal revision number on ELF attribute in near future, e.g. v-ext 0.9.1 / v0p9p1 to prevent compatible issue here.
Note from the last sync up call, it's ok to landing that once review is done without refactor, refactor could be done separately after LLVM 12 release, that's won't be a blocker issue for this patch.
I believe the behavior has aligned to GCC now.
Add a dedicated test file to demonstrate and verify the ABI would be better.
Tue, Jan 19
Just note how current GCC implemented, GCC implement that like implied extension, e.g. V implied Zvamo and Zvlsseg, so __riscv_zvamo is naturally defined when V-ext is enabled.
I think maybe we could extract the arch parser from driver to llvm/lib/Support, so that we could just maintain one parser for driver and assembler, and there is also other potential user for that, like the C front-end for the target attribute, e.g. __attribute__ ((target ("arch=rv64gcv"))), and the linker can re-use that to read/merge/write the attribute too.
Sun, Jan 17
That's my fault, I didn't specify the behavior of sub-extension clearly on the spec, but I think it would be great if we also define sub-extension marcos, since it would be easier to check when some core only implement sub-extension, and the code can just check the sub-extensio rather than check both.
Tue, Jan 12
RVB 0.93 is an awkward version to me, there is mnemonic conflict which is not resolved during release process since it's kind of too rush, the conflict one is bext in zbe and zbs...
Sun, Jan 10
This patch removes the existing restriction for this. I've modified
StructType::isSized to consider a struct containing scalable vectors
as unsized so the verifier won't allow loads/stores/allocas of these
Thu, Jan 7
Don't allow function arguments or returns to use structs containing scalable vectors unless they are intrinsics.
Tue, Jan 5
Note from gnu toolchain side, GCC will detect bintuils version and behavior during configure time and set different default behavior according the version or feature support test result, but I know clang/llvm doing different way on this part.
Dec 21 2020
Dec 19 2020
64 bit splat on rv32 code gen sequence is LGTM, but I think that's all I can review :P
Dec 17 2020
I was wondering if we could do something like (with a0=lo and a1=hi):vmv.v.x vX, a1 vsll.vx vX, vX, /*32*/ vor.vx vX, vX, a0
And then do a .vv operation.
We can then optimize for a sign-extended 32-bit value later. What do you think?
Also, it will not handle 64-bit scalars in RV32, but I don't believe that's
actually supported in the spec?
Dec 16 2020
Do you have implement register pair for rv32ifd_zfinx? I didn't saw the related implementation, but I could be wrong since I am not LLVM expert, in case you have implemented, you need a test case for that.
Dec 10 2020
Dec 9 2020
Spec changes has been merged :)
Dec 8 2020
That's LGTM too, just waiting the spec merge :)
Dec 7 2020
Nov 11 2020
I think zv* need to set too, seems like we should have more word about extension is consisted with several sub-extensions on the ELF attribute spec.
Nov 10 2020
Could you add zfh to ELF attribute output?
Oct 14 2020
@MaskRay Thanks, that's first time I know the suffix -SAME :P
- Update testcase according to MaskRay's suggestion.
- Fix wording in comment
- Add more comment in testcase
- Fix format issue.
Oct 13 2020
If possible that would good, since -mcpu is deprecated (for e.g. x86_64) or unsupported in GCC (for e.g. RISC-V). So doing that would further align Clang with GCC. But I wonder if this might be too problematic, in terms of compatibility.
Oct 12 2020
Oct 7 2020
Sep 24 2020
But this logic is enabled only if CRT_HAS_INITFINI_ARRAY is not defined. Which is controlled by cmake (configuration script). In addition, other architectures (x86, sparc, arm, aarch64, sparc, powerpc) - do allow such fallback option. It just seems strange that RISCV does not have one.
Sep 22 2020
RISC-V LLVM and GCC are default using init_array, curious why we need this?
Aug 19 2020
GCC part should review at gcc-patch mailing list instead of here, for other files (sanitizer_platform.h, sanitizer_common.h and sanitizer_symbolizer_libcdep.cpp), it's right place to review, but it should using the diff which generated within LLVM source-tree, and GCC will sync libsanitizer after LLVM is accepted.
What about config/riscv/riscv.c? Should I place it here to review?
Aug 18 2020
Aug 6 2020
Zvamo implies A-extension.
I think it's require instead of imply?
May 28 2020
May 7 2020
Upstream didn't support those SiFive specific function attribute, and there is no plan to upstream unless CLIC ratified.
And I guess the attribute name would changed after GCC upstream, at least the prefix of SiFive- would be removed.
Apr 30 2020
Another proposal for -mcpu and -mtune:
Feb 23 2020
Could you add following kind of test:
Jan 10 2020
It seems to me that all remarks have already been addressed. Is there anything holding this patch? For it pretty much LGTM.
Jan 9 2020
Seems like this patch mixed with LTO related changes? Could you clean it up?
Nov 14 2019
In addition, I think my testcase is so weird and it does not make sense there are different isa extension are used in the same compilation unit...
Nov 8 2019
Oct 16 2019
Oct 8 2019
Sep 17 2019
Sep 12 2019
Sep 2 2019
Aug 1 2019
Jul 2 2019
Jul 1 2019
Add 2 test cases.
@MaskRay Thanks, I'll add test case soon :)
Feb 19 2019
Feb 10 2019
- Update test/MC/RISCV/rvi-pseudos-invalid.s
Feb 5 2019
- Fix parseBareSymbol with a constant symbols.
- Rebase to D55325
Jan 24 2019
@jrtc27 feel free to upload your one, it's just a 5 minute quick patch :P
Jan 23 2019
Jan 16 2019
- Update testcase, R_RISCV_RELAX won't bind with symbol to fit binutils's behavior.
Jan 14 2019
- Add missing tests
Jan 10 2019
Okay, I'll take a look :)
- Merge emitLoadLocalAddress/emitLoadSymbol/emitStoreSymbol
- Fix wrong operand type and syntax for floating point load instruction.
Oct 15 2018
rv32e arch and ilp32e ABI is decoupling in GCC, that's mean rv32i with ilp32e is possible, so I would suggest separate two thing.
Oct 4 2018
GCC using 5 as threshold to decide using jump table or not for RISC-V and LLVM using 4.
Sep 26 2018
Sep 17 2018
Aug 29 2018
Aug 22 2018
- Add test.
- Move declaration of RelaxCandidate.
- Add comment.
- Update testcase
Aug 13 2018
- Rename functions
- emitLoadSymbolAddress -> emitLoadSymbolAddressHi
- emitLoadWithSymbol -> emitLoadSymbol
- emitStoreWithSymbol -> emitStoreSymbol
- Return shouldForceImediateOperand to true for new pseudo instructions.
- Add negative test
Aug 9 2018
- Add default case in switch.
Aug 2 2018
Rearrange order for testcase.
- Update testcase for rv32i-aliases-invalid.s and rv64i-aliases-invalid.s
- Fix rv32i-invalid.s
- Add addw, sllw, srlw and sraw including testcase.
- Add comment in testcase.
Jul 31 2018
ping, Alex, could you commit that?