This is the mail archive of the
mailing list for the GCC project.
Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 20 Mar 2013 16:29:11 +0100 (CET)
- Subject: Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
- References: <alpine dot DEB dot 2 dot 02 dot 1303191627200 dot 4515 at stedding dot saclay dot inria dot fr> <5148D1FC dot 7000708 at redhat dot com> <alpine dot DEB dot 2 dot 02 dot 1303192309130 dot 3872 at laptop-mg dot saclay dot inria dot fr> <5149D216 dot 4090109 at redhat dot com>
On Wed, 20 Mar 2013, Richard Henderson wrote:
On 03/20/2013 08:00 AM, Marc Glisse wrote:
Do you at least agree that vector-vector subregs make sense, or is that part
wrong as well?
You mean a V4SImode subreg of a V8SImode register, not just same-size casting?
I am mostly interested in the reverse, a paradoxical subreg, since
vec_select can only model one direction (and only rvalues, but that's a
It makes logical sense, but I'm fairly sure you'll need a lot more surgery
throughout the compiler to make that happen.
I'm curious how a define_expand can fail in LRA, but your define_insn succeeds?
I think it is related to that REG_P protected code, and the
reload_complete test. With the define_insn_and_split, we keep the insn
until after reload and only do the subreg magic then. With a
define_expand, we end up writing to reg 60 as a V2DF and reading it as a
V4DF, and since it isn't a hard register, that causes a problem.
Is the failure because of ix86_cannot_change_mode_class? Because that hook
fairly well defines what subregs are valid. And if that says it isn't valid,
then even having a define_insn that uses such is wrong.
A quick look at ix86_cannot_change_mode_class seems to indicate that it
does not mind such paradoxical subregs.