TypeAnalysis: fall back to LLVM type for extractvalue when operand has no type info

[Copilot]

When an opaque function call returns a struct containing float arrays, TypeAnalysis produces {} (unknown) for the call result. Subsequent extractvalue instructions that extract fields from that result inherit the unknown type, causing "Cannot deduce type of extract" errors during differentiation.

Root cause

visitExtractValueInst propagates type info via ShiftIndices on the operand's TypeTree. When the operand is {}, ShiftIndices returns {}, leaving the extracted value with no type info — even when the LLVM IR type is unambiguous (e.g., [2 x float]).

Fix

In the DOWN direction of visitExtractValueInst, when ShiftIndices yields no type info, fall back to defaultTypeTreeForLLVM(I.getType(), &I, /*intIsPointer=*/false). Unlike memory loads where aliasing can create type ambiguity, extractvalue operates on value-typed aggregates whose field types are fully determined by the IR — making the LLVM type authoritative.

%struct.c_v = type { [2 x float], [2 x [3 x float]] }
declare %struct.c_v @pre_work()

; Before fix: %f0 has type {} → "Cannot deduce type" error
; After fix:  %f0 has type {[-1]:Float@float}
%cv    = call %struct.c_v @pre_work()
%f2    = extractvalue %struct.c_v %cv, 0        ; [2 x float] → {[-1]:Float@float}
%f0    = extractvalue [2 x float] %f2, 0        ; float       → {[-1]:Float@float}
%f2x3  = extractvalue %struct.c_v %cv, 1        ; [2 x [3 x float]] → {[-1]:Float@float}
%f00   = extractvalue [2 x [3 x float]] %f2x3, 0, 0  ; float  → {[-1]:Float@float}

The fix also triggers UP-direction back-propagation, so the opaque call result itself gets float type annotations at the appropriate offsets.

Test

Added test/TypeAnalysis/extractvalue_opaque_call.ll covering multi-level extractvalue chains from opaque struct-returning calls.