Closed yowl closed 1 year ago
cc @dotnet/nativeaot-llvm
With release builds:
There is no noticeable difference in time. The last commit shows where I added the StopWatch. Both before and after took between 313 and 370 ms
Before: 320 to 370 ms
After: 313 to 364 ms
However there is a noticeable increase in size of the bitcode for HelloWasm.bc
:
Before 4,108,260 bytes After 4,783,664 bytes
We could have both arrays and structs, switching on the presence of anything of size % ptrsize != 0. If we default to arrays, but switch as soon as we see the first non factor ptrsize
element, that should be nearly as fast as what we have, seeing as the problematic symbol starts with a byte?
Hmm, it would be great to avoid fallbacks, however, I don't have any ideas on how. So the proposed mitigation sounds good to me.
Another option might be to write a byte array instead of an i32 array, I could try that to see if it performs ok, I would expect the size to be as now. Do you think that is worth a try?
How would a byte array represent relocs? With some sort of embedded shifts/ptrtoint
s?
Oh yes, oops, that would be complicated.
Latest commit figures:
Times: 325 to 372 ms unchanged basically Size After: 4,108,588 (328 bytes larger)
Have left the stopwatch in, incase you want to check what I've measured, but will take it out if we are happy with these figures.
Thanks, don't know why the previous build failed. Some blip somewhere.
This PR enables relocs to be written unaligned in anticipation of merging upstream and
StackTraceMethodMappingNode
where it writes a "command" byte before the relocs. This is achieved by using a struct for the object node instead of an array. In many cases this struct will only contain LLVMptr
s and here the reading from the node is unchanged. Reading fromStackTraceMethodMappingNode
when it is tackled will be different...