[RFC] SFTs on complex type

[Andrew Pinski <pinskia at physics dot uc dot edu>]

While looking at PR 25513 and PR 24365, I noticed that we did not have 
SFTs
on complex type.  This patch implements SFTs on complex types with a 
very
simple patch.  It "steals" part of Richard Guenther's patch for SFT for 
arrays.
The part which is required to move away from dependent on SFT are only 
on fields.

Should I split Richard's patch from mine and submit that separate?

The only complex thing in my patch is the patch to var_can_have_subvars
as we can have both complex types which are gimple registers (which has
a SSA_NAME associated with it).  If we just say all variables can have
subvars, we get an ICE in tree-complex.c lowering the arithmetic as we
don't create a SSA_NAME for those variables even though we should have.

OK for the mainline?  Tested on x86_64-linux-gnu with no regressions.

Thanks,
Andrew Pinski

ChangeLog:
2005-12-29  Richard Guenther  <rguenther@suse.de>

	* tree-flow.h (struct fieldoff): Use separate type and offset
	field instead of storing FIELD_DECL in field.
	* tree-ssa-alias.c (create_sft): We now take field type as
	2nd argument.
	(create_overlap_variables_for): Adjust for field now
	storing field type.
	* tree-ssa-structalias.c (create_variable_info_for): Likewise.
	(fieldoff_compare): Likewise.
	(push_fields_onto_fieldstack): Likewise.

2005-12-29  Andrew Pinski  <pinskia@physics.uc.edu>

	* tree-ssa-alias.c (find_used_portions): Handle REALPART_EXPR
	and IMAGPART_EXPR.
	* tree-flow-inline.h (var_can_have_subvars): Handle complex types
	on non gimple variables.
	* tree-ssa-structalias.c (push_fields_onto_fieldstack): Handle
	complex types.
	* tree-ssa-operands.c (parse_ssa_operands): Handle REALPART_EXPR
	and IMAGPART_EXPR for creating MUST_DEFs.

Attachment: SFTcomplex.diff.txt
Description: Text document