Skip to content

Re-organize intrinsic-test to enable seamless addition of behaviour testing for more architectures #1758

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

Open
wants to merge 19 commits into
base: master
Choose a base branch
from

Conversation

madhav-madhusoodanan
Copy link

@madhav-madhusoodanan madhav-madhusoodanan commented Mar 24, 2025

Updates so far

  1. Moved the ARM-specific testing to the arm module, exposing only a test function at src/main.rs
  2. Created a SupportedArchitectureTest trait that has been implemented for arm and should be implemented for other architectures too. Allows us to expose functionality like building C/Rust test files and comparing outputs.
  3. Moved common functionality (CLI parsing, create files, compilations, compare outputs) into the common module for reuse by other architectures too.
  4. Implemented a match block for selection of architectures using the target CLI variable.

Reasoning

  1. The Intrinsic type may be specific to architectures, hence the implementation of a trait helps us to abstract the usage of such data types within the architecture-specific module

New architecture of intrinsic-test

IMG_9057

@rustbot
Copy link
Collaborator

rustbot commented Mar 24, 2025

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch 2 times, most recently from 9900e81 to 546554d Compare March 24, 2025 19:10
@Amanieu
Copy link
Member

Amanieu commented Mar 25, 2025

The module should be called arm rather than aarch.

@Amanieu
Copy link
Member

Amanieu commented Mar 25, 2025

@JamieCunliffe feel free to have a look at this since you are the original author of intrinsic-test. This is part of a GSoC project to extend intrinsic-test to other architectures.

@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch from 546554d to 3ff317f Compare March 25, 2025 09:25
Reasoning:
1. Majority of code assumes the usage of `Intrinsic` and related types, which is derived from the JSON structure of the ARM intrinsics JSON source file
2. Further commits will start with extracting common parts of the code (eg: Create C/Rust file, Build C/Rust file, etc)
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch from 3ff317f to bd0a675 Compare March 25, 2025 09:32
…ted for different architectures.

Next steps:
Move the existing ARM-specific implementation into one that fits well with this trait.
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch 4 times, most recently from 5dce230 to 7ff8497 Compare March 26, 2025 15:32
@madhav-madhusoodanan
Copy link
Author

madhav-madhusoodanan commented Mar 26, 2025

Are we using the --a32 flag in the CLI of intrinsic-test anywhere? I was unable to find its usage.
Would it be alright if I remove it, or is there some reasoning that I may be missing?

@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch 2 times, most recently from a12b4a4 to ff10311 Compare March 27, 2025 15:49
@Amanieu
Copy link
Member

Amanieu commented Mar 27, 2025

--a32 is not currently tested in CI, but it is used for 32-bit ARM targets (arm* and thumb*). Some ARM intrinsics are only available on 64-bit ARM targets and this flag skips those.

@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch 4 times, most recently from 3068c9d to 2d1e482 Compare March 27, 2025 17:52
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch 3 times, most recently from e0b0301 to 54a678c Compare March 27, 2025 18:34
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch from 54a678c to 2777ceb Compare March 27, 2025 18:36
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch 2 times, most recently from 7c686ef to e2444df Compare April 14, 2025 00:38
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch from e2444df to 90249a3 Compare April 14, 2025 00:40
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch from 0d5bd59 to 1791b35 Compare April 14, 2025 08:05
@adamgemmell
Copy link
Contributor

Are we using the --a32 flag in the CLI of intrinsic-test anywhere? I was unable to find its usage. Would it be alright if I remove it, or is there some reasoning that I may be missing?

I believe it's inferred now since here where that PR added a third target. I think it can be removed.

@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch 2 times, most recently from 84d660c to 727da8e Compare April 16, 2025 09:00
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch 3 times, most recently from 448e336 to f3f4f7c Compare April 16, 2025 10:30
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch from f3f4f7c to 358016a Compare April 16, 2025 10:32
Copy link
Contributor

@adamgemmell adamgemmell 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! I think types.rs would map fine to x86 with a little modification.

I'd just like to add that Scalable Vectors will be added to this tool at some point - the Arm code is here and it would probably be useful for RISC-V in the future too.

Don't worry about conflicts with that PR (it's very old and needs a rework) and I don't think there's anything particularly different about how intrinsic-test needs to work but scalable vectors do add an extra dimension of complexity to the tool.

.arg(format!("{runner} ./c_programs/{intrinsic_name}"))
.output();

let rust = if SPECIAL_TARGETS
Copy link
Contributor

Choose a reason for hiding this comment

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

Choose a reason for hiding this comment

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

Got it, let me do that.

name = "Intrinsic test tool",
about = "Generates Rust and C programs for intrinsics and compares the output"
)]
pub struct Cli {
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems an odd file name for the CLI

Choose a reason for hiding this comment

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

I'll need to rename the files, I started off by focussing on the code refactor side of things.
Thank you for sharing this observation with me.

@madhav-madhusoodanan
Copy link
Author

madhav-madhusoodanan commented Apr 16, 2025

Over the last 4 commits I changed from the Argument type to an Argument<T, M> generic type.

This allowed me to refactor a lot more code into the common module, since Argument has a lot of code that could be reused across architectures.

Where it differed was in the usage of the IntrinsicType enum (now the IntrinsicType struct after removing the recursion-based Ptr and Type variants) and the ArgPrep struct.

At the moment, each architecture can define:

  1. Their own Metadata type (which Constraint used to be for arm target intrinsics), represented by the generic type M.
  2. Their own version of <arch>IntrinsicType struct (ArmIntrinsicType, etc), which wraps over the core IntrinsicType struct and can handle architecture-specific needs (represented by the generic type T).
    • The common parts of the definition is now handled by a macro called base_intrinsictype_trait_def_macro.
    • Reason I didn't make this into an enum is I think it might be easier to extend architecture-specific versions of IntrinsicType by adding a new module without having to update the common module, please let me know if this is a good idea.

I've made some changes in the C testfile-generation part, will pinpoint them in the next message.

After this part, I intend to work on:

  1. Wrapping the functionality that handles the compilation commands into a struct
  2. Moving the architecture-specific <arch>ArchitectureTest structs into an enum

@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch 4 times, most recently from a9a1885 to ac478c8 Compare April 18, 2025 16:58
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch from ac478c8 to 16e7523 Compare April 18, 2025 17:05
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch from d75e8ca to da49266 Compare April 19, 2025 17:49
@madhav-madhusoodanan madhav-madhusoodanan force-pushed the restructure-intrinsic-test-crate branch from 16c89b0 to 9eb138d Compare April 19, 2025 18:11
@madhav-madhusoodanan
Copy link
Author

Updating what I did over the last 4 commits:

  1. Converted the way the C compilation commands were being constructed from raw format! calls into a structured manner.
  2. Updated the execution command for Rust test files, removing the aarch64_be-specific commands (as suggested by @adamgemmell in this comment).
  3. Implemented dynamic dispatch for the construction of <arch>ArchitectureTest structs.
    • This was done since the structs are intended to hold similar functionality (viz. building C/Rust files and comparing outputs)
    • The arch-specific modules accommodates any arch-specific differences
    • Dynamic dispatch seems like a great way to call these functions without needing to implement match blocks.
  4. Cleaned up any unnecessary function arguments

What I'll do next:

  1. It seems like arm/function.rs has some code that could be made common to other arch too. Will look into it.
  2. Files need to be renamed for clarity.

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.

4 participants