This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about mem_set_list in propagate_block_info
- From: fnf at intrinsity dot com (Fred Fish)
- To: drow at mvista dot com (Daniel Jacobowitz)
- Cc: fnf at intrinsity dot com (Fred Fish),rth at redhat dot com (Richard Henderson),dnovillo at redhat dot com (Diego Novillo),gcc at gcc dot gnu dot org (gcc at gcc dot gnu dot org)
- Date: Wed, 4 Jun 2003 10:21:42 -0500 (CDT)
- Subject: Re: Question about mem_set_list in propagate_block_info
- Reply-to: fnf at intrinsity dot com
> It's not really what you want to do either. That's probably more
> likely to commit the variable to memory than is strictly necessary.
> Something like
> union matrix_t { int m __attribute__((__mode__(V16SI))); int x[16]; };
I probably should have mentioned that we no longer use that ugly macro
and now use:
static inline int
MatrixElement(matrix_t a, int row, int col)
{
union {
matrix_t matrix;
int elements[4][4];
} u;
u.matrix = a;
return (u.elements[row][col]);
}
however the problem was noted back when we used the macro so I decided
to try to get to the bottom of it, in case there actually was a
compiler bug. If the consensus is that the code is illegal, then I'm
fine with that.
As a matter of curiosity though I'd still be interested in knowing
more about when memory references are supposed to be removed from the
mem_set_list per my original email.
-Fred