[Sorry for the slow response] Jeff Law <j...@ventanamicro.com> writes: > On 11/20/23 11:26, Richard Sandiford wrote: >> >> scalar_int_mode outer_mode; >> if (!is_a<scalar_int_mode> (GET_MODE (x), &outer_mode) >> || GET_MODE_BITSIZE (outer_mode) > 64) >> continue; > Wouldn't we also want to verify that the size is constant, or is it the > case that all the variable cases are vector (and would we want to > actually depend on that)?
Yeah, all the variable cases are vectors. We don't support variable-length scalars at the moment. (And I hope that never changes. :)) >>> + /* We will handle the other operand of a binary operator >>> + at the bottom of the loop by resetting Y. */ >>> + if (BINARY_P (src)) >>> + y = XEXP (src, 0); >> >> What about UNARY_P, given that NOT is included in the codes above? > We'll break that inner for(;;) then iterate into the subobject, marking > the relevant bits live. FWIW, the control flow of this code continues > to be my biggest concern from a maintenance standpoint. Figuring it out > was a major pain and I've tried to document what is and what is not > safe. But it's still painful to walk through. > > I pondered if note_uses/note_stores would be better, but concluded we'd > just end up with a ton of state objects to carry around and reasoning > about that would be just as hard. Feels like it would be good to handle the top-level structure explicitly, (PARALLELs, SETs, SET_SRCs, etc.), then fall back to iteration at the point that we can no longer do better then "all registers in this expression are fully live". If we do that, rtx_properties might be an alternative to explicit iteration. The advantage of that is that it can handle destination and sources as the top-level expression, and records whether each register is itself a destination or source. Thanks, Richard
