santiontanon: sorry for not trying myself (too lazy to set up mdlz80 locally), but yesterday I was trying to improve sjasmplus with some interesting snippet of source, and I was wondering what your optimiser would see in such case.
The somewhat tricky source:
DEVICE ZXSPECTRUM48
org 0x4000
disp 0x10000-this1+zac1 ; should become 0xFFFF to produce code "at end of RAM"
zac1:
nop
this1:
ENT
org 0x4000+this1-zac1 ; this should be 0x4001, after the displaced block
nop
The tricky part for sjasmplus 1.18.2 is, that during first pass the symbols are undefined and first DISP does then calculate address as 0x10000, that's first value for `zac1` symbol, then the `nop` wraps around in 16bit device-memory space and lands to 0x0000 and `this1` becomes 0x0001.
So in second pass the DISP goes 0x10000-1+0x10000 -> 0x1FFFF and the symbols get reassigned again to unexpected values 0x1FFFF and 0x0001 or 0x10001 (not even sure, but still way apart), and so on.
In third pass the v1.18.2 will exit with fatal error in device-memory mapping, because of those symbols spanning across ~64ki, making the ORG to try to set negative address -48ki - which hasn't been checked on the ORG implementation level before fix.
Took me some time to realise how to fix this and make it work internally as expected by original author of that snippet... 
The solution is to crop ORG/DISP arguments to uint16_t (with warning, if such cropping happens in third pass), so in the second pass the DISP does set address 0xFFFF instead of 0x1FFFF, then the redefined second-pass values set the symbols to expected 0xFFFF and 0x10000, and the rest of the source then makes sense and there's no issue with further ORG.
The funny part is, that some of this is induced due to "DEVICE" doing that 16bit address space constraint and causing wrap-around. Contrary to that the code snippet works well in non-device mode with `--longptr` option, as then symbols are 1 byte apart already after first pass, and the second+ pass will produce expected values. I guess your optimiser may fall rather into this category, working without any issue and producing expected result. (if you even do bother to calculate symbol values, I'm not sure .... I'm not sure why I'm even posting this, I just found that problem interesting, and I hope it will somewhat amuse you 
)
One other (very minor) thing, one of the sources I tried MDL on contained the following part:
ld a,r ld h,a ld a,r ld l,a
Probably not the best code 
, but this is detected by MDL as 'Remove duplicate ld a,r (2 bytes, 11 t-states saved)', while actually r will have a different value the second time.
oh, good catch! This is easy to fix, I'll add a note to fix for the next version. Thanks ToriHino!
Yes! I only used a couple of SDCC examples to work on optimization patterns specific to SDCC code though, so it might not be as great as it could be. But SDCC/sdasz80 syntax is indeed supported
If you want to try it, just make sure to use the "-dialect" command line flag to select "sdcc" (or "sdasz80")
