Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • S sdv-lammps
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 100
    • Issues 100
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • djurado
  • sdv-lammps
  • Wiki
  • 32 bit and 64 bit data types

32 bit and 64 bit data types · Changes

Page history
Update 32 bit and 64 bit data types authored Jan 24, 2023 by djurado's avatar djurado
Hide whitespace changes
Inline Side-by-side
32-bit-and-64-bit-data-types.md
View page @ 43c5b5b5
......@@ -17,10 +17,10 @@ This is the source of a conflict, since the intrinsics are not aware of this par
For this reason, using `vwadd` with intrinsics in the 0.7 VPU is not possible since just using a `__epi_2xi64` data type triggers an error because of the lack of LMUL support.
To overcome this, the proposed solution was to try to use `vwadd` with inline assembler to avoid the previous conflict, since inline assembler is not aware of register data types, but that was deemed as too inconsistent.
For the particular implementation of `vwadd` in the VPU, output is written to two consecutive registers, altough only the first one is specified as an operand.
For the particular implementation of `vwadd` in the VPU, output is written to two consecutive registers, although only the first one is specified as an operand.
This can lead to compilation errors, since the inline assembler is not aware of this and may automatically choose a combination of input and output registers that overlap, and generate and error when assembling the instructions.
Sometimes the compiler produces this error, but changing the optimization setting (from -O0 to -O2) can fix the issue since a different combination of registers may be used which happen to not overlap.
For this reason, this approach has been discarded.
Compiling with `-O0` produces this error, but using another optimization level fixes the issue since a different combination of registers which happen to not overlap may be used .
Due to its unreliability, this approach has been discarded.
In the end, a bithack trick was used to extend the array of 32-bit unsigned integers into a vector register with SEW width of 64-bits.
The trick is to load the 32-bit array into a register with 64-bit SEW, and then use an `vand` operation to blank the most significant half of the elements, mimicking an extension with zeros.
......
Clone repository

Home

  1. Introduction
  2. Overview
  3. Implementation
    • Specialization
    • Loop-size
    • Managing-code-paths
    • 32-bit and 64-bit data types
    • union_int_float_t
  4. Annex
    • 32-bit to 64-bit
    • Autovectorization

Sidebar