Re: A potential bug in lra-constraints.c for special_memory_constraint?

[David Miller <davem at davemloft dot net>]

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Wed, 12 Jul 2017 01:19:03 +0200

>> we add this new constraint as:
>> 
>> ;; We need a special memory constraint for the misaligned memory access
>> ;; This is only for TARGET_MISALIGN target
>> (define_special_memory_constraint "B"
>>  "Memory reference whose address is misaligned"
>>  (and (match_code "mem")
>>       (match_test "TARGET_MISALIGN")
>>       (match_test "memory_is_misaligned (op, mode)”)))
>> 
>> the routine “memory_is_misaligned” is a compile-time check to see whether
>> the address is known to be misaligned or not. only for compile-time KNOWN
>> misaligned memory access, we will use misaligned load/store insns provided
>> by the new processor for the memory access.
>> 
>> and then put this new constraints to sparc.md as:
>> 
>> (define_insn "*movdi_insn_sp64"
>>   [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,r, B, m,
>> r,*e,?*e,?*e,?W,b,b") (match_operand:DI 1 "input_operand"       
>> "rI,N,B,m,rJ,rJ,*e, r, *e,  W,*e,J,P"))]
>> 
>> 
>> NOTE, the 4th constraints for this insn is “B, rJ”,  if the operands match
>> this constraint, then.  misaligned store insns will be generated for the
>> misaligned memory access instead of regular store.
> 
> OK, but what happens in the end?  What's the failure mode?  Internal compiler 
> error, impossible reloading, wrong code, suboptimal code, etc?

Yeah I'm still hopelessly confused what the problem is too.

As far as I understand it, the unaligned loads and stores present in
the M8 can be used just fine on aligned data.  It's just not efficient
(11 cycle latency instead of 3).

Perhaps they are just trying to only match the constraints for the
the unaligned loads and stores when absolutely necessary.

If so, I really really wish they had said this from the beginning. :)