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]

rtl generation and life time problem for bitfields


Hi,

I've found two problems and could need some help to fix them correctly.

gcc currently aborts for the following example on m68k:

typedef union {
        unsigned all                    :8;
        struct {
                unsigned cod            :1;
                unsigned io             :1;
                unsigned reserved       :6;
        } b;
} idetape_ireason_reg_t;

int f(void);
void f1(int x)
{
        idetape_ireason_reg_t i;
        i.all = x;
        if (i.b.cod)
                f();
}


It's an extracted example from the linux kernel.

This example shows two problems:

1. Life time information for such structures hold in registers is wrong.
We don't know when is the first time the variable is really used, so
that it lives from the beginning of the function. This has two
consequences:
a) Multiple such virtual registers get a separate hard register
assigned, even if less are needed.
b) More serious is the problem, that if such a register is only used in
a single basic block and it's optimized away, update_life_info will
abort because "Register died unexpectedly", where the register actually
was never live at the beginning.

2. Contrary to 2.95 3.x isn't using a simple move to initialize i.all
anymore, which triggers above problem and the abort. That means "struct
{ int a:8; }" and "struct { char a; }" are not handled the same. What
I'm seeing is that store_bit_field() is called with the same arguments
except fieldmode, which is VOIDmode for bitfields. Note that this
problem isn't m68k specific, e.g. on i386 a series of and/ior
instruction is used, but which are mostly optimized away during the
combine pass. m68k now uses a bitfield instruction here, which is not
that easily optimized away. I checked ppc and it avoids bitfield
instructions in many cases possibly because of this reason.
BTW I played with other sizes for "all", and for values between 17 and
24 the value is forced on the stack, anyone has an idea why?

It would be great if someone could help me a bit on how/where to solve
these problems. The first problem is IMO the more important one, as it
can cause random failures, depending on how the code is optimized.

bye, Roman


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