This is the mail archive of the gcc@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: RFC: subreg fixing (extract_bit_field or simplify_subreg)


On Thu, Oct 28, 2004 at 09:10:00PM -0700, Richard Henderson wrote:
> On Thu, Oct 28, 2004 at 08:22:52PM -0400, Aldy Hernandez wrote:
> > Argh.... Are you looking into this (the extract_bit_field problem)?
> > If not, any pointers on where to look to fix this?
> 
> Not until I have a test case.  The ones that we had before should
> be gone due to emit_group_load/store changes.

Testcase previously in thread, but never mind that...

I see what el problemo is.

The structure is packed, hence it calls for byte alignment.  To access the 
DF in it, expand_expr_real_1 decides to call extract_bit_field to piece
the DF from the bytes in the structure.

extract_bit_field reads the individual bytes, pieces them together into
two words, and tries to put each of these words into the target with
subregs.  Remember that the target is a DF, so we end up with invalid rtl:

	(insn 25 24 26 (set (subreg:SI (reg:DF 118 [ D.1368 ]) 4) ...))
	...
	(insn 40 39 0 (set (subreg:SI (reg:DF 118 [ D.1368 ]) 0) ...))

#ifdef __VERBOSE
The code generated here is wrong for all PPC variants (possibly
other targets).  In my case, death occurs when we do register allocation, 
get a hard register for the DF, and then try to resolve the subreg.

The reason this invalid rtl works on classic with soft-float, is because
a DF spans two registers, so when we get a hard reg for the DF, the
subreg resolves into one of the individual registers.

The reason this invalid rtl works on classic with hard-regs, is because
reload takes care of dumping this to memory.  SECONDARY_MEMORY_NEEDED
specifies that copying between FLOAT_REGS and any other type requires
memory.  This trick doesn't work for e500v2, because float values go
in GENERAL_REGS, so there's no incompatible class move.
#endif

extract_bit_field should be smart enough to do the above magic into a DI, 
then copy it into the target (DF).

Are we in agreement?  If so, I can come up with a patch.

I also saw other problems out of the corner of my eye, but I'll ignore
those for now.

Aldy


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