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: Fix PR/14084

On Thu, 2004-02-19 at 06:38, Josef Zlomek wrote:
> IMHO that would not work for struct of 2 SImode elements in DImode register.
> We do not want to change REG_OFFSET in this case, that's why there are
> conditions regarding the size of mode and decl in my patch.

I don't see why checking to make sure we stay inside the bounds of the
decl is necessary.  The compiler should never try to use a subreg to
reference something outside the decl, so if the incoming offsets are
correct, and we manipulate them correctly, then we should never generate
an offset outside the object.

However, I would not be surprised if there are problems with the offsets
here, either in REG_OFFSET, or in SUBREG_BYTE.  It is easy to get these
offsets wrong, and there is probably no code to make consistency checks
on them.  Since these values are used in the alias code, it is important
for them to be right.  We shouldn't be ignoring incorrect REG_OFFSET

I don't see how your example could be a problem.  For a struct of two
SImode elements in a DImode register, the REG_EXPR would have to point
to the entire structure.  Otherwise, the REG_EXPR would be wrong.  When
we extract out either SImode element, we add the appropriate memory
offset 0 or 4.

I do see that my suggested algorithm doesn't work though.  It converts a
reg-offset of 4 to a mem-offset of 0 which is right, but it converts a
reg-offset of 0 to a mem-offset of -4 which is wrong.  So the algorithm
needs a little more thought here, but I don't think this invalidates my
Jim Wilson, GNU Tools Support,

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