> The old code was inconsistent, had return false; in one case and assert in
> the remaining two spots. If you are not against it, I'd use return false;
> in both cases if we want consistency.
Sure, thanks.
--
Eric Botcazou
On Mon, Dec 11, 2017 at 01:26:42PM +0100, Eric Botcazou wrote:
> > Ah, that makes a lot of sense. So like this?
> >
> > 2017-12-11 Jakub Jelinek
> >
> > * recog.c (store_data_bypass_p_1): New function.
> > (store_data_bypass_p): Handle USE in a PARALLEL like CLOBBER. Use
> > stor
> Ah, that makes a lot of sense. So like this?
>
> 2017-12-11 Jakub Jelinek
>
> * recog.c (store_data_bypass_p_1): New function.
> (store_data_bypass_p): Handle USE in a PARALLEL like CLOBBER. Use
> store_data_bypass_p_1 to avoid code duplication. Formatting fixes.
Yes, b
> Is that long enough to be worth it? I mean, in all other places (rtlanal.c,
> recog.c, ...) we use similar code in all spots where it is needed, adding
> an inline would just mean yet another thing to remember. Or do you mean
> CLOBBER_OR_USE_P macro?
No, the whole function, it seems to duplic
On Mon, Dec 11, 2017 at 11:45:25AM +0100, Eric Botcazou wrote:
> > When looking at the rs6000_store_data_bypass_p stuff, I've noticed that
> > it accepts PARALLELs containing not just SETs and CLOBBERs like
> > store_data_bypass_p, but also USEs. Given that it is something that
> > single_set also
> When looking at the rs6000_store_data_bypass_p stuff, I've noticed that
> it accepts PARALLELs containing not just SETs and CLOBBERs like
> store_data_bypass_p, but also USEs. Given that it is something that
> single_set also ignores, I think fixing store_data_bypass_p is the
> right fix here.
>
