https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #10 from Stupachenko Evgeny <evstupac at gmail dot com> --- (In reply to Uroš Bizjak from comment #9) > (In reply to Stupachenko Evgeny from comment #8) > > (In reply to Uroš Bizjak from comment #7) > > > The difference si that the call to f128_p3 does not expand with "use > > > (reg:SI > > > bx)" tag in the Darwin case. Probably ix86_expand_call should be fixed for > > > TARGET_MACHO > > > > Darwin generates indirect access throw generated section: .symbol_stub. > > They don't use EBX in the call even without any changes (relaxing EBX > > usage). > > I guess that the mentioned "use" in the call is what keeps PIC register live > accross push in the non-Darwin case. Not sure I understand Darwin features correct, but they push shifted esp to calls: (objdump of example for PR63618) 00000d20 <_f128_square>: d20: 56 push %esi d21: 83 ec 18 sub $0x18,%esp d24: 66 0f 6f 44 24 30 movdqa 0x30(%esp),%xmm0 d2a: 89 e0 mov %esp,%eax d2c: 83 ec 2c sub $0x2c,%esp d2f: 8b 74 24 4c mov 0x4c(%esp),%esi d33: 0f 11 44 24 1c movups %xmm0,0x1c(%esp) d38: 0f 11 44 24 0c movups %xmm0,0xc(%esp) d3d: 50 push %eax d3e: e8 f9 00 00 00 call e3c <___multf3$stub> d43: 89 f0 mov %esi,%eax d45: 66 0f 6f 4c 24 2c movdqa 0x2c(%esp),%xmm1 d4b: 0f 29 0e movaps %xmm1,(%esi) d4e: 83 c4 44 add $0x44,%esp d51: 5e pop %esi d52: c2 04 00 ret $0x4 Anyway, if call is not EBX dependent (say local call in Linux) the issue is not reproduced (like in example from PR63618). So the issue looks like Darwin dependent RA issue.
