windelbouwman / ppci

A compiler for ARM, X86, MSP430, xtensa and more implemented in pure Python
https://ppci.readthedocs.io/en/latest/
BSD 2-Clause "Simplified" License
337 stars 36 forks source link

Hashing for IR Nodes #119

Open bifunctor opened 3 years ago

bifunctor commented 3 years ago

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!

windelbouwman commented 3 years ago

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.

obround commented 3 years ago

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.