This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: subreg fixing (extract_bit_field or simplify_subreg)
- From: Richard Henderson <rth at redhat dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 28 Oct 2004 11:03:57 -0700
- Subject: Re: RFC: subreg fixing (extract_bit_field or simplify_subreg)
- References: <20041028175321.GA1438@redhat.com>
On Thu, Oct 28, 2004 at 01:53:21PM -0400, Aldy Hernandez wrote:
> Yay. More subreg stupidity.
>
> On the following testcase, we call extract_bit_field trying to extract
> a DF out of a memory block:
>
> struct __attribute__ ((packed)) W { double l; } sW;
> double dd;
> testW () { dd = sW.l; }
>
> We first call operand_subword with wordnum=1, and somewhere down the call
> chain, simplify_gen_subreg calls simplify_subreg, which returns 0.
> This causes simplify_gen_subreg to force creation of the subreg
> with gen_rtx_SUBREG.
>
> ...this creates invalid rtl: (subreg:SI (reg:DF 118) 4).
>
> What is advisable?
>
> Would it be ok to modify simplify_gen_subreg to return NULL_RTX for
> class incompatabilities, or is the problem further up? (Obviously,
> I'd have to change operand_subword to operand_subword_force).
The problem is farther up. In places, I know it's broken all
the way back up to extract_bit_field.
> On a similar note, invalid rtl keeps biting my butt, and has for about
> 5 years. Would be ok to add checks in gen_rtx_SUBREG to abort on
> invalid RTL (hard coding the common cases)
I thought about doing this when I was debugging the problem
yesterday and was frightened by how often I expect it will
trigger. *sigh* I suppose it really is necessary. Do it.
This is gonna be really ugly...
r~