- User Since
- Oct 20 2016, 2:25 AM (243 w, 4 d)
Mon, Jun 14
Tue, Jun 8
Fri, Jun 4
- Using less invasive way to add intrinsic functions.
Thu, Jun 3
The testcase I provided in last comment could be compile successfully with aarch64-gcc, but failed on clang.
Testcase for AArch64/SVE:
Wed, Jun 2
I would suggest few more line on testcase:
Thu, May 27
Personally I prefer to deprecate -mno-div soon, but based on the rule for RISC-V GNU toolchain, it need to wait Zmmul extension frozen.
My plan is deprecate the -mno-div and emit warning to tell user should use Zmmul instead once it frozen.
Wed, May 26
If .option norelax is the agreed-upon choice (is it?), can I get a stamp?
I did not participate in the meetings you have ... and I am confused about the state now.
We have Zmmul extension in the ISA spec now, that's equivalent to -mno-div , so I suggest we should go forward to implement that extension rather than -mno-div.
Tue, May 25
I think an assembler only option should be spelled as -Wa,*. The driver option isn't useful and should just be avoided.
For -mno-relax, I think there can be arguments that the assembler generation may be affected (to appease assembler, for example) so a driver option is needed.
If the driver option -mno-relax is still preferred over -Wa,-mno-relax, I can abandon this and submit another one passing -mno-relax to GNU as for -fno-integrated-as.
GCC pass -mno-relax to assembler now: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3b0a7d624e64eeb81e4d5e8c62c46d86ef521857
Mon, May 24
After discussion with Jim W, we think it's OK to pass -mno-relax to as for GCC, and we could sent patch recently, but keep emitting .option norelax for this moment to make sure the compatibility, and remove that later after 1 or 2 GCC version (that's means 1~2 years in generally)
Personally I prefer keep compatible with GNU toolchain behavior on this, so this patch is LGTM.
May 12 2021
Maybe you could pre-commit the test case to easier demonstrate the change of this patch?
Could you handle k* extension for ELF attribute?
Apr 15 2021
Could you also check the compiler diagnostic messages? it will report __builtin_rvv_vadd_vv_i8m1 or vadd_generic if argument type mis-match, which one you expected? I assume without __clang_riscv_builtin_alias clang will report vadd_generic?
Few more word for this issue, the option order is matter for linker both for GNU ld and lld, in the test @arcbbb provided, ABC will treat as undefined in a.lds if the order is wrong.
Apr 7 2021
I don't know who is the right people to add as reviewer here, and I saw @MaskRay and @lenary you guys has reviewed this repo before, and most important is I know you guys :P so could you help me to review that or find the right people to review that? Thanks :)
Apr 6 2021
News of Glibc 2.32:
Apr 1 2021
Created an issue for continue discuses on riscv-c-api-doc
General code gen behavior change is look good to me.
Mar 30 2021
Mar 29 2021
LGTM for NaN-boxing behavior.
Mar 25 2021
I just found an issue is unrelated this patch, but related to fp16, RISC-V GCC using the traditional libgcc function name scheme like __extendhfdf2(__<op><srcT><dstT><N_OP>) rather than __gnu_f2h_ieee (__gnu_*2*_ieee).
Mar 17 2021
- Add more verbose message during reading GCC multilib configuration.
- Add test case to verify verbose messages.
Mar 16 2021
This still doesn't report that the multilib configuration came from GCC when it succeeds, does it? I suppose that's not a deal-breaker, but it would be nice to have. Would it be difficult to implement?
Address jrtc27's and luismarques comment
Mar 15 2021
Provide more implementation detail on GCC,
- if a letter are used as a prefix of multi-char constraint, then it can't be used as a single letter constraint
- e.g. If we defined vr and vm then we can't define v as constraint
- constraint with same prefix should have same length
- e.g. If we defined vr and vm then we can't define vrr since has different length.
GCC use vr for vector register and vm for vector mask register.
Mar 5 2021
Mar 4 2021
- Fix build issue.
- Address Jim Lin's and Zakk's comment
Here is another solution for flexible multi-lib configuration I consider before:
Address MaskRay's comment and apply clang-format.
Mar 3 2021
Minor clean up
Update SUMMARY, first version I just incorrectly said ACLE didn't clarify the default argument promotion rule, but I found that in ARM ABI spec later.
Mar 2 2021
Feb 1 2021
Jan 25 2021
Jan 24 2021
Jan 22 2021
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.
Jan 21 2021
@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.
Jan 19 2021
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.
Jan 17 2021
Thanks you implement that on clang, I think it's really great to included that in LLVM 12 release.
Jan 12 2021
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...
Jan 10 2021
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
Jan 7 2021
Don't allow function arguments or returns to use structs containing scalable vectors unless they are intrinsics.
Jan 5 2021
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.