…42347)

The crash in #42264 showed up when attempting to record the new value for
an SSA rename during unionsplit inlining. Such a crash would only happen when
`compact.idx == 1`, which is an unusual condition, because it implies that no
statement of the original function had yet been processed (which is odd, because
the call being inlined must have been processed by this point). As it turns out, there
is currently exactly one case where this happens. If the inliner sees an `_apply_iterate`
(e.g. from splatting) of something that is not a Tuple or SimpleVector (thus
requiring calls to `iterate` to expand the value during `apply`), and if inference
was able to determine the total length of the resulting iteration, a special case early
inliner, will expand out the splat into explicit iterate calls. E.g. a call like:

     %r = tuple((x::Pair)...)

will be expanded out to

     %a = iterate(x::Pair)
     %b = getfield(%a, 1)
     %c = getfield(%a, 2)
     %d = iterate(x, %c)
     %e = getfield(%d, 1)
     %f = getfield(%d, 2)
     iterate(x, %f)
     %r = tuple(%b, %e)

where the inserted `iterate` calls may themselves be inlined. These newly inserted calls are
"pending nodes" during the actual inlining. Thus, if the original apply call was the first statement
of the function, these nodes would be processed before processing the statements in the function themselves.

In particular, this investigation also shows that `compact.idx`, which is the current location
in the function being inlined into is the wrong value to use for SSA renaming. Rather, we
need to use the SSA value of the just-inserted statement. In the absence of pending nodes,
these are equivalent concepts, but not for pending nodes. Fortunately the IncrementalCompact
iterator provides the old SSA value for just this reason and in fact, non-UnionSplit inlining was
already correct here. Thus, to fix the issue, simply adjust union splitting to work the same way
as a non-UnionSplit inline.

In coming up with the test case, an additional complication is that we currently do not perform this optimization for any calls where the apply call itself was unionsplit. It
is somewhat unusual (which explains why we haven't seen this much) for the apply
to not be union-split, but for the subsequent `iterate` to require union-splitting. In the
problem case, what happened is that for two out of the three union cases, the
`iterate` calls themselves would error, causing the resulting info object to look like
a non-unionsplit apply call, triggering this issue.

Co-authored-by: Keno Fischer <keno@alumni.harvard.edu>
(cherry picked from commit b5f3a99)

…42347)

The crash in #42264 showed up when attempting to record the new value for
an SSA rename during unionsplit inlining. Such a crash would only happen when
`compact.idx == 1`, which is an unusual condition, because it implies that no
statement of the original function had yet been processed (which is odd, because
the call being inlined must have been processed by this point). As it turns out, there
is currently exactly one case where this happens. If the inliner sees an `_apply_iterate`
(e.g. from splatting) of something that is not a Tuple or SimpleVector (thus
requiring calls to `iterate` to expand the value during `apply`), and if inference
was able to determine the total length of the resulting iteration, a special case early
inliner, will expand out the splat into explicit iterate calls. E.g. a call like:
    
     %r = tuple((x::Pair)...)

will be expanded out to

     %a = iterate(x::Pair)
     %b = getfield(%a, 1)
     %c = getfield(%a, 2)
     %d = iterate(x, %c)
     %e = getfield(%d, 1)
     %f = getfield(%d, 2)
     iterate(x, %f)
     %r = tuple(%b, %e)

where the inserted `iterate` calls may themselves be inlined. These newly inserted calls are
"pending nodes" during the actual inlining. Thus, if the original apply call was the first statement
of the function, these nodes would be processed before processing the statements in the function themselves.

In particular, this investigation also shows that `compact.idx`, which is the current location
in the function being inlined into is the wrong value to use for SSA renaming. Rather, we
need to use the SSA value of the just-inserted statement. In the absence of pending nodes,
these are equivalent concepts, but not for pending nodes. Fortunately the IncrementalCompact
iterator provides the old SSA value for just this reason and in fact, non-UnionSplit inlining was
already correct here. Thus, to fix the issue, simply adjust union splitting to work the same way
as a non-UnionSplit inline.

In coming up with the test case, an additional complication is that we currently do not perform this optimization for any calls where the apply call itself was unionsplit. It
is somewhat unusual (which explains why we haven't seen this much) for the apply
to not be union-split, but for the subsequent `iterate` to require union-splitting. In the
problem case, what happened is that for two out of the three union cases, the
`iterate` calls themselves would error, causing the resulting info object to look like
a non-unionsplit apply call, triggering this issue.

Co-authored-by: Keno Fischer <keno@alumni.harvard.edu>

…42347)

The crash in #42264 showed up when attempting to record the new value for
an SSA rename during unionsplit inlining. Such a crash would only happen when
`compact.idx == 1`, which is an unusual condition, because it implies that no
statement of the original function had yet been processed (which is odd, because
the call being inlined must have been processed by this point). As it turns out, there
is currently exactly one case where this happens. If the inliner sees an `_apply_iterate`
(e.g. from splatting) of something that is not a Tuple or SimpleVector (thus
requiring calls to `iterate` to expand the value during `apply`), and if inference
was able to determine the total length of the resulting iteration, a special case early
inliner, will expand out the splat into explicit iterate calls. E.g. a call like:

     %r = tuple((x::Pair)...)

will be expanded out to

     %a = iterate(x::Pair)
     %b = getfield(%a, 1)
     %c = getfield(%a, 2)
     %d = iterate(x, %c)
     %e = getfield(%d, 1)
     %f = getfield(%d, 2)
     iterate(x, %f)
     %r = tuple(%b, %e)

where the inserted `iterate` calls may themselves be inlined. These newly inserted calls are
"pending nodes" during the actual inlining. Thus, if the original apply call was the first statement
of the function, these nodes would be processed before processing the statements in the function themselves.

In particular, this investigation also shows that `compact.idx`, which is the current location
in the function being inlined into is the wrong value to use for SSA renaming. Rather, we
need to use the SSA value of the just-inserted statement. In the absence of pending nodes,
these are equivalent concepts, but not for pending nodes. Fortunately the IncrementalCompact
iterator provides the old SSA value for just this reason and in fact, non-UnionSplit inlining was
already correct here. Thus, to fix the issue, simply adjust union splitting to work the same way
as a non-UnionSplit inline.

In coming up with the test case, an additional complication is that we currently do not perform this optimization for any calls where the apply call itself was unionsplit. It
is somewhat unusual (which explains why we haven't seen this much) for the apply
to not be union-split, but for the subsequent `iterate` to require union-splitting. In the
problem case, what happened is that for two out of the three union cases, the
`iterate` calls themselves would error, causing the resulting info object to look like
a non-unionsplit apply call, triggering this issue.

Co-authored-by: Keno Fischer <keno@alumni.harvard.edu>
(cherry picked from commit b5f3a99)

…42347)

The crash in #42264 showed up when attempting to record the new value for
an SSA rename during unionsplit inlining. Such a crash would only happen when
`compact.idx == 1`, which is an unusual condition, because it implies that no
statement of the original function had yet been processed (which is odd, because
the call being inlined must have been processed by this point). As it turns out, there
is currently exactly one case where this happens. If the inliner sees an `_apply_iterate`
(e.g. from splatting) of something that is not a Tuple or SimpleVector (thus
requiring calls to `iterate` to expand the value during `apply`), and if inference
was able to determine the total length of the resulting iteration, a special case early
inliner, will expand out the splat into explicit iterate calls. E.g. a call like:

     %r = tuple((x::Pair)...)

will be expanded out to

     %a = iterate(x::Pair)
     %b = getfield(%a, 1)
     %c = getfield(%a, 2)
     %d = iterate(x, %c)
     %e = getfield(%d, 1)
     %f = getfield(%d, 2)
     iterate(x, %f)
     %r = tuple(%b, %e)

where the inserted `iterate` calls may themselves be inlined. These newly inserted calls are
"pending nodes" during the actual inlining. Thus, if the original apply call was the first statement
of the function, these nodes would be processed before processing the statements in the function themselves.

In particular, this investigation also shows that `compact.idx`, which is the current location
in the function being inlined into is the wrong value to use for SSA renaming. Rather, we
need to use the SSA value of the just-inserted statement. In the absence of pending nodes,
these are equivalent concepts, but not for pending nodes. Fortunately the IncrementalCompact
iterator provides the old SSA value for just this reason and in fact, non-UnionSplit inlining was
already correct here. Thus, to fix the issue, simply adjust union splitting to work the same way
as a non-UnionSplit inline.

In coming up with the test case, an additional complication is that we currently do not perform this optimization for any calls where the apply call itself was unionsplit. It
is somewhat unusual (which explains why we haven't seen this much) for the apply
to not be union-split, but for the subsequent `iterate` to require union-splitting. In the
problem case, what happened is that for two out of the three union cases, the
`iterate` calls themselves would error, causing the resulting info object to look like
a non-unionsplit apply call, triggering this issue.

Co-authored-by: Keno Fischer <keno@alumni.harvard.edu>
(cherry picked from commit b5f3a99)

…42347)

The crash in #42264 showed up when attempting to record the new value for
an SSA rename during unionsplit inlining. Such a crash would only happen when
`compact.idx == 1`, which is an unusual condition, because it implies that no
statement of the original function had yet been processed (which is odd, because
the call being inlined must have been processed by this point). As it turns out, there
is currently exactly one case where this happens. If the inliner sees an `_apply_iterate`
(e.g. from splatting) of something that is not a Tuple or SimpleVector (thus
requiring calls to `iterate` to expand the value during `apply`), and if inference
was able to determine the total length of the resulting iteration, a special case early
inliner, will expand out the splat into explicit iterate calls. E.g. a call like:

     %r = tuple((x::Pair)...)

will be expanded out to

     %a = iterate(x::Pair)
     %b = getfield(%a, 1)
     %c = getfield(%a, 2)
     %d = iterate(x, %c)
     %e = getfield(%d, 1)
     %f = getfield(%d, 2)
     iterate(x, %f)
     %r = tuple(%b, %e)

where the inserted `iterate` calls may themselves be inlined. These newly inserted calls are
"pending nodes" during the actual inlining. Thus, if the original apply call was the first statement
of the function, these nodes would be processed before processing the statements in the function themselves.

In particular, this investigation also shows that `compact.idx`, which is the current location
in the function being inlined into is the wrong value to use for SSA renaming. Rather, we
need to use the SSA value of the just-inserted statement. In the absence of pending nodes,
these are equivalent concepts, but not for pending nodes. Fortunately the IncrementalCompact
iterator provides the old SSA value for just this reason and in fact, non-UnionSplit inlining was
already correct here. Thus, to fix the issue, simply adjust union splitting to work the same way
as a non-UnionSplit inline.

In coming up with the test case, an additional complication is that we currently do not perform this optimization for any calls where the apply call itself was unionsplit. It
is somewhat unusual (which explains why we haven't seen this much) for the apply
to not be union-split, but for the subsequent `iterate` to require union-splitting. In the
problem case, what happened is that for two out of the three union cases, the
`iterate` calls themselves would error, causing the resulting info object to look like
a non-unionsplit apply call, triggering this issue.

Co-authored-by: Keno Fischer <keno@alumni.harvard.edu>
(cherry picked from commit b5f3a99)

…uliaLang#42347)

The crash in JuliaLang#42264 showed up when attempting to record the new value for
an SSA rename during unionsplit inlining. Such a crash would only happen when
`compact.idx == 1`, which is an unusual condition, because it implies that no
statement of the original function had yet been processed (which is odd, because
the call being inlined must have been processed by this point). As it turns out, there
is currently exactly one case where this happens. If the inliner sees an `_apply_iterate`
(e.g. from splatting) of something that is not a Tuple or SimpleVector (thus
requiring calls to `iterate` to expand the value during `apply`), and if inference
was able to determine the total length of the resulting iteration, a special case early
inliner, will expand out the splat into explicit iterate calls. E.g. a call like:
    
     %r = tuple((x::Pair)...)

will be expanded out to

     %a = iterate(x::Pair)
     %b = getfield(%a, 1)
     %c = getfield(%a, 2)
     %d = iterate(x, %c)
     %e = getfield(%d, 1)
     %f = getfield(%d, 2)
     iterate(x, %f)
     %r = tuple(%b, %e)

where the inserted `iterate` calls may themselves be inlined. These newly inserted calls are
"pending nodes" during the actual inlining. Thus, if the original apply call was the first statement
of the function, these nodes would be processed before processing the statements in the function themselves.

In particular, this investigation also shows that `compact.idx`, which is the current location
in the function being inlined into is the wrong value to use for SSA renaming. Rather, we
need to use the SSA value of the just-inserted statement. In the absence of pending nodes,
these are equivalent concepts, but not for pending nodes. Fortunately the IncrementalCompact
iterator provides the old SSA value for just this reason and in fact, non-UnionSplit inlining was
already correct here. Thus, to fix the issue, simply adjust union splitting to work the same way
as a non-UnionSplit inline.

In coming up with the test case, an additional complication is that we currently do not perform this optimization for any calls where the apply call itself was unionsplit. It
is somewhat unusual (which explains why we haven't seen this much) for the apply
to not be union-split, but for the subsequent `iterate` to require union-splitting. In the
problem case, what happened is that for two out of the three union cases, the
`iterate` calls themselves would error, causing the resulting info object to look like
a non-unionsplit apply call, triggering this issue.

Co-authored-by: Keno Fischer <keno@alumni.harvard.edu>

…uliaLang#42347)

The crash in JuliaLang#42264 showed up when attempting to record the new value for
an SSA rename during unionsplit inlining. Such a crash would only happen when
`compact.idx == 1`, which is an unusual condition, because it implies that no
statement of the original function had yet been processed (which is odd, because
the call being inlined must have been processed by this point). As it turns out, there
is currently exactly one case where this happens. If the inliner sees an `_apply_iterate`
(e.g. from splatting) of something that is not a Tuple or SimpleVector (thus
requiring calls to `iterate` to expand the value during `apply`), and if inference
was able to determine the total length of the resulting iteration, a special case early
inliner, will expand out the splat into explicit iterate calls. E.g. a call like:
    
     %r = tuple((x::Pair)...)

will be expanded out to

     %a = iterate(x::Pair)
     %b = getfield(%a, 1)
     %c = getfield(%a, 2)
     %d = iterate(x, %c)
     %e = getfield(%d, 1)
     %f = getfield(%d, 2)
     iterate(x, %f)
     %r = tuple(%b, %e)

where the inserted `iterate` calls may themselves be inlined. These newly inserted calls are
"pending nodes" during the actual inlining. Thus, if the original apply call was the first statement
of the function, these nodes would be processed before processing the statements in the function themselves.

In particular, this investigation also shows that `compact.idx`, which is the current location
in the function being inlined into is the wrong value to use for SSA renaming. Rather, we
need to use the SSA value of the just-inserted statement. In the absence of pending nodes,
these are equivalent concepts, but not for pending nodes. Fortunately the IncrementalCompact
iterator provides the old SSA value for just this reason and in fact, non-UnionSplit inlining was
already correct here. Thus, to fix the issue, simply adjust union splitting to work the same way
as a non-UnionSplit inline.

In coming up with the test case, an additional complication is that we currently do not perform this optimization for any calls where the apply call itself was unionsplit. It
is somewhat unusual (which explains why we haven't seen this much) for the apply
to not be union-split, but for the subsequent `iterate` to require union-splitting. In the
problem case, what happened is that for two out of the three union cases, the
`iterate` calls themselves would error, causing the resulting info object to look like
a non-unionsplit apply call, triggering this issue.

Co-authored-by: Keno Fischer <keno@alumni.harvard.edu>

…42347)

The crash in #42264 showed up when attempting to record the new value for
an SSA rename during unionsplit inlining. Such a crash would only happen when
`compact.idx == 1`, which is an unusual condition, because it implies that no
statement of the original function had yet been processed (which is odd, because
the call being inlined must have been processed by this point). As it turns out, there
is currently exactly one case where this happens. If the inliner sees an `_apply_iterate`
(e.g. from splatting) of something that is not a Tuple or SimpleVector (thus
requiring calls to `iterate` to expand the value during `apply`), and if inference
was able to determine the total length of the resulting iteration, a special case early
inliner, will expand out the splat into explicit iterate calls. E.g. a call like:

     %r = tuple((x::Pair)...)

will be expanded out to

     %a = iterate(x::Pair)
     %b = getfield(%a, 1)
     %c = getfield(%a, 2)
     %d = iterate(x, %c)
     %e = getfield(%d, 1)
     %f = getfield(%d, 2)
     iterate(x, %f)
     %r = tuple(%b, %e)

where the inserted `iterate` calls may themselves be inlined. These newly inserted calls are
"pending nodes" during the actual inlining. Thus, if the original apply call was the first statement
of the function, these nodes would be processed before processing the statements in the function themselves.

In particular, this investigation also shows that `compact.idx`, which is the current location
in the function being inlined into is the wrong value to use for SSA renaming. Rather, we
need to use the SSA value of the just-inserted statement. In the absence of pending nodes,
these are equivalent concepts, but not for pending nodes. Fortunately the IncrementalCompact
iterator provides the old SSA value for just this reason and in fact, non-UnionSplit inlining was
already correct here. Thus, to fix the issue, simply adjust union splitting to work the same way
as a non-UnionSplit inline.

In coming up with the test case, an additional complication is that we currently do not perform this optimization for any calls where the apply call itself was unionsplit. It
is somewhat unusual (which explains why we haven't seen this much) for the apply
to not be union-split, but for the subsequent `iterate` to require union-splitting. In the
problem case, what happened is that for two out of the three union cases, the
`iterate` calls themselves would error, causing the resulting info object to look like
a non-unionsplit apply call, triggering this issue.

Co-authored-by: Keno Fischer <keno@alumni.harvard.edu>
(cherry picked from commit b5f3a99)