This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix gen_lowpart_for_combine (PR rtl-optimization/92510)
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 27 Nov 2019 13:14:02 -0600
- Subject: Re: [PATCH] Fix gen_lowpart_for_combine (PR rtl-optimization/92510)
- References: <20191126235135.GN10088@tucnak> <20191127012043.GF9491@gate.crashing.org> <20191127090310.GP10088@tucnak>
On Wed, Nov 27, 2019 at 10:03:10AM +0100, Jakub Jelinek wrote:
> and it is just combine subst + simplification that turns it into
> ... (subreg:DI (subreg:V1DI (ne:DI (reg:CCZ 17 flags) (const_int 0 [0])) 0) 0) ...
> The restriction that subreg must be of a reg or mem certainly isn't honored
> in debug_insns (there subregs can be of anything that has
> non-VOIDmode/BLKmode).
debug_insns aren't valid RTL often :-(
> Though, just grepping the backends, there are tons
> of cases where the *.md files have subregs of other rtxes (though as I said,
> this is not the case of this testcase, there it is created only during
> substing):
[ snip ]
Wow, lots of it. That's not good. Most of these should use truncate
instead.
> config/arm/iwmmxt.md: (subreg:V8QI (ashiftrt:TI
But there *is* no rtx code for this?
> config/msp430/msp430.md: (subreg:PSI (zero_extend:SI (match_operand:HI 1 "general_operand" "0,r")) 0))]
There doesn't sesem to be a way to write this conversion, either.
> config/sparc/sparc.md: (and:DI (subreg:DI (lshiftrt:SI (match_operand:SI 1 "register_operand" "r")
zero_extend
> > > gen_lowpart_for_combine turns that into (ne:V1DI (reg:CC flags) (const_int 0))
> > > which looks wrong to me,
> >
> > Why would that be wrong?
>
> Because (reg:CC flags) (const_int 0) comparison computes a scalar (boolean),
> not a vector, for vector comparisons I think we only allow say:
> (ne:V1DI (reg:V1DI ...) (reg:V1DI ...)) or const_vector as the other
> operand.
Yeah okay, I see.
> Sure, V1*mode vectors are weird vectors, but still are vectors.
> If we talk about V4DImode, it should be clearer that something that produces
> a scalar can't have vector mode.
It's still not clear to me that
(ne:V1DI (reg:CC flags) (const_int 0))
produces a scalar: it explicitly produces a vector, instead! But it's
not clear what the semantics are, sure. Pity that it isn't documented.
Segher