Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow assembling with LLVM #391

Merged
merged 3 commits into from
Sep 28, 2023

Conversation

arichardson
Copy link
Contributor

Description

This PR adjusts the tests frameworks such that it can be assembled with an upcoming version of LLVM.

  • The TEST_JAL_OP macro used an incorrect label reference in an .if check which was flagged by LLVM but accepted by GCC (most likely by performing a string comparison instead)
  • The LLVM assembler does not accept string comparisons such as
    \__MODE__\() == M in .if and instead requires the .ifc/.ifnc directive.

With LLVM patched to include llvm/llvm-project#67377
I was able to use riscof to compare RV64 sail assembled with LLVM vs.
RV64 sail assembled with GCC.

See individual commit messages for more details (not sure what the workflow is but since there are detailed commit messages please don't squash and merge).

Related Issues

NA

Ratified/Unratified Extensions

  • Ratified
  • Unratified

List Extensions

NA

Reference Model Used

  • SAIL
  • Spike
  • Other - < SPECIFY HERE >

Mandatory Checklist:

  • All tests are compliant with the test-format spec present in this repo ?
  • Ran the new tests on RISCOF with SAIL/Spike as reference model successfully ?
  • Ran the new tests on RISCOF in coverage mode
  • Link to Google-Drive folder containing the new coverage reports (See this for more info): < SPECIFY HERE >
  • Link to PR in RISCV-ISAC from which the reports were generated : < SPECIFY HERE >
  • Changelog entry created with a minor patch

Since this does not add new tests, some of these are N/A?

Optional Checklist:

  • RISCV-V CTG PR link if tests were generated using it : < SPECIFY HERE >
  • Were the tests hand-written/modified ?
  • Have you run these on any hard DUT model ? Please specify name and provide link if possible in the description
  • If you have modified arch_test.h Please provide a detailed description of the changes in the Description section above.

@arichardson arichardson changed the title Assemble with llvm Allow assembling with LLVM Sep 26, 2023
Copy link
Collaborator

@allenjbaum allenjbaum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

@arichardson
Copy link
Contributor Author

Looks good to me

Thanks for the review - what should I update the date and version of changelog entry to to allow merging this?

@allenjbaum
Copy link
Collaborator

allenjbaum commented Sep 27, 2023 via email

When assembling with LLVM, this macro produces the following:
`error: directional label undefined`. This happens because it compares
the symbol value rather than performing a textual comparison. At the
point the 3f label is referenced it is actually a backwards reference
so we would have to use 3b instead. Fix this by using a `.ifc` string
comparison directive instead.
The LLVM assembler does not accept string comparisons such as
`\__MODE__\() == M` and instead requires the .ifc/.ifnc directive.
This requires expanding some .elseif to nested else since GNU AS does
not allow use of `.elseifc` (although in this case LLVM does).

Another options would have been `.set M, 0x<constant>` to evaluate the
expression as integers but I feel that using an explicit string comparison
is cleaner.

With LLVM patched to include llvm/llvm-project#67377
I was able to use riscof to compare RV64 sail assembled with LLVM vs.
RV64 sail assembled with GCC.
@arichardson
Copy link
Contributor Author

Todays date, and bump the version by the minor digit.

On Wed, Sep 27, 2023 at 7:56 AM Alexander Richardson < @.> wrote: Looks good to me Thanks for the review - what should I update the date and version of changelog entry to to allow merging this? — Reply to this email directly, view it on GitHub <#391 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJRZFTUJGLMWQKPMA6TX4Q5ADANCNFSM6AAAAAA5H6OVQA . You are receiving this because you commented.Message ID: @.>

Done, thanks

@allenjbaum allenjbaum merged commit f3c8300 into riscv-non-isa:main Sep 28, 2023
1 check passed
@arichardson arichardson deleted the assemble-with-llvm branch September 28, 2023 05:07
@allenjbaum
Copy link
Collaborator

It turns out that this breaks the GCC. You tested it - but those test also trapped to Mmode, so it didn't make a difference.
Once we introduce multiple per-mode copies of the trap handler, it still thinks it is in Mode, touches Mmode CSRs, and breaks

.endm

.macro XCSR_RENAME __MODE__ // enable CSR names to be parameterized, V,S merged
.ifc \__MODE__\, S
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see a stray \ here maybe that causes the issue?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Umer thinks that doesn't matter.
I changed the RENAME code so there are separate RENAME_M, _S, V macros, and the the RENAME[V]CSR macros just call those - but in unnested if/endif pairs.
If your code works with GCC, then these won't even compile, since none of the .ifs will match, and you'll get an undefined error when you try to compile it.
If you can test this with GCC , then make the above changes (and optionally #define RVTEST_STRAP_ROUTINE).
IF that compiles, then your fix works, else it will cause a compile failure.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also: pull from the latest first....please.

@allenjbaum
Copy link
Collaborator

It is working now

@yroux yroux mentioned this pull request Jan 4, 2024
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants