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

[Primitives] Fix slice primitives #1139

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

[Primitives] Fix slice primitives #1139

wants to merge 5 commits into from

Conversation

leonardt
Copy link
Collaborator

  • Promote int-like values in get_slice/set_slice
  • Update doc to refer to set_index instead of set_bit
  • Support set_slice of length 1 for constant values

* Promote int-like values in get_slice/set_slice
* Update doc to refer to set_index instead of set_bit
* Support set_slice of length 1 for constant values
magma/primitives/slice.py Outdated Show resolved Hide resolved
@codecov-commenter
Copy link

codecov-commenter commented Sep 14, 2022

Codecov Report

Merging #1139 (52e0e12) into master (42b8850) will increase coverage by 0.01%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##           master    #1139      +/-   ##
==========================================
+ Coverage   85.00%   85.01%   +0.01%     
==========================================
  Files         154      154              
  Lines       16368    16379      +11     
==========================================
+ Hits        13914    13925      +11     
  Misses       2454     2454              
Impacted Files Coverage Δ
magma/primitives/slice.py 88.09% <71.42%> (-5.46%) ⬇️
magma/backend/mlir/hardware_module.py 97.07% <0.00%> (+0.23%) ⬆️
magma/conversions.py 86.24% <0.00%> (+0.37%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@rsetaluri rsetaluri changed the title Fix slice primitives [Primitives] Fix slice primitives Sep 15, 2022
@@ -249,23 +249,26 @@ Slice function interfaces:
* width: constant slice width


### set_bit
### set_index
Copy link
Collaborator

Choose a reason for hiding this comment

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

I would be in favor of renaming the function (publicly, i.e. in the docs) to set_bit. We could deprecate set_index for now with warning (doubt anyone is using it anyway...)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It was changed to set_index because the pattern is more general than just set_bit (i.e. you can use it on generic arrays, rather than just on Bits), so I think it makes more sense to keep it as set_index for generality

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see. In that case, why do we need a separate function? I.e. why is it not covered by set slice with width 1?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Simpler to use when you know you're only interested in one index. For the same reasons in Python we have x[1] versus having to do x[1:2].

Copy link
Collaborator

Choose a reason for hiding this comment

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

Makes sense -- but I would argue x[1] and x[1:2] is the same interface with different arguments (in fact it literally is the function __getitem__).

Maybe we don't need to do this in this change, but seems reasonable to refactor to have the following interface:

"""
* target: Array[N, T]
* value: Union[Array[M, T], T]
* start: UInt[W]

where M < N and W <= clog2(N)
"""
def set(target: Array, value: Union[Type, Array], start: UInt):
    ...

Now that I think about it there are few new concerns here:

  • Should this function work with all Arrays and not just Bits? I kind of assumed it did, but looking at the code closer I'm not certain.
  • Do we need a width argument? Can it just be inferred from value? If value is an array of the same dimensionality as target then it is a slice set; else if it is of dimensionality one less than value then it is an index set (of course assuming the contained types match up and all).
  • In the case start being a constant value, should we optimize for the simple wiring (non-dynamic mux) case?

@rsetaluri
Copy link
Collaborator

Moving this conversation here:

I'm not sure if set_slice of length makes sense unless the start value is a constant 0. Otherwise, the smallest start value we could have is a Bit which could take on value 1 or 0. A start index of 1 would be invalid for setting a slice on length 1.

I think my note was unclear. I meant the case when width is 1, i.e. value is of length 1 -- not target being length 1. This seems like it should be uniform with any other width value. Right now it seems to be broken.

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.

3 participants