RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers

[Jeff Law]

On 05/26/2016 10:16 AM, Nick Clifton wrote:
> Hi Jeff,
>
>>>> I may be missing something, but isn't it the transition to an FP
>>>> relative address rather than a SP relative address that's the problem
>>>> here?
>>>
>>> Yes, I believe so.
>>>
>>>> Where does that happen?
>
> I think that it happens in dwarf2out.c:based_loc_descr()  which
> detects the use of the frame pointer and works out that it is going
> to be eliminated to the stack pointer:
>
>   /* We only use "frame base" when we're sure we're talking about the
>      post-prologue local stack frame.  We do this by *not* running
>      register elimination until this point, and recognizing the special
>      argument pointer and soft frame pointer rtx's.  */
>   if (reg == arg_pointer_rtx || reg == frame_pointer_rtx)
>     {
>       rtx elim = (ira_use_lra_p
> 		  ? lra_eliminate_regs (reg, VOIDmode, NULL_RTX)
> 		  : eliminate_regs (reg, VOIDmode, NULL_RTX));
>
>       if (elim != reg)
>         .....
>
> The problem, I believe, is that based_loc_descr() is only called
> from mem_loc_descriptor when the mode of the rtl concerned is an
> MODE_INT.  For example:
>
>     case REG:
>       if (GET_MODE_CLASS (mode) != MODE_INT
> 	 [...]
>       else
>       if (REGNO (rtl) < FIRST_PSEUDO_REGISTER)
> 	mem_loc_result = based_loc_descr (rtl, 0, VAR_INIT_STATUS_INITIALIZED);
>
> or, (this is another one that I found whilst investigating this
> problem further):
>
>   case PLUS:
>     plus:
>       if (is_based_loc (rtl)
> 	  && (GET_MODE_SIZE (mode) <= DWARF2_ADDR_SIZE
> 	      || XEXP (rtl, 0) == arg_pointer_rtx
> 	      || XEXP (rtl, 0) == frame_pointer_rtx)
> 	  && GET_MODE_CLASS (mode) == MODE_INT)
> 	mem_loc_result = based_loc_descr (XEXP (rtl, 0),
> 					  INTVAL (XEXP (rtl, 1)),
> 					  VAR_INIT_STATUS_INITIALIZED);
>       else
>
>
> There are quite a few places in mem_loc_descriptor where the code checks
> for the mode being in the MODE_INT class.  I am not exactly sure why.  I
> think that it might be that the programmer thought that any expression that
> does not involve integer based arithmetic cannot be expressed in DWARF CFA
> notation and so would have to be handled specially.  If I am correct,
> then it seems to me that the proper fix would be to use SCALAR_INT_MODE_P
> instead.
>
> I tried out the extended patch (attached) and it gave even better GDB
> results for the MSP430 and still no regressions (GCC or GDB) for MSP430 or
> x86_64.
>
> Is this enough justification ?
So the argument is that MODE_INT was likely intended to filter out 
things like FP modes and such that might somehow be bogusly used as 
addresses.  As written those tests are also filtering out partial 
integer modes which we can support?

And that many (most?) of the things that filter on MODE_INT should 
really be using MODE_INT || MODE_PARTIAL_INT (aka SCALAR_INT_MODE_P).

I can buy that ;-)   OK with a suitable ChangeLog entry.

jeff