On Thu, 26 Mar 2015, Jakub Jelinek wrote:
> On Thu, Mar 26, 2015 at 10:32:18AM +0100, Richard Biener wrote:
> > I think I simply didn't want to change more testcases at that point,
> > but I can't see how followup passes at the very point wouldn't
> > clean things up very quickly (via fre or copyp
On Thu, Mar 26, 2015 at 10:32:18AM +0100, Richard Biener wrote:
> I think I simply didn't want to change more testcases at that point,
> but I can't see how followup passes at the very point wouldn't
> clean things up very quickly (via fre or copyprop). Eventually
> it was -Og and pass_fold_builti
On Thu, 26 Mar 2015, Jakub Jelinek wrote:
> On Thu, Mar 26, 2015 at 09:33:56AM +0100, Richard Biener wrote:
> > this hunk which I think is not really necessary given that
> > the late object-size pass now runs right before FRE which
>
> Not really immediately before that, but a few passes appart.
On Thu, Mar 26, 2015 at 09:33:56AM +0100, Richard Biener wrote:
> this hunk which I think is not really necessary given that
> the late object-size pass now runs right before FRE which
Not really immediately before that, but a few passes appart.
And in the -Og case, while the immediately next pass
On Wed, 25 Mar 2015, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, fixing this issue for real (make sure we at least
> until the objsz pass don't lose information on which field's address if any
> has been taken) is probably too dangerous at this point, so this patch
> just adds a simple
Hi!
As discussed in the PR, fixing this issue for real (make sure we at least
until the objsz pass don't lose information on which field's address if any
has been taken) is probably too dangerous at this point, so this patch
just adds a simple workaround:
another objsz pass instance run early befo
