more compiler cleanup [nfc] #27945
more compiler cleanup [nfc] #27945
Conversation
|
@nanosoldier |
|
What does "nfc" stand for? Near-field communication? |
|
No functional changes |
| NULL, // cmds | ||
| NULL, // image_file (will be filled in below) | ||
| NULL, // cpu_target ("native", "core2", etc...) | ||
| 0, // nprocs | ||
| NULL, // machine_file | ||
| NULL, // project |
There was a problem hiding this comment.
Thanks for the fix! (Although it really should be in a separate PR or at least a separate commit.)
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
|
I don't understand how this could have affected allocations for |
|
@nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
- dereferenceable attribute requires align attribute (if eltype is not sized) or it is simply ignored - tbaa_const isn't necessarily sufficient to allow LICM hoisting. an unknown call instruction (such as julia.gc_alloc_obj) present in the same loop can prevent TBAA from declaring the memory to be immutable. However, the invariant.load attribute is much stronger: additionally mark all tbaa_const loads with MD_immutable_load, permitting llvm to reorder and left them them much more freely (requiring only dereferenceable).
vtjnash
force-pushed
the
jn/arrayvar-cleanup
branch
from
f6bd488 to
d803472
Compare
|
Not precisely NFC anymore, since this uncovered optimizations that we thought were happening but weren’t, so @nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
No description provided.