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]

Re: store_bit_field, CONCATs and subregs


OK, I'll try the alternative that you suggested, but for the record:

Richard Henderson <rth@redhat.com> writes:
>> 	* rtlhooks.c (gen_lowpart_general): Handle CONCATs.
>
> This part I don't think is correct.  We often use the result of
> gen_lowpart as an lvalue,
>
>> +       emit_move_insn (gen_lowpart_common (GET_MODE (x), tmp), x);
>
> ... as you do yourself.  Therefore creating a new pseudo for tmp
> is incorrect.

I was using gen_lowpart_common as an lvalue, not gen_lowpart_general.
The distinction was deliberate.

To repeat a comment I tend to associate with Jim Wilson,
gen_lowpart(_general) isn't guaranteed to return an lvalue.
For example (perhaps the only example?), the MEM case includes:

      /* The following exposes the use of "x" to CSE.  */
      if (GET_MODE_SIZE (GET_MODE (x)) <= UNITS_PER_WORD
	  && SCALAR_INT_MODE_P (GET_MODE (x))
	  && TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode),
				    GET_MODE_BITSIZE (GET_MODE (x)))
	  && ! no_new_pseudos)
	return gen_lowpart_general (mode, force_reg (GET_MODE (x), x));

That's why I thought this approach might be acceptable.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]