- User Since
- Mar 11 2015, 2:39 PM (254 w, 4 d)
Fri, Jan 24
Dec 10 2019
Nov 18 2019
Nov 7 2019
@lenary Following the discussion regarding D69383, I think it's best for now to keep the logic just keeping -march directly, rather than using getRISCVArch. I think in the case of -target risc32-..... -mabi=lp64 I think it would confuse users if the tools suddenly changed to doing an rv64 compile. If we disable that, all that function would provide me is the same StringRef I'm already evaluating. I think adding any extra flag to indicate whether a rv32<->rv64 switch is acceptable would just make the code unnecessarily more messy. I think in the future if getRISCVArch evaluates more flags, then it might make sense to reconsider this.
Nov 6 2019
Add diff that has useful context
Nov 5 2019
Oct 25 2019
I have a question about backwards compatibility with this patch. Clang 9 has shipped with rvXXg/etc defaulting to ilp32/lp64 ABI, and no march meaning rvXXi, with users having built objects with those defaults. When Clang 10 ships, users they now need to always use a mabi/march flag to keep the same compatibility with their Clang 9 flows, the enabled extensions and ABI will be changed under their feet without warning (or at least until they either hit a linker error in the ABI case, or potentially an invalid instruction trap in the march case).
Oct 23 2019
Oct 22 2019
Ping, before I rebased this did anyone have any other thoughts on flag precedence?
Oct 21 2019
Rebase, implement all hooks that aren't PrepareTrivialCall/function calling related. If its possible to commit these two separately, I think it would be best to have that as a separate patch whereby preparing arguments for the various RISC-V hard-float ABIs can be done independently of breakpoints/unwinding/etc.
Oct 14 2019
Oct 3 2019
Rebase on top of tree, add @luismarques as reviewer
Sep 19 2019
Update to reflect comments about the fact registers are explicitly reserved. In addition to @lenary 's suggested change, I renamed isReservedReg to note the check that we are checking if its a user provided reservation.
Sep 6 2019
Update based on initial feedback/going down the providing error route.
Sep 5 2019
For added context, I have gone and double-checked with GCC's implementation both for AArch64 and RISC-V and for registers used by the calling convention the compiler will still use them for argument passing and return values, but otherwise won't use it for any temporaries/register allocation purposes, which does have the side effect of confusing behaviour unless carefully documented.
Thanks for the feedback. I will improve the test so it more reliably tests what it intends to.
Sep 4 2019
Sep 3 2019
Aug 8 2019
In that case LGTM
Other than my small suggestion about the use of NoRegister, this looks good to me.
Aug 5 2019
Aug 1 2019
Rebase on top of tree.
Jul 31 2019
Jul 29 2019
Jul 25 2019
Jul 15 2019
As an aside, I've noticed a codegen issue when using floating point clobber lists, resulting in the implicit-defs not being added to INLINEASM instructions. I'm working on a fix for that now and will submit a second patch shortly.
Jul 3 2019
Jun 18 2019
- Refactored register tables to match style used in i386/x86_64
- Add enum for RISC-V DWARF numbers
- Add F registers (assuming 32-bit, at runtime this seems to be overwritten to 64-bit if D extension is provided)
- Add default unwind plan for first frame
May 31 2019
Jan 31 2019
As this mllvm option only affects the creation of ELF objects, do we also need to add a similar option for the LTO case, as the -G value would have no effect otherwise?
Nov 7 2018
Oct 15 2018
I tried building this on top of trunk but my build failed with this assertion:
Aug 15 2018
My tests now look better, there are a couple of failures, but this seems to be a bug in newlib, rather than with clang/this patch (the bug was masked before as we would have been pulling in system headers). So this patch looks good to me.
Aug 14 2018
I've tested this, regression tests involving linking now mostly pass as crt0 can now be found, but it seems that system headers are still being pulled in causing a couple of tests to fail. In particular using limits.h is causing build failures for me.
Aug 2 2018
It seems the ability to link objects has been broken by this change. As an example from our nightly tests:
Jun 21 2018
I think this should also cover mismatched arguments if the attribute appears several times, and reject/warn about the attribute combination in these cases.
May 23 2018
May 22 2018
Note: I've marked this as WIP whilst discussing the interface, I'm not suggesting hardcoding in a setSTI() function to MCAsmBackend, that will be removed from the final patch
Rebased on top of tree, and applied changes as per Alex's review.
I agree, the route you have taken in D46965 seems the best route to go down. Unless we end up with some fixup where we want to manipulate bytes that wouldn't be covered by that calculation (it seems unlikely), then all this table is doing is duplicating what information we already have, so I think it's best to use your calculation.
May 11 2018
May 4 2018
May 3 2018
Apr 19 2018
I've readded the reloc check line to hilo-constaddr.s and renamed hilo-constaddr-invalid.s to hilo-constaddr-expr.s since it is no longer checking something that is always invalid.
Apr 16 2018
I've rebased the change on top of D44886 to indicate what is conditional based on linker relaxation.
Apr 7 2018
Take part of test I removed as it now produces and error, and turn it into an explicit test for an error message.
Apr 6 2018
The previous diff had one change missing from my original patch, that is now restored.
I've updated the patch to respond to comments, and deal with the couple of test failures I was seeing.
Apr 4 2018
Apr 2 2018
Nov 15 2017
Thanks, I found one nitpick with a couple of the tests, but the rest looks good to me.