Open Seelengrab opened 3 weeks ago
Cthlhu disagrees with code typed and
Base.infer_effects(*, (String, String))
(+c,+e,+n,+t,!s,!m,+u,+o)
Which version are you seeing that on? On 1.11-alpha2 I see this:
Which makes sense, since the arguments are Const
and thus are inaccessible. It's just weird that this doesn't end up as a simple return of a constant on the LLVM level, since the concatenation was already computed for the Core.Const("foobar")
:thinking:
Strings are explicitly excluded from being able to be inlined constants:
This could possibly be changed
That's good to know! The comment above that ("No definite size") indicates that this is primarily due to size concerns, but in practice, aren't most string constants that would be const-eval eligible going to be small?
Thinking further, in a static compilation setting it's common to pool global string constants/literals together, for deduplication purposes - not sure how feasible that is with our String
, which IIRC guarantees storing a NUL at the end.. Maybe that's a possible avenue for optimizations?
Consider this silly little function:
which concatenates two string constants,
"foo"
and"bar"
, into one bigger constant"foobar"
. The compiler agrees, and according to Cthulhu, infers that this is a constant:However, even though it's inferred as a constant (and thus
"foobar"
is already allocated somewhere!), the compiler doesn't actually concretely evaluate this:Preferring to do this at runtime instead.
Effects look wonderful too:
So why doesn't the compiler fold this away, since the result was inferred as
Core.Const
& presumably allocated during that?I was able to reproduce this on 1.11 & master.
I've labelled this with
compiler:optimizer
, but I'm not sure this fits there exactly. Feel free to relabel as appropriate.