Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fewer anonymous funcs and despecialize inference #2131

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Fewer anonymous funcs and despecialize inference #2131

wants to merge 7 commits into from

Conversation

wsmoses
Copy link
Member

@wsmoses wsmoses commented Nov 28, 2024

No description provided.

Copy link
Contributor

github-actions bot commented Nov 28, 2024

Benchmark Results

main d32a06f... main/d32a06f1ed818d...
basics/overhead 4.64 ± 0.011 ns 4.33 ± 0.01 ns 1.07
time_to_load 1.13 ± 0.013 s 1.14 ± 0.026 s 0.989

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

@wsmoses wsmoses changed the title Fewer anonymous funcs Fewer anonymous funcs and despecialize inference Nov 28, 2024
@wsmoses wsmoses requested a review from vchuravy November 28, 2024 08:18
src/utils.jl Outdated

define i64 @f({} addrspace(10)* %obj) readnone alwaysinline {
%c = addrspacecast {} addrspace(10)* %obj to {} addrspace(11)*
%r = call {}* @julia.pointer_from_objref({} addrspace(11)* %c)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh? Doesn't this break code?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

surprisingly no (I mean this is what the implementation is supposed to do anyways) and now we don't have a cfunction ptr we have to ccall

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should just use Base.unsafe_pointer_to_objref

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was some reason historically why that wasn’t possible, eg some types saying that wasn’t valid for

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just noticed that my brain read something correctly

unsafe_pointer_to_objref(x::Ptr) = ccall(:jl_value_ptr, Any, (Ptr{Cvoid},), x

function pointer_from_objref(@nospecialize(x))
    @inline
    ismutable(x) || error("pointer_from_objref cannot be used on immutable objects")
    ccall(:jl_value_ptr, Ptr{Cvoid}, (Any,), x)
en

So unsafe_pointer_from_objref(x) = ccall(:jl_value_ptr, Ptr{Cvoid}, (Any,), x)

@@ -1,6 +1,6 @@
# For julia runtime function emission

function emit_allocobj!(
Base.@nospecializeinfer function emit_allocobj!(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we import Base: @nospecializeinfer?

Comment on lines 492 to 498
for lbb in blocks(initfn), linst in collect(instructions(lbb))
for lbb in blocks(initfn)
liter = LLVM.API.LLVMGetFirstInstruction(lbb)
while liter != C_NULL
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not simply for linst in instructions(lbb)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm will look at, elsewhere it is required because we may delete the present instruction (so this is akin to the pre increment iterator in llvm)


const swiftself_kind = enum_attr_kind("swiftself")

Base.@assume_effects :removable :foldable :nothrow function has_swiftself(fn::LLVM.Function)::Bool
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why those effects? We shouldn't add them to every function, and I kinda doubt they apply here or are useful?

@@ -81,7 +81,7 @@ end
export unsafe_to_ptr

# This mimicks literal_pointer_val / literal_pointer_val_slot
function unsafe_to_llvm(B::LLVM.IRBuilder, @nospecialize(val))::LLVM.Value
Base.@nospecializeinfer function unsafe_to_llvm(B::LLVM.IRBuilder, @nospecialize(val))::LLVM.Value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do all these @nospecializeinfer actually do anything?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants