freenode/#sbcl - IRC Chatlog
Search
9:52:31
White_Flame
another silly optimization question: Looking at the disassembly, when setf'ing 3 fixnums into 3 :type fixnum slots of a struct, two of them directly set while the 3rd calls through #<FDEFN (SETF #)>
9:52:48
White_Flame
is there something that that tends to indicate, that can be further optimized via my source?
9:57:04
White_Flame
I'm going through my codegen, and eliminating/inlining asm-level calls that seem worth it
10:04:12
flip214
White_Flame: perhaps that accessor was defined manually and is therefore not inlined?
10:04:35
White_Flame
all 3 are defined the same. I"m desparately looking for any discrepancy between them
10:05:00
White_Flame
I haven't pulled out a minimum case yet, since there's a lot of macro generated stuff
10:12:18
flip214
White_Flame: perhaps some name collision and this became a GF instead? Unlikely because of struct, but I don't have much data to guess from
10:16:37
White_Flame
this is the gist of how this is structured, building source & compiling stuff at runtime: https://pastebin.com/8vkHrsSJ
10:17:03
White_Flame
this test code does disassemble properly, yet my real stuff doesn't. The slot names are the same as the real code
10:26:22
White_Flame
(#<SB-KERNEL:DEFSTRUCT-DESCRIPTION CPU {1002D9E283}> . #<SB-KERNEL:DEFSTRUCT-SLOT-DESCRIPTION LP>)
10:26:38
White_Flame
(#<SB-KERNEL:DEFSTRUCT-DESCRIPTION CPU {1002D9E283}> . #<SB-KERNEL:DEFSTRUCT-SLOT-DESCRIPTION FP>)
10:33:27
White_Flame
for what it's worth, this is where I believe the various lisp clauses match the asm code: https://pastebin.com/C0Yqdxvs
10:35:06
White_Flame
you know what, I'm probably an idiot. I bet that final SETF # call is for the next (SETF (CPU-CONTROL CPU) NEW-CONTROL) clause
10:39:27
White_Flame
if it could be increased by just 1, then the actual setter name would be visible, but I don't know how much sprawl that would create for other forms in the disassembly
10:41:49
White_Flame
I verified that yes, the FDEFN is in fact from the next form, so this has just been a rubber duck debugging session for me :-/
10:45:49
White_Flame
(btw, that insane array of LABELS functions I was fiddling with the other day is actually working out pretty great so far)