On 01/10/2019 20:43, Jeff Law wrote:
On 9/20/19 7:18 PM, co...@sdf.org wrote:
On Fri, Sep 20, 2019 at 10:07:59PM +0000, co...@sdf.org wrote:
Introducing the reversed jbb* patterns doesn't seem to help with the
original issue. It crashes building libatomic.
My loose understanding of what is going on:
- GCC emits this atomic in expand.
- When cleaning up, it looks for optimizations.
- It decides this is a branch to another branch situation, so maybe
can be improved.
- This fails to output an instruction for unrelated reasons.
- Hit an assert.
I don't think that we should be trying to combine regular branch +
atomic branch in very generic code.
I can see how you might think that, but the way the RTL optimizers work,
particularly the combiner is it tries to smash together two or more
insns that are related by dataflow into a single insn (I'm
over-simplifying, but it's good enough for this discussion).
That's an inherent design decision for the combiner, it's not likely to
change. If you want to prevent the combiner from doing that, you have
to use UNSPECs
Jeff
There are some target hooks in combine that might help here.
targetm.cannot_copy_insn_p and targetm.legitimate_combined_insn. The
former is used more widely than just combine, so you might need to be
careful that it doesn't adversely affect other optimizations. The
latter relies on spotting that the combined insn is doing something
stupid even though it matches a pattern in the back-end. So it may be
that neither really solves your problem in this case.
R.
