Mehdi Amini via llvm-dev
2016-Jan-04 20:53 UTC
[llvm-dev] Can someone give me some pointer on alias analysis ?
> On Jan 4, 2016, at 9:55 AM, Amaury SECHET via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > 2016-01-04 18:21 GMT+01:00 Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>>: > On 01/04/2016 07:32 AM, Amaury SECHET wrote: >> After a bit more investigation, it turns out that because %0 is stored into %1 (after bitcast) and so %3 may have access to it and clobber it. > Can you give a bit more context? I'm not sure which of the examples you're talking about. > > > Sure. Let's look at http://pastebin.com/K0J9yGq1 <http://pastebin.com/K0J9yGq1> > > Because of the store line 7, it is assumed that the call line 8 may see %0 and even modify the memory it points to. As a result, it is assumed that the load line 11 may not be eliminated. > > Which seems actually correct in the general case. > > >> >> After a bit of thought, it is correct in the general case, but definitively something stricter is needed here. Looking at inaccessiblememonly I'm not sure this is what is needed. What if the memory allocator is defined is the current module ? > At the moment, inaccessiblememonly would require separate compilation of the allocation function. >> >> This leads me to conclude this is way more linked to the memory allocation pass than I expected it to be in the first place. Can I ask what you plan to use inaccessiblememonly for ? Should the semantic be refined to fit the bill better ? > Well, I didn't introduce the attribute, so I can't speak for the original intent. For me, I plan on applying it to some of our out of line allocation functions and other helper routines which modify runtime state, but not java visible state. > > If you have specific suggestions for how to refine the semantics, please make them. Getting the details right is always the hard part. :) > > You might also consider using a variant of your allocation function which takes a pointer to the global state it needs to modify. Doing this would allow you to use argmemonly to restrict the aliasing while still allowing whole program optimization. I haven't tried this in practice, but it seems like it would probably work... > > I do not wish to make suggestion before I understand where this is coming from. So far, from what I've collected, use cases are: > - Memory allocation > - Runtime isolation for managed languages. > > I have some more though to put into this, but to boot, would that be possible to only use this attribute on method that are declared, but not defined and remove it when merging modules ? It doesn't look like it is necessary to have it when the function may be exposed depending on the way the software is built.We can imagine a function defined in the current module, that does not modify any global, but calls malloc. Could it be inferred the argmemonly? — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160104/3659c94c/attachment.html>
Mehdi Amini via llvm-dev
2016-Jan-04 20:54 UTC
[llvm-dev] Can someone give me some pointer on alias analysis ?
> On Jan 4, 2016, at 12:53 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Jan 4, 2016, at 9:55 AM, Amaury SECHET via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> 2016-01-04 18:21 GMT+01:00 Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>>: >> On 01/04/2016 07:32 AM, Amaury SECHET wrote: >>> After a bit more investigation, it turns out that because %0 is stored into %1 (after bitcast) and so %3 may have access to it and clobber it. >> Can you give a bit more context? I'm not sure which of the examples you're talking about. >> >> >> Sure. Let's look at http://pastebin.com/K0J9yGq1 <http://pastebin.com/K0J9yGq1> >> >> Because of the store line 7, it is assumed that the call line 8 may see %0 and even modify the memory it points to. As a result, it is assumed that the load line 11 may not be eliminated. >> >> Which seems actually correct in the general case. >> >> >>> >>> After a bit of thought, it is correct in the general case, but definitively something stricter is needed here. Looking at inaccessiblememonly I'm not sure this is what is needed. What if the memory allocator is defined is the current module ? >> At the moment, inaccessiblememonly would require separate compilation of the allocation function. >>> >>> This leads me to conclude this is way more linked to the memory allocation pass than I expected it to be in the first place. Can I ask what you plan to use inaccessiblememonly for ? Should the semantic be refined to fit the bill better ? >> Well, I didn't introduce the attribute, so I can't speak for the original intent. For me, I plan on applying it to some of our out of line allocation functions and other helper routines which modify runtime state, but not java visible state. >> >> If you have specific suggestions for how to refine the semantics, please make them. Getting the details right is always the hard part. :) >> >> You might also consider using a variant of your allocation function which takes a pointer to the global state it needs to modify. Doing this would allow you to use argmemonly to restrict the aliasing while still allowing whole program optimization. I haven't tried this in practice, but it seems like it would probably work... >> >> I do not wish to make suggestion before I understand where this is coming from. So far, from what I've collected, use cases are: >> - Memory allocation >> - Runtime isolation for managed languages. >> >> I have some more though to put into this, but to boot, would that be possible to only use this attribute on method that are declared, but not defined and remove it when merging modules ? It doesn't look like it is necessary to have it when the function may be exposed depending on the way the software is built. > > We can imagine a function defined in the current module, that does not modify any global, but calls malloc. Could it be inferred the argmemonly?I meant inaccessiblememonly instead of argmemonly… — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160104/ea514280/attachment.html>
Amaury SECHET via llvm-dev
2016-Jan-04 21:30 UTC
[llvm-dev] Can someone give me some pointer on alias analysis ?
Can't the GlobalsAA pass figure that out without requiring the annotation ? 2016-01-04 21:54 GMT+01:00 Mehdi Amini <mehdi.amini at apple.com>:> > On Jan 4, 2016, at 12:53 PM, Mehdi Amini via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > On Jan 4, 2016, at 9:55 AM, Amaury SECHET via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 2016-01-04 18:21 GMT+01:00 Philip Reames <listmail at philipreames.com>: > >> On 01/04/2016 07:32 AM, Amaury SECHET wrote: >> >> After a bit more investigation, it turns out that because %0 is stored >> into %1 (after bitcast) and so %3 may have access to it and clobber it. >> >> Can you give a bit more context? I'm not sure which of the examples >> you're talking about. >> >> > Sure. Let's look at http://pastebin.com/K0J9yGq1 > > Because of the store line 7, it is assumed that the call line 8 may see %0 > and even modify the memory it points to. As a result, it is assumed that > the load line 11 may not be eliminated. > > Which seems actually correct in the general case. > > >> >> After a bit of thought, it is correct in the general case, but >> definitively something stricter is needed here. Looking at >> inaccessiblememonly I'm not sure this is what is needed. What if the >> memory allocator is defined is the current module ? >> >> At the moment, inaccessiblememonly would require separate compilation of >> the allocation function. >> >> >> This leads me to conclude this is way more linked to the memory >> allocation pass than I expected it to be in the first place. Can I ask what >> you plan to use inaccessiblememonly for ? Should the semantic be refined >> to fit the bill better ? >> >> Well, I didn't introduce the attribute, so I can't speak for the original >> intent. For me, I plan on applying it to some of our out of line >> allocation functions and other helper routines which modify runtime state, >> but not java visible state. >> >> If you have specific suggestions for how to refine the semantics, please >> make them. Getting the details right is always the hard part. :) >> >> You might also consider using a variant of your allocation function which >> takes a pointer to the global state it needs to modify. Doing this would >> allow you to use argmemonly to restrict the aliasing while still allowing >> whole program optimization. I haven't tried this in practice, but it seems >> like it would probably work... >> > > I do not wish to make suggestion before I understand where this is coming > from. So far, from what I've collected, use cases are: > - Memory allocation > - Runtime isolation for managed languages. > > I have some more though to put into this, but to boot, would that be > possible to only use this attribute on method that are declared, but not > defined and remove it when merging modules ? It doesn't look like it is > necessary to have it when the function may be exposed depending on the way > the software is built. > > > We can imagine a function defined in the current module, that does not > modify any global, but calls malloc. Could it be inferred the argmemonly? > > > I meant inaccessiblememonly instead of argmemonly… > > — > Mehdi > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160104/cfccc93c/attachment.html>
Philip Reames via llvm-dev
2016-Jan-04 22:24 UTC
[llvm-dev] Can someone give me some pointer on alias analysis ?
On 01/04/2016 12:54 PM, Mehdi Amini via llvm-dev wrote:> >> On Jan 4, 2016, at 12:53 PM, Mehdi Amini via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >>> >>> On Jan 4, 2016, at 9:55 AM, Amaury SECHET via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> >>> >>> 2016-01-04 18:21 GMT+01:00 Philip Reames<listmail at philipreames.com >>> <mailto:listmail at philipreames.com>>: >>> >>> On 01/04/2016 07:32 AM, Amaury SECHET wrote: >>>> After a bit more investigation, it turns out that because %0 is >>>> stored into %1 (after bitcast) and so %3 may have access to it >>>> and clobber it. >>> Can you give a bit more context? I'm not sure which of the >>> examples you're talking about. >>> >>> >>> Sure. Let's look athttp://pastebin.com/K0J9yGq1 >>> >>> Because of the store line 7, it is assumed that the call line 8 may >>> see %0 and even modify the memory it points to. As a result, it is >>> assumed that the load line 11 may not be eliminated. >>> >>> Which seems actually correct in the general case. >>> >>> >>>> >>>> After a bit of thought, it is correct in the general case, but >>>> definitively something stricter is needed here. Looking >>>> atinaccessiblememonlyI'm not sure this is what is needed. What >>>> if the memory allocator is defined is the current module ? >>> At the moment, inaccessiblememonly would require separate >>> compilation of the allocation function. >>>> >>>> This leads me to conclude this is way more linked to the memory >>>> allocation pass than I expected it to be in the first place. >>>> Can I ask what you plan to useinaccessiblememonlyfor ? Should >>>> the semantic be refined to fit the bill better ? >>> Well, I didn't introduce the attribute, so I can't speak for the >>> original intent. For me, I plan on applying it to some of our >>> out of line allocation functions and other helper routines which >>> modify runtime state, but not java visible state. >>> >>> If you have specific suggestions for how to refine the >>> semantics, please make them. Getting the details right is always >>> the hard part. :) >>> >>> You might also consider using a variant of your allocation >>> function which takes a pointer to the global state it needs to >>> modify. Doing this would allow you to use argmemonly to >>> restrict the aliasing while still allowing whole program >>> optimization. I haven't tried this in practice, but it seems >>> like it would probably work... >>> >>> >>> I do not wish to make suggestion before I understand where this is >>> coming from. So far, from what I've collected, use cases are: >>> - Memory allocation >>> - Runtime isolation for managed languages. >>> >>> I have some more though to put into this, but to boot, would that be >>> possible to only use this attribute on method that are declared, but >>> not defined and remove it when merging modules ? It doesn't look >>> like it is necessary to have it when the function may be exposed >>> depending on the way the software is built. >> >> We can imagine a function defined in the current module, that does >> not modify any global, but calls malloc. Could it be inferred the >> argmemonly? > > I meant inaccessiblememonly instead of argmemonly…I believe that it should be yes. (If we had malloc marked as inaccessiblememonly which we don't currently.)> > — > Mehdi > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160104/26a88f73/attachment.html>