This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.
- From: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>, vogt at linux dot vnet dot ibm dot com
- Cc: gcc-patches at gcc dot gnu dot org, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Date: Tue, 11 Apr 2017 10:11:27 +0200
- Subject: Re: [PATCH] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.
- Authentication-results: sourceware.org; auth=none
- References: <20170410213706.C67D7D83143@oc3748833570.ibm.com>
On 04/10/2017 11:37 PM, Ulrich Weigand wrote:
> Dominik Vogt wrote:
>
>> So, we could add a special case for const0_rtx that generates the
>> LT pattern and does not rely on Combine, and get rid of the
>> peephole. I'm not sure this is worthwhile thoug, because the
>> peephole has other beneficial effects (as discussed), and until
>> we've solved the problems preventing Combine from merging L+LTR in
>> some cases, this is the best we have. What do you think?
>
> If we removed the peephole (for now), the patch now only touches
> parts of the backend used to emit atomic instructions, so code
> generation for any code that doesn't use those is guaranteed to
> be unchanged. Given that we're quite late in the cycle, this
> might be a good idea at this point ...
>
> But I don't see anything actually incorrect in the peephole, and
> it might indeed be a good thing in general -- just maybe more
> appropriate for the next stage1.
>
> Andreas, do you have an opinion on this?
Yes, the change is unrelated to the rest of the patch and therefore should go into a separate patch.
But I'm fine with applying both right now.
The peephole surprisingly often helped code generation. There appear to be plenty of cases where
the L+LTR combination could not be handled otherwise. Dominik reviewed the speccpu diffs and there
were only improvements.
-Andreas-