- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Hoist object allocation before inner field initialization (#45153)
* Hoist object allocation before inner field initialization Consider the following pattern for building up nested objects ``` %obj = Expr(:new, obj, ...) %obj_wrapper = Expr(:new, obj_wrapper, ..., %obj) %obj_wrapper2 = Expr(:new, obj_wrapper2, ..., %obj_wrapper) %outer = Expr(:new, outer, %obj_wrapper2) ``` Asssuming everything except `struct outer` is struct-inlineable, the LLVM IR we emit looks something like the following: ``` %obj = alloca %obj_wrapper = alloca %obj_wrapper_wrapper = alloca %obj = alloca init(%obj, <obj>) init(%obj_wrapper, <obj_wrapper>); memcpy(%obj_wrapper, %obj) init(%obj_wrapper2, <obj_wrapper2>); memcpy(%obj_wrapper2, %obj_wrapper) init(%outer, <outer>); memcpy(%outer, %obj_wrapper2) %outer_boxed = julia.gc_alloc memcpy(%outer_boxed, %outer) ``` While LLVM is capable of removing all the allocas and memcpys, it's taking an unreasonable amount of time to do so. This PR introduces a small optimization into the frontend lowering for `:new`: If all the :new calls are in the same LLVM basic block, then we delete the alloca, and hoist the allocation of the object to the earliest point before the initialization of the fields. This gives essentially the same result as LLVM would have given us post-optimization, but is much cheaper to do because we don't have to perform any analysis to tell us that it is a legal optimization. In the above example, we would end up with something like: ``` %outer_boxed = julia.gc_alloc init(%outer_boxed, <obj>) init(%outer_boxed, <obj_wrapper>); init(%outer_boxed, <obj_wrapper2>); init(%outer_boxed, <outer>); ``` Of course this does extend the liftime of the outer object, but I don't think that's a particular problem as long as we're careful not to hoist any boxings out of error paths. In the current implementation, I only allow this optimization to occur in the same LLVM basic block, but I think it should be fine to extend it to allow the same julia basic block or more generally, any allocation that post-dominates the relevant promotion points. * fix codegen bug Co-authored-by: Keno Fischer <keno@juliacomputing.com>
- v1.11.3
- v1.11.2
- v1.11.1
- v1.11.0
- v1.11.0-rc4
- v1.11.0-rc3
- v1.11.0-rc2
- v1.11.0-rc1
- v1.11.0-beta2
- v1.11.0-beta1
- v1.11.0-alpha2
- v1.11.0-alpha1
- v1.10.8
- v1.10.7
- v1.10.6
- v1.10.5
- v1.10.4
- v1.10.3
- v1.10.2
- v1.10.1
- v1.10.0
- v1.10.0-rc3
- v1.10.0-rc2
- v1.10.0-rc1
- v1.10.0-beta3
- v1.10.0-beta2
- v1.10.0-beta1
- v1.10.0-alpha1
- v1.9.4
- v1.9.3
- v1.9.2
- v1.9.1
- v1.9.0
- v1.9.0-rc3
- v1.9.0-rc2
- v1.9.0-rc1
- v1.9.0-beta4
- v1.9.0-beta3
- v1.9.0-beta2
- v1.9.0-beta1
- v1.9.0-alpha1
Showing
2 changed files
with
197 additions
and
51 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
93ac4a3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Executing the daily package evaluation, I will reply here when finished:
@nanosoldier
runtests(ALL, isdaily = true)
93ac4a3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your package evaluation job has completed - possible new issues were detected. A full report can be found here.