So the core problem was my "restore multiple" insn contained a CALL insn
and was a call_insn. The symbol it called is in the static section of
libgcc. However, during peephole2 pass, get_call_reg_set_usage in
final.c didn't find a function declaration attached to the symbol and so
defaulted to
It would probably be useful to post the actual code. The below function
emit_msabi_outlined_restore() is is called from ix86_expand_epilogue()
to emit the RTL to call the restore stub. Like ix86_expand_epilogue, it
uses style == 0 to indicate that there will be a sibling call following
the
On 10/16/2016 05:27 PM, Segher Boessenkool wrote:
Oddly enough, I had forgotten to call add_function_usage_to() on my save
stub (which I didn't post), but not the restore stub. So thanks for that
psychic intervention. :) But if you look carefully, it's there, although
it's hard to read because
On Sun, Oct 16, 2016 at 05:05:17PM -0500, Daniel Santos wrote:
> >>The insn that's getting deleted is 75, where RCX is set. I'm starting
> >>to think that maybe df_analyze() presumes that my call (to the stub) is
> >>invalidating RCX, although it does not.
> >It looks like you don't use
On 10/15/2016 08:41 PM, Segher Boessenkool wrote:
Hi Daniel,
On Sat, Oct 15, 2016 at 01:45:12AM -0500, Daniel Santos wrote:
The insn that's getting deleted is 75, where RCX is set. I'm starting
to think that maybe df_analyze() presumes that my call (to the stub) is
invalidating RCX, although
Hi Daniel,
On Sat, Oct 15, 2016 at 01:45:12AM -0500, Daniel Santos wrote:
> The insn that's getting deleted is 75, where RCX is set. I'm starting
> to think that maybe df_analyze() presumes that my call (to the stub) is
> invalidating RCX, although it does not.
It looks like you don't use
I'm working on my -foutline-masbi-xlouges optimization (targeting 64 bit
Wine) and I've run into a snag with sibling calls. When
-foutline-masbi-xlouges is disabled, the sibling call generates just
fine. But when enabled the call to df_analyze() in the peephole2 pass
deletes the insn that
