This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] Cleanup DW_CFA_GNU_args_size handling


This is related primarily to PR49864 but also to PR49879.

The fundamental problem in the first test case is that the
AVR target cannot perform

   (set (stack-pointer-rtx)
	(plus (stack-pointer-rtx) (const_int large)))

where "large" is in fact really quite small.  This gets
dutifully reloaded to

   (set (reg temp) (stack-pointer-rtx))

   (set (reg temp) (plus (reg temp) (const_int large)))

   (set (stack-pointer-rtx) (reg temp))

which, we have to admit, is perfectly reasonable.

The code that we had in stack_adjust_offset would not
properly handle anything except immediate addends to
the stack pointer.  Indeed, if it saw any other sort
of stack pointer adjustment, it gave up and assumed 
that we'd reset the args_size level to 0.

This exact problem hasn't shown up on other targets
either (1) because they ACCUMULATE_OUTGOING_ARGS, or
(2) while they may not be able to handle very large
addends to the stack pointer, we usually don't let
the pushed arguments grow to very large numbers; we
regularly reduce stack_pointer_delta.

AVR is special in that it can't *really* perform any
direct addition to the stack pointer at all; "large"
is non-zero only because of a peephole pattern to use
pop insns into a scratch register for small adjustments.

I briefly considered adding an insn pattern that would
handle the entire mov/add/mov thing with a scratch, so
that we wouldn't have to do anything special.  It seemed
relatively unlikely that any other port would be this
severely limited.

However, then came a look at the second PR, where we
performed cross-jumping between two blocks with different
args_size values.

For the specific case of the PR, this "merely" resulted
in wrong-debug, because we would in fact generate invalid
unwind info for one of the two paths.

That said, I see no reason why this same cross-jump could
not occur with a real throw as opposed to an abort.  And
in that case we would have wrong-code.

I consulted the IRC oracle, and Ian didn't have any 
objections in principal to a new reg-note.

Comments?


r~

Attachment: d-args-size-1
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]