Jeff and Segher, thanks for the clarifications and hints! Bohan, I assume you will have a look at this (there is also PR119587 to keep track of it).
BR Christoph On Mon, Jun 9, 2025 at 6:28 PM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > On Mon, Jun 09, 2025 at 08:26:10AM -0600, Jeff Law wrote: > > On 4/1/25 9:35 PM, Jeff Law wrote: > > So returning to this.... > > > > So the combine pass doesn't reject combination into an ASM_INPUT, just > > combination from most ASM_INPUTs. > > Yeah, exactly. > > > It does rely on predicates to determine validity. > > More precisely, recog() does. > > > So my suspicion is > > that the memory_operand (or one of the closely related) predicates is > > returning true for an addressing mode is that is not always valid. > > Yeah, some target issue. > > > Or to put it another way, addressing mode validity is based on two > > properties. The form of the address and the mode of the memory > > reference. If any other context is needed to determine validity, then > > that addressing format must not be considered valid for the given memory > > access mode. > > > > I hope I didn't steer you the wrong way on that issue Christoph! > > Yeah, sounds like a bug in TARGET_LEGITIMATE_ADDRESS_P . > > > So at best this splitter is still just papering over a bigger problem > > that needs to be fixed. > > Essentially all splitters that are made just for combine paper over > something (not define_insn_and_split, I mean pure splitters here; > sometimes you want to allow combine to create something complex). > > > Segher
