On Tue, Apr 18, 2017 at 10:01:02PM +0200, Eric Botcazou wrote:
> > There are workarounds to this problem as well: mips_store_data_bypass_p,
> > added in 2006. mep_store_data_bypass_p, added in 2009 (the port has
> > been removed since then, of course).
>
> I see, no strong opinion then, but indiv
[Sorry for the long delay]
> Why is it nonsense? The predicate gives the answer to the question
> "given these insns A and B, does A feed data that B stores in memory".
> That is a perfectly valid question to ask of any two insns.
I disagree, for example it's nonsensical to send it a blockage in
On Mon, Apr 10, 2017 at 06:38:07PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Fri, Apr 07, 2017 at 10:39:03AM +0200, Eric Botcazou wrote:
> >> > Or we could just change "blockage" and wait for the next bug report.
> >>
> >> That's my suggestion, yes.
> >>
> >> > Alternat
Segher Boessenkool writes:
> On Fri, Apr 07, 2017 at 10:39:03AM +0200, Eric Botcazou wrote:
>> > Or we could just change "blockage" and wait for the next bug report.
>>
>> That's my suggestion, yes.
>>
>> > Alternatively, we can arrange for the bypass functions to not ICE. We
>> > can do that s
On Fri, Apr 07, 2017 at 10:39:03AM +0200, Eric Botcazou wrote:
> > Or we could just change "blockage" and wait for the next bug report.
>
> That's my suggestion, yes.
>
> > Alternatively, we can arrange for the bypass functions to not ICE. We
> > can do that specific to these rs6000 pipeline des
> Or we could just change "blockage" and wait for the next bug report.
That's my suggestion, yes.
> Alternatively, we can arrange for the bypass functions to not ICE. We
> can do that specific to these rs6000 pipeline descriptions, by having
> our own version of store_data_bypass_p; or we can ma
On Fri, Apr 07, 2017 at 08:54:01AM +0200, Eric Botcazou wrote:
> > The only straightforward way I see is to use a rs6000_store_data_bypass_p
> > instead, which would be doing the same thing. :-(
>
> Why not just change the type of the blockage instruction as you suggested?
That works for this ca
> The only straightforward way I see is to use a rs6000_store_data_bypass_p
> instead, which would be doing the same thing. :-(
Why not just change the type of the blockage instruction as you suggested?
--
Eric Botcazou
On Thu, Apr 06, 2017 at 10:05:54PM +0200, Eric Botcazou wrote:
> > [This is a repost of a patch previously posted on 3/29/2017.
> > Eric, I hope you might consider that this falls within your scope
> > of maintenance. Thanks.]
>
> My viewpoint is that it's better to keep the assertions and fix th
> [This is a repost of a patch previously posted on 3/29/2017.
> Eric, I hope you might consider that this falls within your scope
> of maintenance. Thanks.]
My viewpoint is that it's better to keep the assertions and fix the back-end
instead, which looks rather straightforward.
--
Eric Botcaz
[This is a repost of a patch previously posted on 3/29/2017.
Eric, I hope you might consider that this falls within your scope
of maintenance. Thanks.]
This problem reports an assertion error when certain rtl expressions
which are not eligible as producers or consumers of a store bypass
optimiza
This problem reports an assertion error when certain rtl expressions
which are not eligible as producers or consumers of a store bypass
optimization are passed as arguments to the store_data_bypass_p
function. The proposed patch returns false from store_data_bypass_p
rather than terminating with
12 matches
Mail list logo
