Hi Richard, > It's ok for instructions to require properties that are false during > early RTL passes and then transition to true. But they can't require > properties that go from true to false, since that would mean that > existing instructions become unrecognisable at certain points during > the compilation process.
Only invalid cases are rejected - can_create_pseudo_p is used to reject instructions that cannot be split after regalloc. This is basically a small extension to that: we always split the aarch64_float_const_rtx_p case before regalloc, and thus no such instructions should exist/created during IRA. So this simply blocks any code that tries to undo the split. > Also, why are the conditions tighter for aarch64_float_const_rtx_p > (which we can split) but not for the general case (which we can't, > and presumably need to force to memory)? I.e. for what cases do we want > the final return to be (sometimes) true? If it's going to be forced > into memory anyway then wouldn't we get better optimisation by exposing > that early? This is the only case that is always split before regalloc. The forced into memory case works exactly like it does now for all other FP immediates. > Would it be possible to handle the split during expand instead? > Or do we expect to discover new FP constants during RTL optimisation? > If so, where do they come from? The split is done during the split passes. The issue is that combine_and_move undoes this split during IRA and creates new FP constants that then require to be split, but they aren't because we don't run split passes during IRA. Cheers, Wilco
