This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 17/12/15 17:27, Segher Boessenkool wrote:
On Thu, Dec 17, 2015 at 05:12:16PM +0100, Bernd Schmidt wrote:On 12/17/2015 05:10 PM, Kyrill Tkachov wrote:Well, this patch still produces the QImode comparison if the target has a QImode comparison (the have_insn_for check in the simplify_comparison hunk).Ok, I didn't look that closely because I had doubts about the approach. This kind of check also goes somewhat against the principles of just producing canonical forms of RTL.The canonicalisation rules exist so that optimisers only need to match one form instead of several, and machine descriptions only need to describe one form instead of several. For this bitmasking case it perversely forces you to describe the same instruction in many ways, for many targets. This is what the change_zero_ext was about as well. It's not so easy to fix for the compare case. Maybe the idea of making genrecog make code that recognises more forms of the same insn will work out. GCC 7 in any case...
Perhaps I had underestimated how involved this issue is :) So if I want to improve the aarch64 situation for GCC 6, would the recommended course of action be to just define the QI and HImode compare against zero patterns? Note that I think the make_extraction hunk from my patch is in line with the function comment of make_extraction that says: " IN_COMPARE is nonzero if we are in a COMPARE. This means that a ZERO_EXTRACT should be built even for bits starting at bit 0." whereas the condition that I'm adding "&& !in_compare" is explicitly trying to avoid an extraction. But anyway, if this has the potential to cause negative fallout that I had not anticipated, it can wait for later. Thanks, Kyrill
Segher
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |