Re: Regression due to tree loop opt / expand weirdness

[Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>]

Richard Henderson wrote:

> I can't imagine except that would break things when you *do*
> want to use "typedef void *ptr32 __attribute__((mode(SI)));".

What do you think would break?  I assume you're talking about
s390x, not ia64 (as on ia64 there wouldn't be any difference).

The intended use of SImode pointers on s390x is *not* to hold
machine addresses in the current addressing mode.  Instead,
it is intended to simplify writing code that interfaces to
code running in another addressing mode (think something like
the 32-bit system call compatibility layer in the Linux kernel).
[ This tends to occur more frequently in TPF than in Linux,
which is why the TPF folks requested that feature.  ]

You want to declare variables and data structures holding 31-bit
pointers, so that you can easily access the data pointed to 
from within GCC-generated 64-bit code.  

So writing 

  typedef int *ptr32 __attribute__ ((mode (SI)));
  
  ptr32 p;
  use (*p);

should generate code equivalent to

  typedef int ptr32;

  ptr32 p;
  use (*(int *)(size_t)(p & 0x7fffffff));

except it is easier to write and provides additional type checks.


It is not really required that 64-bit code like

  ptr32 p;
  int i;

  p = &i;

does something sensible (it ususally cannot as &i isn't representible
in 32-bit) or is implemented efficiently.  However, even *if* you
want this to work by storing the truncated pointer value, it does
work just fine with my patch.  In fact, *without* my patch this
test case ICEs currently.
 

So the way things used to work (all address arithmetic performed in
DImode) was just fine for the intended use of mode((SI)) pointers
on s390x.

Or, to put it another way, IMO valid_pointer_mode should be a pure
front-end issue, providing syntactic sugar to simplify writing cross-
mode code, but should not change anything w.r.t. code generation
or the back end.  (B.t.w. it appears valid_pointer_mode isn't
actually documented anywhere :-/)

In the mean time bootstrap and regression tests have finished 
succesfully for the patch below on s390-ibm-linux and s390x-ibm-linux.

If you still don't like it, I'd appreciate any suggestions how to
fix the current problems ...

Thanks,
Ulrich



ChangeLog:

	* expr.c (expand_expr_addr_expr): Only accept Pmode or ptr_mode
	as valid modes to expand address expressions.

Index: gcc/expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.725
diff -c -p -r1.725 expr.c
*** gcc/expr.c	28 Sep 2004 22:54:57 -0000	1.725
--- gcc/expr.c	3 Oct 2004 20:16:29 -0000
*************** expand_expr_addr_expr (tree exp, rtx tar
*** 6201,6207 ****
    /* We can get called with some Weird Things if the user does silliness
       like "(short) &a".  In that case, convert_memory_address won't do
       the right thing, so ignore the given target mode.  */
!   if (!targetm.valid_pointer_mode (tmode))
      tmode = Pmode;
  
    result = expand_expr_addr_expr_1 (TREE_OPERAND (exp, 0), target,
--- 6201,6207 ----
    /* We can get called with some Weird Things if the user does silliness
       like "(short) &a".  In that case, convert_memory_address won't do
       the right thing, so ignore the given target mode.  */
!   if (tmode != Pmode && tmode != ptr_mode)
      tmode = Pmode;
  
    result = expand_expr_addr_expr_1 (TREE_OPERAND (exp, 0), target,


-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de