[M3devel] convert vs. cast in parse.c?

[Jay K]

I don't know.
I'm not too concerned with float/loophole at the moment.
 Granted, probably a good way is take address, cast to new pointer type, deref -- you know, the "safe" load/store pattern. 
  "view convert" sounds like it might be equivalent but more efficient (ie: not introduce pessimization associated with address-taken).
 
 
I agree though, now that you mention it, sounds useful.
 
 
My more immediate concern is 1) the min/max change I made, though that seems clearly to preserve preexisting semantics 2) changes to let configure -enable-checking to work. Many of the errors around operations that mix integer types, in comparison, assignment, plus, multiply, etc.
 
 
 
 >  (i.e., bits are compatible, no extension necessary, etc.).
 
 
What would qualify there?
I can think of only a few:
   signed to/from unsigned, of same size 
   pointer to/from integer, of same size (loophole) 
   possibly loophole, of same size (e.g. int32 <=> float, int64 <=> double, heck float or double <=> pointer) 
   enum <=> integer, of same size 
   and NOT anything involving a change in size 
   possibly, like boolean <=> int8/uint8, if boolean is 8 bits 
 
 
 - Jay

 


Subject: Re: convert vs. cast in parse.c?
From: hosking at cs.purdue.edu
Date: Mon, 13 Sep 2010 16:22:11 -0400
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


m3_cast uses a NOP_EXPR, which assumes no code needs generating to effect the type change (i.e., bits are compatible, no extension necessary, etc.).
convert is provided to perform all reasonable conversions.  It generates code as necessary (see comments below from c-convert.c).
Looking at the comments for VIEW_CONVERT_EXPR, I wonder if we should be using that for LOOPHOLE on floats to avoid the need for the temporary?
I'm not sure we should ever be using CONVERT_EXPR explicitly — probably better to use convert and get the CONVERT_EXPR from that as necessary?







/* Change of width--truncation and extension of integers or reals--
   is represented with NOP_EXPR.  Proper functioning of many things
   assumes that no other conversions can be NOP_EXPRs.


   Conversion between integer and pointer is represented with CONVERT_EXPR.
   Converting integer to real uses FLOAT_EXPR
   and real to integer uses FIX_TRUNC_EXPR.


   Here is a list of all the functions that assume that widening and
   narrowing is always done with a NOP_EXPR:
     In convert.c, convert_to_integer.
     In c-typeck.c, build_binary_op (boolean ops), and
c_common_truthvalue_conversion.
     In expr.c: expand_expr, for operands of a MULT_EXPR.
     In fold-const.c: fold.
     In tree.c: get_narrower and get_unwidened.  */

/* Subroutines of `convert'.  */




/* Create an expression whose value is that of EXPR,
   converted to type TYPE.  The TREE_TYPE of the value
   is always TYPE.  This function implements all reasonable
   conversions; callers should filter out those that are
   not permitted by the language being compiled.  */


tree
convert (tree type, tree expr)




Also:


NOP_EXPR
These nodes are used to represent conversions that do not require any code-generation. For example, conversion of a char* to an int* does not require any code be generated; such a conversion is represented by a NOP_EXPR. The single operand is the expression to be converted. The conversion from a pointer to a reference is also represented with a NOP_EXPR. 

CONVERT_EXPR
These nodes are similar to NOP_EXPRs, but are used in those situations where code may need to be generated. For example, if an int* is converted to an intcode may need to be generated on some platforms. These nodes are never used for C++-specific conversions, like conversions between pointers to different classes in an inheritance hierarchy. Any adjustments that need to be made in such cases are always indicated explicitly. Similarly, a user-defined conversion is never represented by a CONVERT_EXPR; instead, the function calls are made explicit. 

FIXED_CONVERT_EXPR
These nodes are used to represent conversions that involve fixed-point values. For example, from a fixed-point value to another fixed-point value, from an integer to a fixed-point value, from a fixed-point value to an integer, from a floating-point value to a fixed-point value, or from a fixed-point value to a floating-point value. 






Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On 13 Sep 2010, at 06:31, Jay K wrote:


Tony, et. al. can you help me understand when in parse.c to use "convert" vs. "cast"?

Thanks,
 - Jay




    

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100914/4dc6f7fd/attachment-0002.html>