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

[Qing Zhao]

> On Jul 11, 2017, at 4:24 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> 
>> we need to generate misaligned load/store insns ONLY for misaligned memory
>> access, therefore need a new constraints for misaligned address.
> 
> Why?  What happens exactly if the memory access turns out to be aligned?

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. 

misaligned insns will NOT be used for memory access whose alignment cannot be decided to be misaligned during compilation time.

Hope this is clear.  If I still don’t answer your question, please let me know.

Qing
 

> 
> -- 
> Eric Botcazou