> On Jul 11, 2017, at 2:00 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>
>> 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.
A standard memory_constraint has the same handling on spilled code as
special_memory_constraint:
2250 case CT_MEMORY:
2251 if (MEM_P (op)
2252 && satisfies_memory_constraint_p (op, cn))
2253 win = true;
2254 else if (spilled_pseudo_p (op))
2255 win = true;
as a result, if the new misaligned memory access was defined as a standard
memory_constraint, will have the same issue.
>
>> 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.
You mean, even for the mis-alignment requirement, the spilled memory access
will met the mis-alignment?
>
> Why do you absolutely need to have a misaligned address?
we need to generate misaligned load/store insns ONLY for misaligned memory
access, therefore need a new
constraints for misaligned address.
As I checked the GCC source code, the special_memory_constraints only were
defined in i386 and sparc target, not
used quite often.
Qing
> 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
