Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: syncing the GCC vax port, atomic issue



On 01/10/2019 20:43, Jeff Law wrote:
On 9/20/19 7:18 PM, coypu%sdf.org@localhost wrote:
On Fri, Sep 20, 2019 at 10:07:59PM +0000, coypu%sdf.org@localhost 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.


Home | Main Index | Thread Index | Old Index