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 descriptions, by having > > our own version of store_data_bypass_p; or we can make that function > > work for all insns (its definition works fine for insn pairs where > > not both the producer and consumer are SETs). That's what Kelvin's > > patch does. What is the value in ICEing here? > > Telling the back-end writer that something may be wrong somewhere instead of > silently accepting nonsense?
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. > How long have all the assertions been there? 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). Segher