On Mon, Oct 21, 2019 at 01:27:23PM +0200, Jakub Jelinek wrote:
> On Mon, Oct 21, 2019 at 05:45:16AM -0500, Segher Boessenkool wrote:
> > On Sun, Oct 20, 2019 at 09:51:22PM +0200, Uros Bizjak wrote:
> > > On Sun, Oct 20, 2019 at 1:24 PM Jakub Jelinek wrote:
> > > > As mentioned in the PR, the x86
On Mon, Oct 21, 2019 at 05:45:16AM -0500, Segher Boessenkool wrote:
> On Sun, Oct 20, 2019 at 09:51:22PM +0200, Uros Bizjak wrote:
> > On Sun, Oct 20, 2019 at 1:24 PM Jakub Jelinek wrote:
> > > As mentioned in the PR, the x86 backend has various define_insn_and_split
> > > patterns that are meant
On Sun, Oct 20, 2019 at 09:51:22PM +0200, Uros Bizjak wrote:
> On Sun, Oct 20, 2019 at 1:24 PM Jakub Jelinek 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
On Sun, Oct 20, 2019 at 1:24 PM Jakub Jelinek wrote:
>
> Hi!
>
> 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 ()
>
Hi!
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,
