You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Move intrinsics from settings.intrinsics to settings.extensions.{ext_name}.intrinsics (easier lookup)
Add signedness information to arguments and return type
Allow specifying allowed value ranges (i.e. [0, 31] or [-16, 15] for 5-bit operand exposed via uint8_t argument)
Use c_type instead of ir_type as the default format to define argument types (includes sign information)
Allow specifying defaults for intrinsics/builtins (on per-extension level)
Allow just generating an LLVM intrinsic without generating the respective Clang builtin, i.e. via builtin: null
Define/override the builtin/intrinsic prefix per-instruction or per-extension, i.e. via builtin.prefix: "__builtin_riscv_{arch}" or intrinsic.prefix: "llvm.int.riscv.{arch}"
Support intrinsic properties (IntrNoMem, IntrWillReturn, ...) and builtin attributes (NoThrow, Const, ...). Either explicitly or automatically inferred by Seal5 passes.
This is mostly not implemented in Seal5 yet, so I am happy about any comment.
In the following, I will provide examples to compare the new and old configuration.
Note that despite the compact syntax using YAML anchors, this is actually a bit longer than the original. However, this can partly be explained by the fact, that this Syntax includes more information (i.e. signedness/range of arguments)
I also came up with a "shorthand" syntax that lets you specify just the prototype for the builtins. The actual configuration would then need to be inferred by Seal5. This will work in some cases, but it should be possible to provide the full information as shown above, too.
This the compact syntax it should also be easy to embed the builtin settings (optionally of course) in the CDSL syntax via attributes. Here is an example:
Looks ambitiously comprehensive, or comprehensively ambitious :-) Scattershot shallow comments...
Is the motivation for using c_type over ir_type principally to include the signed-ness info? Seems good anyway since the types are more obvious, maybe more dominant in future LLVM evolution
Number ranges might also be useful for subsetting - eg like restricting the register numbers in RV32E to [0, 15] (though that's a poor example though since those are also the RV32I instruction encodings so could only work if the toolchain is being built to only support RV32E)
Custom immediate handling in general is (was? did it get better in LLVM19?) regrettably ugly with the need to generate C++ rather than expressing purely through TableGen
With some different layers of config possible, e.g. the CoreDSL annotations from Support automatically generated intrinsics/builtins #69, prefix overrides here, clear diagnostics will be a blessing for understanding the results
As you note the wordiness of the configuration is an existing problem with too much information being duplicated from the CoreDSL types. And some of those anchor patterns like "binary_args_unsigned" might be common/generic enough to be worth promoting to some "standard_intrinsic_patterns.yml" (though
Proposed changes:
settings.intrinsics
tosettings.extensions.{ext_name}.intrinsics
(easier lookup)uint8_t
argument)c_type
instead ofir_type
as the default format to define argument types (includes sign information)builtin: null
builtin.prefix: "__builtin_riscv_{arch}"
orintrinsic.prefix: "llvm.int.riscv.{arch}"
IntrNoMem
,IntrWillReturn
, ...) and builtin attributes (NoThrow
,Const
, ...). Either explicitly or automatically inferred by Seal5 passes.This is mostly not implemented in Seal5 yet, so I am happy about any comment.
In the following, I will provide examples to compare the new and old configuration.
Example 1 (before):
Example 2 (after, long):
Note that despite the compact syntax using YAML anchors, this is actually a bit longer than the original. However, this can partly be explained by the fact, that this Syntax includes more information (i.e. signedness/range of arguments)
I also came up with a "shorthand" syntax that lets you specify just the prototype for the builtins. The actual configuration would then need to be inferred by Seal5. This will work in some cases, but it should be possible to provide the full information as shown above, too.
Example 3 (after, short):
This the compact syntax it should also be easy to embed the builtin settings (optionally of course) in the CDSL syntax via attributes. Here is an example:
The text was updated successfully, but these errors were encountered: