Search Issue Tracker
By Design
Votes
1
Found in [Package]
1.8.19
Issue ID
BUR-2819
Regression
No
Burst Compiler Fails To Inline Generic Type Method
Reproduction steps:
1. Open the attached “IN-89539_Burst Inline Bug.zip“ project
2. Open Burst Inspector (Jobs > Burst > Open Inspector…)
3. Select the “NoiseTestJob32“ under the “NoiseTesting” category
4. Observe
Expected result: Functions are inlined
Actual result: Functions are not inlined, nearing the bottom “bl“ calls are seen
Reproducible with: 1.8.19 (2022.3.57f1, 6000.0.37f1, 6000.1.0b5, 6000.2.0a2)
Reproducible on: Windows 10 (User’s platform), M1 Max MacOS 15.1.1 (Tested by CQA)
Not reproducible on: No other environment tested
Comments (2)
-
chadfranklin47
Feb 20, 2025 00:17
Just some added context:
Burst changelog [1.0.1]:
(the link should be allowed according to the list of validated links, but it gives me an error when trying to include it)
states “Add support for MethodImplOptions.AggressiveInlining to force inlining.“Inlining optimizations are a necessity here.
-
chadfranklin47
Feb 07, 2025 22:35
It seems this issue has been placed in the wrong package. It should be in the Burst package.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Mono Windows Builds don't produce full log callstacks when generating logs
- AssetBundles fail to load when running in Built Players for Mobile Devices
- UI elements with text gets bigger and grey when Player window is moved to another screen with different resolution
- System name accepts multiline text but crops it on confirmation, duplicates input, and shrinks the field when empty
- UI element scale and position are wrong in project build when DRS is changed with HDR and Software Dynamic Resolution enabled
Resolution Note:
In the provided code, the interface is implemented implicitly. This causes the C# compiler to generate an intermediate forwarding method, which does not have the AggressiveInlining attribute. As a result, Burst treats it as a regular method, and the underlying LLVM compiler does not force inlining.
To address this issue, we recommend explicitly implementing the interface. Explicit implementation eliminates the need for a forwarding method, ensuring that it does not prevent inlining.
Keep in mind that Burst provides the LLVM compiler a strong hint to inline methods marked with the AggressiveInlining attribute, but it does not guarantee that they will get inlined.