This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Another NaT bit propagation bug.
- To: amacleod at cygnus dot com
- Subject: Re: Another NaT bit propagation bug.
- From: Richard Henderson <rth at redhat dot com>
- Date: Thu, 8 Nov 2001 17:51:48 -0800
- Cc: gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <200111071413.fA7EDlZ14316@simba.cygnus.com>
On Wed, Nov 07, 2001 at 06:13:47AM -0800, amacleod@cygnus.com wrote:
> The simplest way to handle this is to look for any registers which
> are live on entry to the function, check to see if their first use is
> in a zero_extract or subreg expression, and if so, set them to 0 immediately
> following the prologue. Since this is specific to ia64, I've put the
> code into ia64_reorg.
I don't think this is really ia64 specific. Well, the NaT death
is, but not the general problem. Consider
idefloppy_bcount_reg_t xxx(void)
{
idefloppy_bcount_reg_t bcount;
bcount.all = 0;
bcount.b.high = get_char[0];
bcount.b.low = get_char[1];
return bcount;
}
On Alpha, we get
# $1 has get_char[0]; $3 has get_char[1]; $2 is undefined.
zapnot $2,12,$2
sll $1,8,$1
bis $2,$1,$2
bis $2,$3,$2
stl $2,0($16)
I.e. we do see the unnecessary masking. Contrast this with
union {
int x;
idefloppy_bcount_reg_t bcount;
} u;
u.x = 0;
u.bcount.all = 0;
u.bcount.b.high = get_char[0];
u.bcount.b.low = get_char[1];
# $1 has get_char[0]; $2 has get_char[1].
sll $1,8,$1
bis $1,$2,$1
stl $1,0($16)
It would be nice to handle this in a generic fashion before
combine, so that combine can simplify the masking.
r~