Hi,
On Fri, 22 Nov 2013, Xinliang David Li wrote:
> > Apart from the issue that LTO drops all BLOCKs this makes the middle-end
> > feature too much tied to the C family frontends and their definition
> > of restrict. It also requires BLOCK lookup / matching at the time
> > of the alias query (wh
On Fri, 22 Nov 2013, Xinliang David Li wrote:
> On Fri, Nov 22, 2013 at 2:19 AM, Richard Biener wrote:
> > On Thu, 21 Nov 2013, Xinliang David Li wrote:
> >
> >> On Thu, Nov 21, 2013 at 10:03 AM, Michael Matz wrote:
> >> > Hello,
> >> >
> >> > after much pondering about the issue we came up with
On Thu, 21 Nov 2013, Michael Matz wrote:
> Hello,
>
> after much pondering about the issue we came up with this design to
> handle restrict more generally. Without a completely different way of
> representing conflicts (or non-conflicts) of memory references we're bound
> to somehow encode th
Michael Matz wrote:
after much pondering about the issue we came up with this design to
handle restrict more generally.
Cool! Thanks for the last-minute patch.
If I understand the patch correctly, it does handle the problem of
inlining restrict pointers correctly – which was previously a
mis
On Fri, Nov 22, 2013 at 2:19 AM, Richard Biener wrote:
> On Thu, 21 Nov 2013, Xinliang David Li wrote:
>
>> On Thu, Nov 21, 2013 at 10:03 AM, Michael Matz wrote:
>> > Hello,
>> >
>> > after much pondering about the issue we came up with this design to
>> > handle restrict more generally. Without
On Thu, 21 Nov 2013, Xinliang David Li wrote:
> On Thu, Nov 21, 2013 at 10:03 AM, Michael Matz wrote:
> > Hello,
> >
> > after much pondering about the issue we came up with this design to
> > handle restrict more generally. Without a completely different way of
> > representing conflicts (or no
On Thu, Nov 21, 2013 at 10:03 AM, Michael Matz wrote:
> Hello,
>
> after much pondering about the issue we came up with this design to
> handle restrict more generally. Without a completely different way of
> representing conflicts (or non-conflicts) of memory references we're bound
> to somehow
Michael,
Thanks for working to improve this feature.
I think that testing on a few more targets would be advisable because
other targets may expose problems caused by the effects of
optimizations exposed by better "restrict" implementation.
Thanks, David
Hello,
after much pondering about the issue we came up with this design to
handle restrict more generally. Without a completely different way of
representing conflicts (or non-conflicts) of memory references we're bound
to somehow encode the necessary information into the points-to set (or in
