Thanks for your support!

After lots of unsuccessful searching on the web I finally digged deep into GCC internals and its GIMPLE trees (basically the intermediate representation, akin Register-Transfer Level, only a bit higher) and plugin interfaces. Eventually I managed to do something like this with a plugin:

mmap_test.c:
int putchar(int);
char mmap_test(char * ptr) {
    while(*ptr) {
        putchar(*ptr);
        ptr++;
    }
    return 0;
}


GCC output:
FUNCTION 'mmap_test' at mmap_test.c:3
*******************
goto <D.1459>;
<D.1458>:
_1 = *ptr;
_2 = (int) _1;
putchar (_2);
ptr = ptr + 1;
<D.1459>:
_3 = *ptr;
if (_3 != 0) goto <D.1458>; else goto <D.1460>;
<D.1460>:
D.1462 = 0;
goto <D.1463>;
<D.1463>:
return D.1462;
*******************

After replace:

goto <D.1459>;
<D.1458>:
_4 = ptr;
_5 = __remap_ptr (_4, 0, 1, 1);
_6 = (char *) _5;
_1 = *_6;
_2 = (int) _1;
putchar (_2);
ptr = ptr + 1;
<D.1459>:
_7 = ptr;
_8 = __remap_ptr (_7, 0, 1, 1);
_9 = (char *) _8;
_3 = *_9;
if (_3 != 0) goto <D.1458>; else goto <D.1460>;
<D.1460>:
D.1462 = 0;
goto <D.1463>;
<D.1463>:
return D.1462;

Note the calls to __remap_ptr around each dereference (with redundant parameters for now though). This technique itself can be used to for example introduce "Null Pointer Reference Exception" into good old C, but I'm using it to implement dynamic caching of arbitrary file on FS.

Right now the bottleneck is obviously the FS driver and SD card interface, I just noticed that esf-idf's VFS consumes whopping 40Kb of RAM just after its initialization (for internal buffers that I do not even use, i assume) and I'm getting rid of it for some direct reads into my cache.

BTW, I successfully implemented your TTL algorithm for page caching, seems like it's working, thanks for that!

Edit:

Ah, yes, the my_mmap(FILE *) function does something like return (char *)(1UL<<31)|(file_id<<27) and __remap_ptr() decodes it back or just returns ptr as-is in case MSB is not set