This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: A potential bug in lra-constraints.c for special_memory_constraint?
> the problem I had is:
>
> 1. we added a new special_memory_constraint for misaligned memory access,
> one important requirement for this new special_memory_constraint is, the
> address of the memory access is misaligned.
OK, it's the other way around from the usage of special_memory_constraint.
In other words, I'm not sure that you really need to use it in this case,
a standard memory_constraint could be sufficient.
> 2. per the current code in lra-constraints.c:
>
> 2286 case CT_SPECIAL_MEMORY:
> 2287 if (MEM_P (op)
> 2288 && satisfies_memory_constraint_p (op, cn))
> 2289 win = true;
> 2290 else if (spilled_pseudo_p (op))
> 2291 win = true;
> 2292 break;
>
> if the op is a pseudo_p that can be spilled, then it's treated as a
> PERFECT MATCH.
>
> the issue only can be exposed by the following kind of RTL:
>
> (insn 34 13 14 2 (set (reg:DI 122)
> (reg:DI 129)) misalign-3.c:12 125 {*movdi_insn_sp64}
> (nil))
>
> i.e.
> (1). REG2 move to REG1
> and. (2). REG2 is a virtual reg (> the max hard regno, on Sparc, its 103),
> therefore, must be spilled to stack.
>
> the current interpretation of special memory treat such REG2 as a perfect
> match to special memory, and then spill it.
> however, such spilled memory RTL is NOT match the MISALIGN requirement,
> (i.e, the address of the memory access for the spilled RTL is not
> misaligned)
Yes, spilling will automatically meet alignment requirements, that's why it's
allowed for special_memory_constraint.
Why do you absolutely need to have a misaligned address? Can't you just avert
your eyes and pretend that the address is misaligned? This will be suboptimal
but presumably work. To be honest, I'm not even sure that you really need an
additional constraint, but I haven't investigated the subject seriously.
--
Eric Botcazou