-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
FnAbi computation should be cached. #65999
Copy link
Copy link
Open
Labels
A-codegenArea: Code generationArea: Code generationC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.I-compiletimeIssue: Problems and improvements with respect to compile times.Issue: Problems and improvements with respect to compile times.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-codegenArea: Code generationArea: Code generationC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.I-compiletimeIssue: Problems and improvements with respect to compile times.Issue: Problems and improvements with respect to compile times.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
We might be spending a non-trivial amount of time creating
FnAbis and adjusting them, so we should investigate caching them, similar to how we cache LLVMTypes we compute from RustTys.After #65947, this is what's left:
FnAbi::of_instance: takesty::Instance, easy to cachelayout_ofisFnAbi::of_fn_ptr: takesty::PolyFnSig, might be more expensiveinputs_and_outputsis compared/hashed by pointer nowadays, isn't it?Types forfnpointers is already cached itself, but calls offnpointers also requireFnAbisFnAbi::of_instance, so it's lower priority