when applying wasm-opt with fpcast to postgres, a few functions are noticed to have way more parameters which exceeded the fpcast default limit of 18:
warning: FuncCastEmulation: skipping thunk for 'TypeCreate' (33 params exceeds max-func-params=18)
warning: FuncCastEmulation: skipping thunk for 'CreateConstraintEntry' (33 params exceeds max-func-params=18)
warning: FuncCastEmulation: skipping thunk for 'index_create' (21 params exceeds max-func-params=18)
warning: FuncCastEmulation: skipping thunk for 'AggregateCreate' (33 params exceeds max-func-params=18)
warning: FuncCastEmulation: skipping thunk for 'ProcedureCreate' (29 params exceeds max-func-params=18)
Increasing the fpcast parameter limit to number like 34 means the limit must be increased across all the application stack (glibc, bash, etc), which would likely double the overhead of fpcast.
Currently these skipped symbols are not causing problems for postgres regression test. Those five symbols are currently skipped by wasm-opt fpcast, and therefore its GOT entry is going to be unresolved, but existing libraries like plpgsql.so are not using these symbols, so this is fine for now. But probably a problem we need to fix in the future
when applying wasm-opt with fpcast to postgres, a few functions are noticed to have way more parameters which exceeded the fpcast default limit of 18:
Increasing the fpcast parameter limit to number like 34 means the limit must be increased across all the application stack (glibc, bash, etc), which would likely double the overhead of fpcast.
Currently these skipped symbols are not causing problems for postgres regression test. Those five symbols are currently skipped by wasm-opt fpcast, and therefore its GOT entry is going to be unresolved, but existing libraries like
plpgsql.soare not using these symbols, so this is fine for now. But probably a problem we need to fix in the future