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 case, sure, but it won't solve the underlying problem. The default instruction type for rs6000 is "integer". Many instructions have this type: some bswap, register moves, load address/immediate, mtvrsave, nop, and many things that are split; and that is just those that have type "*" (so are easy to search for), not all those that do no explicitly have a type attribute (including blockage). Now, the power6 scheduler defines a bypass from power6-integer (which is types "integer" as well as "add" and "logical") to stores. And then store_data_bypass_p ICEs because not all "integer" insns are a SET or a PARALLEL of SETs. So, changing the type involves changing the default to something else, changing all pipeline descriptions to do the same with that type as it does with "integer", checking all patterns that are type "integer" to see if they should be that new type or not. Or we could just change "blockage" and wait for the next bug report. 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? Segher
