Skip to content

Intrinsics system #800

Open
Open
@sorear

Description

@sorear

Right now adding a fundamentally new operation requires modifying all of the semantics and quite a few transformations. It's a very involved process, and it makes future maintenance more difficult. I would like to add a kind of extensible instruction so that target-specific functionality can be done without changing most transformations.

A reasonable functionality target would be something close to the constraints gcc and llvm use for inline asm:

  • Intrinsic (at the wordLang level) has a tag identifying the intended semantics, and a list of registers used by the operation, each with a role (in, out, in/out via memory; at stackLang clobber and earlyclobber can also appear)
  • The semantics of an intrinsic are globally defined (but may be architecture aware due to e.g. float nondeterminism); each target declares which intrinsics are ok and what constraints apply to them
  • Some intrinsics will be shared between targets. The current float instructions (maybe also Div/LongDiv) are demoted to intrinsics, since most transforms don't care about them.
  • Constraints associate a specific position of an instruction with a storage class Unboxed values / storage classes in backend #799 or a specific register, or require an input and an output to be allocated to the same register.
  • Most intrinsics are pure functions. There is some utility for intrinsics which behave like FFI calls and access state not modeled by the core semantics.

The information about what registers and memory an intrinsic accesses is represented generically, so no transformation should need exhaustive knowledge of intrinsics to function. A transformation can of course detect and handle intrinsics it knows about, subject to the state dependence of the definition of that intrinsic if any. Each encoder handles some subset of them and the only complete list needs to exist in the parser.

The requirements on the middle end here are exactly the same for inline asm, and it would be possible to support some form of that in the future. Inline asm would need a callback for encoding after the registers are chosen, and would need to be proof-carrying in some capacity (TBD).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions