Try to fix missing libc++.so.1 errors in arm64 llvmaot perf run#88705
Try to fix missing libc++.so.1 errors in arm64 llvmaot perf run#88705directhex merged 16 commits intodotnet:mainfrom
Conversation
|
Tagging subscribers to this area: @hoyosjs Issue Detailsnull
|
|
Tagging subscribers to this area: @directhex Issue Detailsnull
|
|
I think this passed on internal CI? @LoopedBard3 @DrewScoggins @caaavik-msft if y'all are happy, plz approve and merge |
|
Looking back into the internal run, there are a lot of errors in the format of: Do you know what the impact of this is on the rest of the testing and do you happen to know a good fix? Thanks! |
|
I think generally "condition 'corlib' not met" means the corlib wasn't found in the searched locations. I'm not sure where it's being copied too & searched for. Do you want me to try & figure a fix for that here, or in another PR? |
|
Either works, if kept in this PR we could rename the PR to something like "Update MonoAOT perf flow". |
|
OK. What's the minimally complex way I can reproduce the errors locally? How can I get a folder which looks like what's trying to run on Helix and a copy of the command we're trying to execute on there? |
|
@LoopedBard3 I think other changes in the interim have dealt with the missing Can we determine where we stand, with this PR in as-is? |
|
I will do another run so we can see if the issue has been fixed in the CI. @directhex The last change that I think is needed for the PR is to add the same monoAOT build args changes to the perf-non-wasm-jobs.yml. |
|
I have started a test run here: https://dev.azure.com/dnceng/internal/_build/results?buildId=2230039&view=results |
|
FWIW, you can try #88917 as a fix for the browser-wasm failing job |
The corelib issue has been fixed, check discussion in dotnet/BenchmarkDotNet#2311. Currently, there is another issue with nuget package versions reported in dotnet/performance#3164. |
I don't see any cases in perf-non-wasm-jobs.yml which are clearly wrong (just a lot of things using defaults). Are there further failures happening, in that set of pipelines? |
|
I think this issue is linux-arm64 specific which is in: runtime/eng/pipelines/coreclr/perf_slow.yml Lines 156 to 173 in 1138b24 The |
I will do a test run to verify. I noticed that some changes were made to perf_job.yml and what not. We use perf_job.yml for both sets perf_slow and perf-non-wasm-jobs, so if these changes are compatible with how we are already building in perf-non-wasm-jobs we are good. |
|
The error may have been made by using the same perf_slow build args for the non-wasm jobs run. Trying a run with the currently working Wasm AOT Build args. |
|
The Mono AOT LLVM arm64 perf lanes are broken due to this. What else needs to get this merged ? |
|
@LoopedBard3 the Helix queue seems to be pretty backed up so the internal runs will keep timing out, can we clear the queue? |
@DrewScoggins @cincuranet Any thoughts? |
|
@LoopedBard3 I don't know whether we have knobs to clear the queue. |
|
@cincuranet you can ask dnceng on the First Responders channel, they have the knobs. |
|
OK, x64 seems to be good. I think there's still a failure condition in arm64 ( |
|
I think I'm going to try and eliminate MonoBundleLLVMOptimizer and MonoAOTBundleLLVMOptimizer entirely. It's such an odd switch to include. Either you want a functional LLVM AOT (with opt/llc included) or you don't. |
I'm going to do this IN ANOTHER PR, since I've actually been making progress with fixing issues in this PR with the existing properties. |
|
I'm declaring this "good enough for now" X64 https://dev.azure.com/dnceng/internal/_build/results?buildId=2238462&view=results ARM64 run isn't finished, but has at least some tests passing already so unblocks the failures: |


No description provided.