>
> The debug info on your testcase looks as expected (though,
> we really don't emit the DW_OP_GNU_parameter_ref for aggregates anyway
> - not sure if we could do something about those at least in the easy cases
> where the argument used to be stored into the struct shortly before the
> call.
Co
On Thu, Dec 17, 2015 at 10:10:48PM +0100, Jan Hubicka wrote:
> here is better testcase that also trigger splitting
> struct a {int a;int b;};
The debug info on your testcase looks as expected (though,
we really don't emit the DW_OP_GNU_parameter_ref for aggregates anyway
- not sure if we could do
> Jakub,
> thanks a lot for looking into this! I am now bit on tight schedule moving back
> to Prague and I knew little about the implementation of debug info for
> optimized out arguments.
Hi,
here is better testcase that also trigger splitting
struct a {int a;int b;};
inline
static int reta (str
Jakub,
thanks a lot for looking into this! I am now bit on tight schedule moving back
to Prague and I knew little about the implementation of debug info for
optimized out arguments.
>
> Ok, so here is a WIP patch changing the functions you wanted, untested so
> far.
>
> I've been looking at 3 tes
On Wed, Dec 16, 2015 at 08:15:12PM +0100, Jan Hubicka wrote:
> just to summarize a discussion on IRC. The problem is that we produce debug
> statements for eliminated arguments only in ipa-sra and ipa-split, while we
> don't do anything for cgraph clones. This is a problem on release branches,
> to
Hi,
just to summarize a discussion on IRC. The problem is that we produce debug
statements for eliminated arguments only in ipa-sra and ipa-split, while we
don't do anything for cgraph clones. This is a problem on release branches,
too.
It seems we have all the necessary logic, but the callee modi
On Wed, Dec 16, 2015 at 06:15:33PM +0100, Jan Hubicka wrote:
> > On Wed, Dec 16, 2015 at 05:24:25PM +0100, Jan Hubicka wrote:
> > > I am trying to understand Jakub's debug code and perhaps it can be
> > > improved. But in
> > > the case of optimized out unused parameters I think it is perfectly
>
> On Wed, Dec 16, 2015 at 05:24:25PM +0100, Jan Hubicka wrote:
> > I am trying to understand Jakub's debug code and perhaps it can be
> > improved. But in
> > the case of optimized out unused parameters I think it is perfectly
> > resonable to
> > say that the variable was optimized out.
>
> As
On Wed, Dec 16, 2015 at 05:24:25PM +0100, Jan Hubicka wrote:
> I am trying to understand Jakub's debug code and perhaps it can be improved.
> But in
> the case of optimized out unused parameters I think it is perfectly resonable
> to
> say that the variable was optimized out.
As long as the valu
> On Thu, Dec 10, 2015 at 08:30:37AM +0100, Jan Hubicka wrote:
> > * ipa-cp.c (ipcp_cloning_candidate_p): Use node->optimize_for_size_p.
> > (good_cloning_opportunity_p): Likewise.
> > (gather_context_independent_values): Do not return true when
> > polymorphic call context is known
On Wed, Dec 16, 2015 at 10:59:10AM +0100, Richard Biener wrote:
> Same on x86_64 btw. If there isn't a bugreport already please open
> one to track this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68935
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
On Wed, Dec 16, 2015 at 10:59:10AM +0100, Richard Biener wrote:
> > What can I do to help fixing this?
>
> Same on x86_64 btw. If there isn't a bugreport already please open
> one to track this issue.
PR68860 covers this already and it has been discussed on this ml too
already.
Jakub
On Wed, Dec 16, 2015 at 10:15 AM, Dominik Vogt wrote:
> On Thu, Dec 10, 2015 at 08:30:37AM +0100, Jan Hubicka wrote:
>> * ipa-cp.c (ipcp_cloning_candidate_p): Use node->optimize_for_size_p.
>> (good_cloning_opportunity_p): Likewise.
>> (gather_context_independent_values): Do not
On Thu, Dec 10, 2015 at 08:30:37AM +0100, Jan Hubicka wrote:
> * ipa-cp.c (ipcp_cloning_candidate_p): Use node->optimize_for_size_p.
> (good_cloning_opportunity_p): Likewise.
> (gather_context_independent_values): Do not return true when
> polymorphic call context is known o
Hi,
On Fri, Dec 11, 2015 at 10:20:20PM +0100, Jan Hubicka wrote:
> Actually I added
> if (!ipa_is_param_used (info, i))
>
> continue;
>
> shortcut to gather_context_independent_v
Actually I added
if (!ipa_is_param_used (info, i))
continue;
shortcut to gather_context_independent_values which prevents
us from recording context_independent_aggregate_values for
> On Thu, Dec 10, 2015 at 08:30:37AM +0100, Jan Hubicka wrote:
> > I am bootstrapping/regtesting this on x86_64-linux, does it seem OK?
>
> I think this patch (just a guess, but certainly ipa-cp related during last
> 24 hours) significantly regressed guality/pr36728-*.c on x86_64.
> Previously we
On Thu, Dec 10, 2015 at 08:30:37AM +0100, Jan Hubicka wrote:
> I am bootstrapping/regtesting this on x86_64-linux, does it seem OK?
I think this patch (just a guess, but certainly ipa-cp related during last
24 hours) significantly regressed guality/pr36728-*.c on x86_64.
Previously we have not tur
On Thu, Dec 10, 2015 at 05:56:26PM +0100, Jan Hubicka wrote:
> > Is this really necessary, is it not enough to remove the assignment to
> > ret below? If the parameter is not used, devirtualization time bonus,
> > which you then rely on estimate_local_effects, should be zero for it.
> >
> > It is
> Is this really necessary, is it not enough to remove the assignment to
> ret below? If the parameter is not used, devirtualization time bonus,
> which you then rely on estimate_local_effects, should be zero for it.
>
> It is a very minor point, I suppose, but if the function gets cloned
> for a
Hi,
thanks for looking into this, I only have one question:
On Thu, Dec 10, 2015 at 08:30:37AM +0100, Jan Hubicka wrote:
> Martin,
> while looking into the ipa-cp dumps for bzip and Firefox I noticed few issues.
> First of all, ipcp_cloning_candidate_p calls
> optimize_function_for_speed_p (DECL
21 matches
Mail list logo