wanted: compiler cleverness for (or (gethash ..) (setf (gethash ...) ..)
Bug #655816 reported by
Tobias C. Rittweiler
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| SBCL |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
I'm using (OR (GETHASH ...) (SETF (GETHASH ..))) all the time,
and it seems like it does a lot of work twice:
- locking
- calculating hash
- trying to find bucket
I wonder if even with threads, the compiler might be allowed to compile
the above into basically one operation with one lock. The only way to
fail is if in the above, an interrupt is processed right between the GETHASH
and the (SETF GETHASH), and sitting in the debugger, another thread
modified the hash-table.
Revision history for this message
| Nikodemus Siivola (nikodemus) wrote | #1 |
| Changed in sbcl: | |
| importance: | Undecided → Wishlist |
| status: | New → Triaged |
| tags: | added: compiler-ir1 optimization |
To post a comment you must log in.
I believe the way to implement this (and possibly similar optimizations for AREF) is to recognize the pattern:
(LET ((X (GETHASH KEY TABLE)))
(IF X
X
(SETF (GETHASH KEY TABLE) ...)))
during IR1 optimization.