Bernd Edlinger wrote: > No, the split condition does not begin with "&& TARGET_32BIT...". > Therefore the split is enabled in TARGET_NEON after reload_completed. > And it is invoked from adddi3_neon for all alternatives without vfp > registers:
Hmm that's a huge mess. I'd argue that any inst_and_split should only split it's own instruction, never other instructions (especially if they are from different md files, which is extremely confusing). Otherwise we should use a separate split and explicitly list which instructions it splits. So then the next question is whether the neon_adddi3 still needs the arm_adddi3 splitter in some odd corner cases? > > Also there are more cases, a quick grep suggests *anddi_notdi_di has the > > same issue. > Yes, that pattern can be cleaned up in a follow-up patch. And there are a lot more instructions that need the same treatment and split early (probably best at expand time). I noticed none of the zero/sign extends split before regalloc for example. > Note this splitter is invoked from bicdi3_neon as well. > However I think anddi_notdi_di should be safe as long as it is enabled > after reload_completed (which is probably a bug). Since we should be splitting and/bic early now I don't think you can get anddi_notdi anymore. So it could be removed completely assuming Neon already does the right thing. It looks like we need to do a full pass over all DI mode instructions and clean up all the mess. Wilco
