This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] (another one) Fix PR33870, PTA and partitoning interaction

On 10/24/07, Richard Guenther <> wrote:
> On Wed, 24 Oct 2007, Daniel Berlin wrote:
> > On 10/24/07, Richard Guenther <> wrote:
> > >
> > > So, as opposed to the earlier patch which papered over one specific case
> > > of the problem (which is that alias partitioning rips apart SFTs belonging
> > > to the same parent variable), this is a hammer that really solves it
> > > but at a cost (maybe, to be investigated).
> > >
> > > IMHO the operand scanning part of accesses through pointers is fragile
> > > in that it requires that the full set of SFTs that possibly are addressed
> > > by the pointer is available together as aliases of a symbol.
> >
> > Actually, it only requires that the points-to sets be correct :)
> But we don't use the points-to set.  We use the aliased bitmap.

Feel free to keep the ptset around for 4.3 (i think we already do),
and just use that.
I'd happily approve that.

> > > Another possible "fix" for PR33870 would be to force memory partitioning
> > > to either never put SFTs into MPTs or if an SFT goes into a MPT also
> > > add all other SFTs belonging to its parent variable.  Of course this
> > > perverts memory partition heuristics and effectively makes SFTs
> > > useless (unless doing option one which makes one point of MPTs, reduced
> > > number of VOPs moot).
> >
> > This is the right option.  We have other constraints on partitioning
> > to make it correct.  This is just another one.
> Which one?  I gave two options.

The "don't split SFT's between partitions".

At the point that we make MPT's, we've *already* given up on getting
really accurate info, so putting more things into the partition
doesn't really hurt us.
> > Alternatively, i'd rather remove SFT's entirely and force our
> > optimizers to start doing what they should (use more than just
> > vdefs/vuses) than I would go back to lying about what the points-to
> > sets are.
> I sort of agree.  But certainly not for 4.3.  We need a fix for the
> wrong-code problem and I didn't see you doing anything constructive
> here apart from very fast ditching my proposed "solutions".

The problem with moving back tot he model we moved away from is it
will raise exactly the same bugs we worked around in 4.2 in very ugly
ways about making sure all the parts of the structure get into the
points-to set when doing address taking of fields (remember the
set_union_with_increment patches, etc).

You seem to be driving this bug, so i didn't want to start
interrupting you other than feedback.
If you want me to take it over, i'm happy to, but it will be a while
before i can get to it.

> > I just went through a lot of trouble to stop making PTA lie about what
> > is being pointed to.
> Well, it happens that set_uids_in_ptset computes the points-to solution,
> so I should have touched compute_flow_sensitive_aliasing instead.  But
> let me guess - you wouldn't like that one either.

> Well, I'm off this problem now and leave this to obviosly more intelligent
> people like you.

Dude, i'm not sure what is up with you, i'm simply giving you feedback
on ways to fix this problem that aren't going to lead us back to the
same bugs we already fixed!

I've given you 3 possible solutions so far that i'd happil accept.

1. Have partitioning stop splitting SFT's among partitions
2. Use pt_set for 4.3 instead of aliases during operand scanning.
3. Stop TBAA pruning pt sets for 4.3.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]