| Message ID | CAFULd4Y+XxWA5WEgLvYZd5KqDp732k2sbKbA+haOsy=U6gw8+g@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 07/13/2015 11:03 AM, Uros Bizjak wrote: > This is rtl-optimization part of a two-part patch series. > > As discussed in the PR, we have to prcompute register parameters > before stack alignment is performed, otherwise eventual call to > __tls_get_addr can be called with unaligned stack. When compiling the > testcase from the PR, anti_adjust_stack is called just before > precompute starts expanding function parameters. > > The solution is to move precomputation before stack pointer is adjusted. > > 2015-07-13 Uros Bizjak <ubizjak@gmail.com> > > PR rtl-optimization/58066 > * calls.c (expand_call): Precompute register parameters before stack > alignment is performed. > > Patch was bootstrapped and regression tested on x86_64-linux-gnu > {,-m32} for all default languages, obj-c++ and go. > > OK for mainline? OK once a comment is added indicating why we have to precompute before the anti-adjust-stack. jeff
On Tue, Jul 14, 2015 at 6:46 AM, Jeff Law <law@redhat.com> wrote: > On 07/13/2015 11:03 AM, Uros Bizjak wrote: >> >> This is rtl-optimization part of a two-part patch series. >> >> As discussed in the PR, we have to prcompute register parameters >> before stack alignment is performed, otherwise eventual call to >> __tls_get_addr can be called with unaligned stack. When compiling the >> testcase from the PR, anti_adjust_stack is called just before >> precompute starts expanding function parameters. >> >> The solution is to move precomputation before stack pointer is adjusted. >> >> 2015-07-13 Uros Bizjak <ubizjak@gmail.com> >> >> PR rtl-optimization/58066 >> * calls.c (expand_call): Precompute register parameters before stack >> alignment is performed. >> >> Patch was bootstrapped and regression tested on x86_64-linux-gnu >> {,-m32} for all default languages, obj-c++ and go. >> >> OK for mainline? > > OK once a comment is added indicating why we have to precompute before the > anti-adjust-stack. Thanks, I have committed the patch with following comment: + /* Precompute all register parameters. It isn't safe to compute + anything once we have started filling any specific hard regs. + TLS symbols sometimes need a call to resolve. Precompute + register parameters before any stack pointer manipulation + to avoid unaligned stack in the called function. */ Uros.
Index: calls.c =================================================================== --- calls.c (revision 225727) +++ calls.c (working copy) @@ -3144,6 +3144,10 @@ expand_call (tree exp, rtx target, int ignore) compute_argument_addresses (args, argblock, num_actuals); + /* Precompute all register parameters. It isn't safe to compute anything + once we have started filling any specific hard regs. */ + precompute_register_parameters (num_actuals, args, ®_parm_seen); + /* Perform stack alignment before the first push (the last arg). */ if (argblock == 0 && adjusted_args_size.constant > reg_parm_stack_space @@ -3184,10 +3188,6 @@ expand_call (tree exp, rtx target, int ignore) funexp = rtx_for_function_call (fndecl, addr); - /* Precompute all register parameters. It isn't safe to compute anything - once we have started filling any specific hard regs. */ - precompute_register_parameters (num_actuals, args, ®_parm_seen); - if (CALL_EXPR_STATIC_CHAIN (exp)) static_chain_value = expand_normal (CALL_EXPR_STATIC_CHAIN (exp)); else
This is rtl-optimization part of a two-part patch series. As discussed in the PR, we have to prcompute register parameters before stack alignment is performed, otherwise eventual call to __tls_get_addr can be called with unaligned stack. When compiling the testcase from the PR, anti_adjust_stack is called just before precompute starts expanding function parameters. The solution is to move precomputation before stack pointer is adjusted. 2015-07-13 Uros Bizjak <ubizjak@gmail.com> PR rtl-optimization/58066 * calls.c (expand_call): Precompute register parameters before stack alignment is performed. Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32} for all default languages, obj-c++ and go. OK for mainline? Uros.