Interesting, I would have assumed that the compiler did some of these on its own (given the inline and the greater picture)
but I checked the dynrec core x64 and noticed that for smaller functions it is "smart", but for the more complex things (gen_function_raw and such, which is inlined itself), it really starts doing one byte at the time and increase the pointer through a move, increase, move back operation.

Yeah, my intent was/is to do the gcc option of spitting out its assembly step to see the difference or not in the code it generates, know for sure at that point. Sounds like this is how you checked?

yeah, I used

1objdump -Mintel -dS core_dynrec.o > test.asm 

But it is a bit messy to read due to the optimized code.
I could have used that gcc option to output it directly, but this is easier given that the object files are in my tree normally

Yeah, gcc asm output is cryptic but a before and after compare is enough, mostly, for me to follow along. Hopefully I'll work out this annoying permissions issue to play with this myself. Speaking of cryptic, I find some of the changes I did more readable/less spaghetti, shorter than the original, but maybe that's just me:)

It's easier to read with the -Mintel, but the interlinked source (the S) is sometimes a bit off.

Another tweak, can pull "if (!dsr2 && (ddr==dsr1) && !imm_size) return;" into the "if (!imm && (gsr1->index!=0x5))" path, no need to do the check for imm_size 1 & 4.

1static void gen_lea(DynReg * ddr,DynReg * dsr1,DynReg * dsr2,Bitu scale,Bits imm) {
2	GenReg * gdr=FindDynReg(ddr);
3	Bitu imm_size;
4	Bit8u rm_base=(gdr->index << 3);
5	Bit8u index;
6	if (dsr1) {
7		GenReg * gsr1=FindDynReg(dsr1);
8		if (!imm && (gsr1->index!=0x5)) {
9         if (!dsr2 && (ddr==dsr1)) return;		
10			imm_size=0;	rm_base+=0x0;			//no imm				
11		} else if ((imm>=-128 && imm<=127)) {
12			imm_size=1;rm_base+=0x40;			//Signed byte imm
13		} else {
14			imm_size=4;rm_base+=0x80;			//Signed dword imm
15		}	
16		index=gsr1->index;    
17	} else {
18	  imm_size=4;
19	  index=5; 
20	}   
21	if (dsr2) {
22		GenReg * gsr2=FindDynReg(dsr2);			
23		cache_addw(0x8d|(rm_base+0x4)<<8);	//0x8d=LEA | The sib indicator
24		Bit8u sib=(index+(gsr2->index<<3)+(scale<<6));  
25		cache_addb(sib);			
26	} else {			
27		cache_addw(0x8d|(rm_base+index)<<8);	//LEA | dword imm			
28	}	
29	switch (imm_size) {
30	case 0:	break;
31	case 1:cache_addb(imm);break;
32	case 4:cache_addd(imm);break;
33	}
34	ddr->flags|=DYNFLG_CHANGED;
35}

cinched up decoder.h

I can compile now, took a reinstall, w7 was borked. Tweaks work, /w a touch up here and there, negligible performance change, though the binary is a K smaller and saved ~100k on mem usage(varies, just tracking /w task manager,) which I've been trading for inlining xyz. Need to get asm output going(objdump isn't working for me currently) and profiling to see what's going on.

I'll be interested what you come up with.
I did something similar as you did for the dynrec core and it got a lot smaller indeed, but noticed no performance changes (which isn't too surprising as the asm that dosbox executes is unchanged)

Refresh my memory on invoking diff to output the correct format and I can upload what I have now, warts and all. I used the svn tar.gz from here: https://www.dosbox.com/wiki/Building_DOSBox_with_MinGW

extract the source a second time (folder name dosbox-org)
and then run in the folder that contains both yoursource and the original source

1diff -u dosbox-org/src/cpu/core_dynamic/decoder.h yoursource/src/cpu/core_dynamic/decoder.h > mypatch.txt

Changes have been more than to just decoder.h, but confined to core_dyn_x86 dir.

did another tightening to the guys in decoder with these:

cache_addd(0x52|(0x50+genreg->index)<<8|0xe850<<16);
to
cache_addd(0xe8505052+(genreg->index<<8));

getting rid of two ors and a shift. chris's 3d bench liked it, it seems, 1001 vs 957. error of margin? like I said, I need to get asm output and profiling going.

Reduced the binary by 8k now, mostly from changing ifs & switches /w repetitive function/method calls with local vars and calling once. Applied the optimized bound checking from the mixer to the mouse handler. The optimization in gen_call_function I had commented out working now.

From the asm gcc is generating, they are faster, not just a size reduction of the binary. so yeah, fewer cache_addx is betta.

1static void gen_return(BlockReturn retcode) {
2	gen_protectflags();
3	if (retcode==0) { 
4		cache_addd(0xc3c03359);			//POP ECX, the flags
5//	  cache_addw(0xc033);		//MOV EAX, 0
6//	 	cache_addb(0xc3);			//RET
7	} else {
8		cache_addw(0xb859);			//POP ECX, the flags
9//		cache_addb(0xb8);		//MOV EAX, retcode
10		cache_addd(retcode);
11		cache_addb(0xc3);			//RET
12	}
13}
14
15new:
16__ZL10gen_return11BlockReturn.part.5: 
17  movl	__ZL5cache+16, %eax
18	movl	$-1010814119, (%eax)	
19	addl	$4, %eax
20	movl	%eax, __ZL5cache+16
21	ret
22__ZL10gen_return11BlockReturn:	
23	subl	$4, %esp
24	cmpb	$0, __ZL6x86gen
25	jne	L247
26L244:  // -1xmov,2xlea 
27	testl	%eax, %eax
28	je	L248
29	movl	__ZL5cache+16, %edx
30	movl	$-18343, %ecx
31	movl	%eax, 2(%edx)
32	leal	7(%edx), %eax
33	movw	%cx, (%edx)
34	movl	%eax, __ZL5cache+16
35	movb	$-61, 6(%edx)
36	addl	$4, %esp
37	ret
38L248:	// +1xadd,1xjmp, -2xmov,1xlea,1xadd
39	addl	$4, %esp
40	jmp	__ZL10gen_return11BlockReturn.part.5
41L247:	
42  movl	%eax, (%esp)
43	call	__ZL16gen_protectflagsv.part.2
44	movl	(%esp), %eax
45	jmp	L244
46
47old:
48__ZL10gen_return11BlockReturn:
49	.cfi_startproc
50	subl	$4, %esp
51	cmpb	$0, __ZL6x86gen
52	jne	L266
53L262:	
54	movl	__ZL5cache+16, %edx
55	testl	%eax, %eax
56	leal	1(%edx), %ecx
57	movl	%ecx, __ZL5cache+16
58	movb	$89, (%edx)
59	je	L267
60	movl	__ZL5cache+16, %edx

61	leal	1(%edx), %ecx
62	movl	%ecx, __ZL5cache+16
63	movb	$-72, (%edx)
64	movl	__ZL5cache+16, %edx
65	movl	%eax, (%edx)
66	leal	4(%edx), %eax
67	leal	1(%eax), %edx
68	movl	%edx, __ZL5cache+16
69	movb	$-61, (%eax)
70	addl	$4, %esp
71	ret
72L267:	
73	movl	__ZL5cache+16, %eax
74	movl	$-16333, %edx
75	movw	%dx, (%eax)
76	addl	$2, %eax
77	leal	1(%eax), %edx
78	movl	%edx, __ZL5cache+16
79	movb	$-61, (%eax)
80	addl	$4, %esp
81	ret
82L266:	
83	movl	%eax, (%esp)
84	call	__ZL16gen_protectflagsv.part.2
85	movl	(%esp), %eax
86	jmp	L262

10k now.

Added a cache_add3, which adds three bytes to the cache doing a dword move and inc the pointer by 3, replacing the addb + addw for those cases.

I did that in my own tree as well. Guess we had similar thoughts 😀

Oh yeah? Well I've got cache_addq & cache_add7 working preliminarily and currently implementing the optimizations 😀

edit: Well, they work, but it seems like doom bench is getting slower as I add 64 bit moves.