[PATCH] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.

Andreas Krebbel krebbel@linux.vnet.ibm.com
Tue Apr 11 08:11:00 GMT 2017


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-



More information about the Gcc-patches mailing list