search for: functiontyperesolution

...ed to know which functions have jumptable entries created for them (they will need to be RAUWed with f.cfi-jt). In the Cross-DSO mode, external functions don’t get jumptable entries. This information is passed back from the LTO step through combined summary. The current idea is to add a new record, FunctionTypeResolution, which would contain a set of function names in the jumptable. == Alternatives Function type information can be passed in the summary, as a list of records (name, linkage, type(, type)*). * Type can be either a string or a number. This complicates the encoding. * The code in LowerTypeTests works...

...table entries >> created for them (they will need to be RAUWed with f.cfi-jt). In the >> Cross-DSO mode, external functions don’t get jumptable entries. This >> information is passed back from the LTO step through combined summary. >> The current idea is to add a new record, FunctionTypeResolution, which >> would contain a set of function names in the jumptable. > > > It occurred to me that this design could prevent inlining of indirect calls > via constant propagation. For example, suppose that we have a module that > looks like this: > > define void @f() { >...

...ted for them (they will need to be RAUWed with f.cfi-jt). In the > >>> Cross-DSO mode, external functions don’t get jumptable entries. This > >>> information is passed back from the LTO step through combined summary. > >>> The current idea is to add a new record, FunctionTypeResolution, which > >>> would contain a set of function names in the jumptable. > >> > >> > >> It occurred to me that this design could prevent inlining of indirect > calls > >> via constant propagation. For example, suppose that we have a module > that &g...