> I think re-test is just waste of cycles, as you know cfa_base_rtx is
> arg_pointer_rtx on both x86_64 and i686 (it is frame_pointer_rtx only on
> pa, vax and rx). IMHO just testing if var-tracking still compiles without
> warnings ought to be enough.
Alright, quickstrapped and guality-regtested
On Mon, May 30, 2011 at 01:16:13PM +0200, Eric Botcazou wrote:
> > This should be cfa_base_rtx instead of arg_pointer_rtx, or the condition
> > should test that cfa_base_rtx == arg_pointer_rtx. We don't have a dynamic
> > stack realignment target which defines FRAME_POINTER_CFA_OFFSET right now,
>
> This should be cfa_base_rtx instead of arg_pointer_rtx, or the condition
> should test that cfa_base_rtx == arg_pointer_rtx. We don't have a dynamic
> stack realignment target which defines FRAME_POINTER_CFA_OFFSET right now,
> but what if one day such target is added or just dynamic realignment
On 05/30/2011 09:54 AM, Alexandre Oliva wrote:
> On May 29, 2011, Eric Botcazou wrote:
>
>> * var-tracking.c (vt_add_function_parameter): Remap incoming MEMs with
>> crtl-> args.internal_arg_pointer based address to arg_pointer_rtx if
>> there is a DRAP register.
>> (vt_init_
On May 29, 2011, Eric Botcazou wrote:
> * var-tracking.c (vt_add_function_parameter): Remap incoming MEMs with
> crtl-> args.internal_arg_pointer based address to arg_pointer_rtx if
> there is a DRAP register.
> (vt_init_cfa_base): Don't equate cfa_base_rtx if stack was re
On Sun, May 29, 2011 at 10:57:34AM +0200, Eric Botcazou wrote:
> --- var-tracking.c(revision 174377)
> +++ var-tracking.c(working copy)
> @@ -8398,6 +8398,27 @@ vt_add_function_parameter (tree parm)
>if (GET_MODE (decl_rtl) == BLKmode || GET_MODE (incoming) == BLKmode)
> return;
>
> Here is an alternative, almost completely untested, patch, which
> uses DW_OP_fbreg for the arguments of dynamically realigned functions.
> draptest.c now works...
I've attached a slightly revamped, IMO easier to understand version. Stack
realignment with DRAP is quite seldom on the mainline
> So, would you like me to redo my patch on top of your patch, test it and
> submit?
I'll take care of that.
> If you think it makes the code clearer, the extra comparison for at most
> each stmt in the prologue_bb is probably noise compile time wise.
No doubt about that. Plus this may save the
On Tue, May 24, 2011 at 01:42:11PM +0200, Eric Botcazou wrote:
> > That is so that the argp (or framep) will be properly handled during
> > CSELIB, as constant VALUE that is never changed through the function. And
> > additionally to find out if we can do the replacement (we can't if argp
> > resp
> That is so that the argp (or framep) will be properly handled during
> CSELIB, as constant VALUE that is never changed through the function. And
> additionally to find out if we can do the replacement (we can't if argp
> resp. framep isn't eliminated and could therefore occur in the real code).
On Tue, May 24, 2011 at 12:59:57PM +0200, Eric Botcazou wrote:
> Now on to a few questions:
>
> > 2011-05-23 Jakub Jelinek
> >
> > * var-tracking.c (vt_add_function_parameter): Remap incoming
> > MEMs with crtl->args.internal_arg_pointer based address
> > if stack_realign_drap to ar
> Here is an alternative, almost completely untested, patch, which
> uses DW_OP_fbreg for the arguments of dynamically realigned functions.
> draptest.c now works...
Thanks for the tip. I completely overlooked this CFA-based machinery and now
agree that it's the most sensible approach. For my
On Mon, May 23, 2011 at 11:33:42AM +0200, Eric Botcazou wrote:
> > Anyway, IMHO the desired outcome is that the
> > parameters will have DW_OP_fbreg {0,4} as their location, so perhaps the
> > DRAP register needs to be remapped somehow during adjust_insn.
>
> So you don't care about their locatio
On Mon, May 23, 2011 at 11:33:42AM +0200, Eric Botcazou wrote:
> > Do you mean something like the attached one? We don't have guality
> > testsuite for ada and I think ada testcases are quite unreadable for most
> > people. Definitely to me. Plus it is always better to have a single
> > file tes
> Do you mean something like the attached one? We don't have guality
> testsuite for ada and I think ada testcases are quite unreadable for most
> people. Definitely to me. Plus it is always better to have a single
> file testcase over 5 files.
Sure. Last time I mentioned the guality testsuite
On Sun, May 22, 2011 at 10:51:30PM +0200, Eric Botcazou wrote:
> var-tracking doesn't fully work with dynamic stack realignment on x86 when a
> DRAP register is used for a function: the value of the incoming parameters is
> very quickly wrong (as soon as the DRAP register is clobbered), in partic
var-tracking doesn't fully work with dynamic stack realignment on x86 when a
DRAP register is used for a function: the value of the incoming parameters is
very quickly wrong (as soon as the DRAP register is clobbered), in particular
in backtraces. The reason is that var-tracking doesn't track pa
17 matches
Mail list logo
