use mark_julia_const in codegen of typeof when type is known
#15313
Conversation
|
Should we instead have one of the post-inference pass replace every e::Type{X} with X where X has no typevar and e is effect free ? |
|
no, |
|
So should there instead be an overload of |
|
yeah, or just always return a jl_cgval_t, and use |
now `emit_typeof(jl_cgval_t&)` returns a jl_cgval_t, and `emit_typeof_boxed` returns a Value*. also optimize away `typeof` in `inlineable` along with other type functions, and check argument for effect_free.
JeffBezanson
force-pushed
the
jb/codegen_typeof
branch
from
e3afec2 to
305b807
Compare
|
Ok, I've done all of the above. Should be truly beaten to death now :) |
| @@ -1075,6 +1075,9 @@ static Value *emit_typeptr_addr(Value *p) | |||
| return emit_nthptr_addr(p, -offset); | |||
| } | |||
|
|
|||
| static Value *boxed(const jl_cgval_t &v, jl_codectx_t *ctx, bool gcooted=true); | |||
| static Value *boxed(const jl_cgval_t &v, jl_codectx_t *ctx, jl_value_t* type) = delete; // C++11 (temporary to prevent rebase error) | |||
There was a problem hiding this comment.
Make sure there's no use of the original signature?
There was a problem hiding this comment.
correct. C++ will silently convert from a jl_value_t* to bool during dispatch, potentially leading to unhappiness. this makes it a fast error, but won't compile on pre-C++11. if someone needs a pre-C++11 compiler and complains about this, we can either remove the = delete (turning misuse into a linker error), or the whole line (turning misuse into silent corruption).
There was a problem hiding this comment.
We only need a pre-C++11 compiler when building against LLVM 3.3, so if this is behind enough ifdefs to not break that then I think we're fine. Hopefully compiler performance will be at parity soon enough that we could confidently remove the LLVM 3.3 code.
There was a problem hiding this comment.
We only need a pre-C++11 compiler when building against LLVM 3.3
We don't "need" pre-C++11 compiler, we just don't require a c++11 mode. All the compiler we support should support c++11 and we should just bump the compiler flags in Make.inc to enable it.
There was a problem hiding this comment.
clang doesn't seem to care, but i don't know if gcc might
use `mark_julia_const` in codegen of `typeof` when type is known
This improves performance of #15146. In
collect_to!there is a call totypeofin the inner loop, which was generating a store to the gc frame instead of a no-op. @vtjnash is this the right way to do this?