On Sun, Oct 20, 2019 at 09:51:22PM +0200, Uros Bizjak wrote: > On Sun, Oct 20, 2019 at 1:24 PM Jakub Jelinek <ja...@redhat.com> wrote: > > As mentioned in the PR, the x86 backend has various define_insn_and_split > > patterns that are meant to match usually during combine, are then > > unconditionally split during split1 pass and as they have && > > can_create_pseudo_p () > > in their define_insn condition, if they get matched after split1, nothing > > would split them anymore and they wouldn't match after reload. > > > > The split1 pass already sets a property that can be used. > > > > I've first tried to remove some constraints and associated attributes, but > > it seems from further discussions in the PR I don't know much about the > > reasons why they were added and if they are still needed or not, so this > > version of the patch just replaces the can_create_pseudo_p () conditions > > with a new predicate that stops matching already after the split1 pass. > > As explained by Segher in the PR, there is no 100% guarantee that > combine won't produce a pattern with a wrong hard register as a e.g. > count reg of a shift insn. RA will die on this kind of pattern with > reload failure, so these constraints are used together with > ix86_legitimate_combined_insn target hook to reject invalid > combinations involving hard registers.
And even that isn't completely safe, there is nothing that stops other passes from creating the offending insns. i386 isn't the only target doing nasty things here, btw., the sky hasn't come crashing down for many years, we'll all be okay. Fingers crossed. Segher
