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]

In Search Of The One True Zero.


L.S.,

A couple of weeks ago I submitted (and got approval for) a patch to
optabs.c that would enable optimization of Complex OP Real constructs.

The gist of the comparison to zero in this patch is:

           && part == CONST0_RTX (submode));

However, it turns out that `part' always is a (pseudo-) register, never
CONST0_RTX (some mode).

What the Fortran Frontend does is this:

/* A rip-off of gcc's convert.c convert_to_complex function,
   ...  */

static tree
ffecom_convert_to_complex_ (tree type, tree expr)
{
  register enum tree_code form = TREE_CODE (TREE_TYPE (expr));
  tree subtype;

  assert (TREE_CODE (type) == RECORD_TYPE);

  subtype = TREE_TYPE (TYPE_FIELDS (type));

  if (form == REAL_TYPE || form == INTEGER_TYPE || form ==
ENUMERAL_TYPE)
    {                                                                    
      expr = convert (subtype, expr);
      return ffecom_2 (COMPLEX_EXPR, type, expr,
                       convert (subtype, integer_zero_node));

i.e., it uses convert (REAL_TYPE, integer_zero_node) as the imaginary
part of a REAL_TYPE converted to complex.

I tried to determine why `convert (REAL_TYPE, integer_zero_node)' didn't
get converted to something using CONST0_RTX, but quickly lost track.

Where does the conversion to rtx nodes take place ?

Thanks in advance,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)


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