This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: syncing the GCC vax port, atomic issue
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Cc: Jeff Law <law at redhat dot com>, coypu at sdf dot org, gcc at gcc dot gnu dot org, port-vax at netbsd dot org
- Date: Wed, 2 Oct 2019 12:17:14 -0500
- Subject: Re: syncing the GCC vax port, atomic issue
- References: <20190330090306.GA29299@SDF.ORG> <180b1040-215f-e6dc-599b-394d91761d88@redhat.com> <20190920111532.GB15685@SDF.ORG> <20190920210434.GA13838@SDF.ORG> <010f52a3-98ed-47f9-38af-2560193b6a52@redhat.com> <20190920220756.GA10628@SDF.ORG> <20190921011835.GA5931@SDF.ORG> <86ce35ec-9471-66bc-bf0d-72a1b5d7813e@redhat.com> <14f417df-83f4-13ac-9f10-73b1192b74f8@arm.com>
On Wed, Oct 02, 2019 at 10:39:23AM +0100, Richard Earnshaw (lists) wrote:
> 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.
Well, if what you need to prevent here is two branches from being combined
into one, you need to prevent many more passes than just combine from doing
the same, so this hook won't really help you.
I don't quite see why the generic optimisers make something that ICEs
later here, but yeah UNSPECs can side-step this whole issue.
Segher