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

dialects: (csl) adding constructors for CSL ops #2742

Merged
merged 3 commits into from
Jun 17, 2024
Merged

Conversation

n-io
Copy link
Collaborator

@n-io n-io commented Jun 17, 2024

Adding constructors for many CSL ops.

This was originally part of #2720

@n-io n-io added dialects Changes on the dialects minor For minor PRs, easy and quick to review, quickly mergeable labels Jun 17, 2024
@n-io n-io self-assigned this Jun 17, 2024
@n-io n-io requested review from dk949 and AntonLydike June 17, 2024 15:10
Copy link

codecov bot commented Jun 17, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.91%. Comparing base (2fb4c3f) to head (8cfdc20).
Report is 3 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2742      +/-   ##
==========================================
- Coverage   89.93%   89.91%   -0.03%     
==========================================
  Files         367      367              
  Lines       47282    47302      +20     
  Branches     7219     7229      +10     
==========================================
+ Hits        42525    42531       +6     
- Misses       3645     3659      +14     
  Partials     1112     1112              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

xdsl/dialects/csl.py Outdated Show resolved Hide resolved
fname: str,
result_type: Attribute,
struct: Operation,
*params: SSAValue | Operation,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I'd like this to not be a vararg, and instead be a Sequence[SSAValue | Operation].

Having a vararg after a bunch of other arguments would make the code less readable at the call site imo.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

As long as it's limited to function name+type, it should hopefully be fine enough to avoid me doing cross-PR changes (:

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm strongly in favour of switching to Sequence here, as it's otherwise out of line with the other call operations...

xdsl/dialects/csl.py Outdated Show resolved Hide resolved
@@ -1486,6 +1533,13 @@ class ParamOp(IRDLOperation):

res = result_def(T)

def __init__(self, name: str, result_type: T):
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure if this is allowed in python... @PapyChacal do you have any input on this? I think you know more on this than I do...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I thought that's what make TypeVars so neat
https://mypy.readthedocs.io/en/stable/generics.html

Copy link
Collaborator

Choose a reason for hiding this comment

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

But T is not a TypeVar, it's an IRDL constraint! These two are sadly quite different...

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think it's necessarily wrong, but it's not expressing what you may think it is.

Copy link
Collaborator Author

@n-io n-io Jun 17, 2024

Choose a reason for hiding this comment

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

You're right, I misread, it's not a TypeVar. I think it's not an IRDL constraint either, though, it should just be a union type with some additional meta data.

Comment on lines 1568 to 1578
def __init__(self, op: SSAValue | Operation):
typ = op.results[0].type if isinstance(op, Operation) else op.type
assert isinstance(typ, IntegerType)
res_signedness = (
Signedness.SIGNLESS
if typ.signedness.data == Signedness.UNSIGNED
else Signedness.UNSIGNED
)
super().__init__(
operands=[op], result_types=[IntegerType(typ.width, res_signedness)]
)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I'd prefer a much simpler interface that is in-line with other cast operations:

Suggested change
def __init__(self, op: SSAValue | Operation):
typ = op.results[0].type if isinstance(op, Operation) else op.type
assert isinstance(typ, IntegerType)
res_signedness = (
Signedness.SIGNLESS
if typ.signedness.data == Signedness.UNSIGNED
else Signedness.UNSIGNED
)
super().__init__(
operands=[op], result_types=[IntegerType(typ.width, res_signedness)]
)
def __init__(self, op: SSAValue | Operation, result_type: IntegerType):
super().__init__(
operands=[op], result_types=[result_type]
)

This way the caller can decide what he wants instead of the init smartly guessing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If you prefer a simple interface, I suggest it's simplest to do what the op promises to do, and just flip the signedness.

Copy link
Collaborator

Choose a reason for hiding this comment

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

But you may want to cast from i32 to si32, which this constructor does not allow.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I understood we didn't want to have si32, but I added an optional arg to explicitly state the result type, and if it's None we derive it.

@AntonLydike
Copy link
Collaborator

A very nice set of changes, I just have a bunch of nitpicks strewn about :D

@n-io n-io merged commit 454f1b3 into main Jun 17, 2024
10 checks passed
@n-io n-io deleted the csl-op-constructors branch June 17, 2024 16:50
AntonLydike added a commit that referenced this pull request Jun 18, 2024
Fix some of the things that accidentally went through in #2742.

Also moves the `__init__` to the top of the method definition and adds
some docstrings.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dialects Changes on the dialects minor For minor PRs, easy and quick to review, quickly mergeable
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants