ppci icon indicating copy to clipboard operation
ppci copied to clipboard

Hashing for IR Nodes

Open bifunctor opened this issue 4 years ago • 2 comments

Hello, I'm quite new to PPCI. While I was looking in ir.py, I was wondering why the nodes don't have __eq__ of __hash__ implemented in them. Is there a reason behine this? Maybe a way to get around it? Thanks!

bifunctor avatar Jan 05 '21 05:01 bifunctor

Hi @bifunctor ,

Good point! Never really thought about it, but it might be convenient to make the ir nodes hashable. One reason why they perhaps are not hashable is that they might be modified (in other words, they might not be immutable). For example the python list is mutable, and hence not hashable. A tuple on the other hand is immutable, and hence hashable. The IR nodes shoud probably be immutable, but I know that they are sometimes modified in place, for example in some optimization passes.

So in short: no specific reason, just never thought about it.

windelbouwman avatar Jan 05 '21 17:01 windelbouwman

tl;dr: Its a good idea to implement __eq__, and (maybe) an okay idea to implement __hash__.

I believe that support should be added for __eq__ and __hash__ (or at very least __eq__). As you said, hashing might be problematic in the case of mutability. A way to get around this would be to hash only some defining attributes. For example, Block's name and function won't be changed (once function is set that is). So Block could be hashed as so:

class Block:
    ...
    def __hash__(self):
        assert self.function, "function should have been set"
        return hash((self.name, self.function))

or if you wish to be able to compare blocks without having added them to functions:

class Block:
    ...
    def __hash__(self):
        return hash(self.name)

and so on.

obround avatar Jan 05 '21 18:01 obround