Re: [PATCH] Fix PR rtl-optimization/23585 (delay slots)

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> 1) When would it be important for may_trap_p and may_trap_or_fault_p
>    to return different values?  On a strict alignment machine, a
>    misaligned access is always going to trap.  Why do we need a
>    separate may_trap_or_fault_p function to test for that?  Why can't
>    we test for it in may_trap_p?

Because:
1. AFAIK you're allowed to put MEM_NOTRAP_P on any stack slot, misaligned or 
not.
2. You want to eliminate these misaligned accesses to stack slots, even if 
-fnon-call-exceptions.

> 2) The comment for SPARC_STACK_BOUNDARY_HACK in function.c says that
>    it is temporary, although it has been there for two years now.

Ask Geoff about the "temporary".  AFAIK no SPARC maintainer has made any 
commitment about it, although it would of course be desirable to rework the 
whole approach of the stack bias.

>    The comment in sparc.h says that SPARC_STACK_BOUNDARY_HACK is only used
>    in function.c.  For reference:
>        http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00526.html
>    If we're not going to fix this problem, then at the very least we
>    need to update those comments.

Agreed.

Thanks for looking at this.

-- 
Eric Botcazou