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
