This is the mail archive of the 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]
Other format: [Raw text]

Re: Strange RTL

> > The RTL generated for the assignment is the following (this is from the
> > .00.rtl dump, Pmode=PDI):
> >
> > (insn 10 5 15 (set (subreg:PDI (reg/v:DI 107) 0)
> >         (const_int 123 [0x7b])) -1 (nil)
> >     (nil))
> >
> > So, my question is: why does the subreg come into play here?
> Well, the union/struct is small enough, so only a pseudo is allocated for
> it (of DImode size) as backing storage.  Because it's a union, it could
> contain other members (which ultimately could result also in different
> modes for that pseudo, think about a float also being member).  But the
> pseudo itself only has one mode, DImode in this case.  To access the real

The reason that I bring this up is that it only happens in a few cases,
such as the case above (which did originally have other members, but
probably did still fit in 64-bits).  I just need to teach my code
generator to handle subregs on the destination side of a set expression.

The really ugly part of this, however is that the above set turns into the
following RTL when converted to SSA:

(insn 10 24 15 (sequence[
            (set (reg/v:DI 107)
                (reg:DI 109))
            (set (subreg:PDI (reg/v:DI 107) 0)
                (const_int 123 [0x7b]))
        ] ) -1 (nil)

Of course this basically breaks the single assignment property of SSA, and
means I'll have to introduce special hacks to handle this. :(

So my currently plan is to add code to specifically match this case.
Is anyone aware of a simpler way to stop this code from being generated in
the first place though?  Where would I look to implement the optimization
of not generating these in the first place?

Thanks for the help!


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