On 8/22/24 1:50 PM, Patrick O'Neill wrote:
Applies after the recent 9 patch series:
"RISC-V: Improve const vector costing and expansion"
https://inbox.sourceware.org/gcc-patches/20240822194705.2789364-1-patr...@rivosinc.com/T/#t
This isn't functional due to RTX hash collisions. It was incredibly useful and
helped me catch a few tricky bugs like:
"RISC-V: Handle 0.0 floating point pattern costing"
Current flow is susceptible to hash collisions.
Ideal flow would be:
Costing: Insert into hashmap<rtx, vec<(const_rtx, enum)>>
Expand: Check for membership in hashmap
-> Not in hashmap: ignore, this wasn't costed
-> In hashmap: Iterate over vec
-> if RTX not in hashmap: Ignore, this wasn't costed (hash collision)
-> if RTX in hashmap: Assert enum is expected
Example of hash collision:
hash -663464470:
(const_vector:RVVM4DI repeat [
(const_int 8589934593 [0x200000001])
])
hash -663464470:
(const_vector:RVVM4SF repeat [
(const_double:SF 1.0e+0 [0x0.8p+1])
(const_double:SF 2.0e+0 [0x0.8p+2])
])
Segher pointed out that collisions are inevitible (~80k 32 bit hashes
have a >50% chance of containing a collision)
If this is worth adding then these are the next questions:
* How heavy-weight is it to store a copy of every costed
const RTX vector (and ideally other costed expressions later).
* Does this belong in release or gated behind rtx checking?
Given that it's currently non-functional and potentially quite
expensive, RTL checking seems more appropriate than release checking.
But I think even to get there you'd need to address some of the hash
collision issues.
I'm not sure if/how to go forward with this.
jeff
