search

iree-org / iree

A retargetable MLIR-based machine learning compiler and runtime toolkit.
http://iree.dev/
Apache License 2.0
2.87k stars 627 forks source link

Make VM type descriptors local to the context in which they are used. #8698

Open powderluv opened 2 years ago

powderluv commented 2 years ago

We have some deployments where globals and BSS segments get nuked in bare-metal-ish setups. It would be good to reduce the global usage (or anything using .got). Some examples here: https://github.com/google/iree/blob/7aa6b691b5ed81f191053404c181c49516765da0/iree/modules/hal/module.c#L29-L41

Also in the static library case the "vmfb" is a global.

benvanik commented 2 years ago

There's been a TODO to do something with these for awhile but to set expectations it's unlikely to happen for awhile. I'd recommend checking your compilation flags - .got is only needed if you have position-independent code and if you have PIC you need it - there's no way around that. I'm going to guess you've got a PIC flag set when you shouldn't. Non-PIC code is fine with bss data on bare-metal - if an arduino can do it on 8-bit uc (or cc65 can do it on a 6502) anything can :)

The data segment is the best solution for size/startup cost/performance and anything we do to work around this is going to add overhead and memory consumption. Instead of a linker resolved fixup (PIC) or a constant (non-PIC) each context will need its own copy of these in dynamically allocated memory and will have to perform a few pointer hops to access them - and they are accessed a lot. The reason we'd want to move away from this is allowing multiple contexts to have different types registered as a tradeoff against size/perf/compatibility, not because of it.

benvanik commented 2 years ago

Not sure there's an issue for it, but here's a relevant TODO: https://github.com/google/iree/blob/0aba6d9bee0f31a4492e945794ca73a9e90ddc15/iree/vm/ref.c#L13-L18

benvanik commented 2 years ago

AFAIK these are the only things using file-level variables, however there are function-level statics that also end up in bss that may exist (though unlikely to be on the path used by bare-metal - most are in platform-specific files).

stellaraccident commented 1 year ago

I think this is done by the above commits.

benvanik commented 1 year ago

Not yet but close - whenever it's fixed there should be no user-level changes, though.