You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your refactor request related to a problem? Please describe. store instructions on big aggregate types degrade the compile times from milliseconds to seconds. For example
FUNCTION bar : DINTVAR_INPUT
val : STRING[65536];
END_VAREND_FUNCTION
will generate the following IR
definei32@bar([65537 x i8] %0) {
entry:
%bar = allocai32, align4%val = alloca [65537 x i8], align1store [65537 x i8] %0, [65537 x i8]* %val, align1storei320, i32*%bar, align4%bar_ret = loadi32, i32*%bar, align4reti32%bar_ret
}
with store [65537 x i8] %0, [65537 x i8]* %val, align 1 being the problematic line. Replacing the store with a memcpy (and the parameter from [65537 x i8] %0 to i8* %0) reduces the compile times back to milliseconds. This is also highlighted in Performance Tips for Frontend Authors.
Describe the solution you'd like
Pass aggregate types by reference, memcpy them into the local variable defined in VAR_INPUT and work on the memcpy'ed local variable.
Additional context
(Assumption, I'm not 100% sure if it's correct) Internally LLVM / clang will create an assembly file with thousands of load / store instructions, for example a string size of 40 000 will generate the following output with llc (which clang uses internally) bottlenecking the whole compilation to ~50 seconds.
Is your refactor request related to a problem? Please describe.
store
instructions on big aggregate types degrade the compile times from milliseconds to seconds. For examplewill generate the following IR
with
store [65537 x i8] %0, [65537 x i8]* %val, align 1
being the problematic line. Replacing the store with a memcpy (and the parameter from[65537 x i8] %0
toi8* %0
) reduces the compile times back to milliseconds. This is also highlighted in Performance Tips for Frontend Authors.Describe the solution you'd like
Pass aggregate types by reference, memcpy them into the local variable defined in
VAR_INPUT
and work on the memcpy'ed local variable.Additional context
(Assumption, I'm not 100% sure if it's correct) Internally LLVM / clang will create an assembly file with thousands of load / store instructions, for example a string size of
40 000
will generate the following output withllc
(which clang uses internally) bottlenecking the whole compilation to ~50 seconds.The text was updated successfully, but these errors were encountered: