thr3ads.net - llvm dev - [llvm-dev] LLVM Alias Analysis Technical Call

If this information is useful, please help other people find it:
Share via:

Finkel, Hal J. via llvm-dev

2020-May-21 16:15 UTC

[llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll

Great, thanks!

Are you planning on just talking about these things with slides? Do we have
other things to which we can link for people to read?

-Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

________________________________
From: Tarique Islam <tislam at ca.ibm.com>
Sent: Thursday, May 21, 2020 8:19:31 AM
To: Finkel, Hal J. <hfinkel at anl.gov>
Cc: Alina Sbirlea <alina.sbirlea at gmail.com>; Doerfert, Johannes
<jdoerfert at anl.gov>; Jeroen Dobbelaere <Jeroen.Dobbelaere at
synopsys.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
Subject: RE: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll

Hi Hal,

Thanks very much for scheduling the LLVM Alias Analysis Technical Call. I have
added more details to the Google document.

Regards,
Tarique Islam
XL Fortran Compiler Development
IBM Toronto Software Lab
tislam at ca.ibm.com (905) 413-3190

[Inactive hide details for "Finkel, Hal J. via llvm-dev" ---2020-05-18
12:41:56 PM---To join our call on Thursday, May 28th @ 9-]"Finkel, Hal J.
via llvm-dev" ---2020-05-18 12:41:56 PM---To join our call on Thursday, May
28th @ 9-10 AM central time / 2-3 PM UTC please use this informati

From: "Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org>
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>, Alina Sbirlea
<alina.sbirlea at gmail.com>
Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>,
"Doerfert, Johannes" <jdoerfert at anl.gov>
Date: 2020-05-18 12:41 PM
Subject: [EXTERNAL] Re: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle
Poll
Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org>

________________________________

To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC
please use this information:

Meeting URL
https://bluejeans.com/643493129?src=join_info

Meeting ID
643 493 129

Want to dial in from a phone?

Dial one of the following numbers:
+1.312.216.0325 (US (Chicago))
+1.408.740.7256 (US (San Jose))
+1.866.226.4650 (US Toll Free)
(see all numbers - https://www.bluejeans.com/premium-numbers)

Enter the meeting ID and passcode followed by #

Connecting from a room system?
Dial: bjn.vc or 199.48.152.152 and enter your meeting ID & passcode

On our agenda, we'll have:

1. Scalability challenges and other issues discovered with the current
infrastructure (especially, perhaps, with the noalias metadata).
2. Proposed solutions: progress, outstanding challenges, how to make progress
going forward.

We'll formulate the detailed agenda and take notes from the call using this
Google doc:
https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing

A summary will then be sent to the mailing list after the call. If you would
like to add items to the agenda, please edit the document (or reply to this
email).

Thanks again,
Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

________________________________

From: Finkel, Hal J. <hfinkel at anl.gov>
Sent: Monday, May 18, 2020 10:24 AM
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>; Alina Sbirlea
<alina.sbirlea at gmail.com>; Finkel, Hal J. <hfinkel at anl.gov>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Doerfert,
Johannes <jdoerfert at anl.gov>
Subject: Re: LLVM Alias Analysis Technical Call - Doodle Poll

Thanks to everyone who participated in the poll. The time that maximizes
availability is:

Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC.

I'll send out meeting information shortly.

-Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

________________________________

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Finkel,
Hal J. via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Wednesday, May 13, 2020 11:14 AM
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>; Alina Sbirlea
<alina.sbirlea at gmail.com>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Doerfert,
Johannes <jdoerfert at anl.gov>
Subject: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll

Hi, everyone,

We've had a number of discussions recently, including on the Flang technical
call, about potential improvements to LLVM's alias analysis to support
handling restrict and restrict-like semantics.

We would like to try having a call to discuss these issues further. Please, if
you're interested in joining, indicate your availability (prior to the end
of this week):

https://doodle.com/poll/evhwr2eyfvcf8ib3

Thanks again,
Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

________________________________

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Alina
Sbirlea via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Monday, May 11, 2020 9:49 AM
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Doerfert,
Johannes <jdoerfert at anl.gov>
Subject: Re: [llvm-dev] Full restrict support - status update

Hi Johannes et al,

Trying to revive this discussion, as the restrict support is relevant for one of
our teams.

Thank you,
Alina

On Tue, Nov 12, 2019 at 1:16 PM Jeroen Dobbelaere via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Hi Johannes et al,
> -----Original Message-----
> From: Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at
anl.gov>>
[..]> On 11/06, Jeroen Dobbelaere wrote:
> > >From: Alexey Zhikhartsev
> > [..]
> > > We would love to see your patches merged as soon as possible, so
I was
> wondering: do you think the lack of bitcode support will prevent that from
> happening?
> >
> > Yes, I think that the lack of bitcode support will prevent it.
> >
> > During the Developers meeting, I also talked with Hal and Johannes.
> > They had some extra remarks:
> > - (1) the restrict implementation deserves a separate document. (I am
> working on that one)
> > - (2) they don't like the naming of 'noalias_sidechannel'.
> > - (3) they also have some other mechanisms in mind to add the
'sidechannel'
> to the load/store instructions
> > (and maybe to function calls, intrinsics; currently that is handled
through
> llvm.noalias.arg.guard)
> >
> > For (2) and (3), I am waiting for a proposal from them ;)
>
> I would like to see the restrict support be merged but, as Jeroen
> mentions above, I feel there are two design choices we have to
> overthink. Here are short descriptions to get some feedback from the
> community:
>
> (A) Naming and restriction
>
> The name "sidechannel" is unfortunate, it has various negative
> connotations, e.g., the release notes that read:
> "LLVM 10.0 now has sidechannel support for your restrict pointer"
> will raise a lot of follow up questions.
>
> What I think we actually do, and what we should call it, is
"provenance"
> tracking.
>
> Now beyond the pure renaming of "sidechannel" into
"provenance" (or sth.
> similar) I want us to decouple provenance tracking from the noalias
> logic. Noalias/restrict is one use case in which (pointer) provenance
> information is useful but not the only one. If we add some mechanism to
> track provenance, let's make it generic and reusable. Note that the
> basic ideas are not much different to what the noalias RFC proposed.
> The major difference would be that we have provenance information and if
> that originates in an `llvm.restrict.decl` call we can use it for
> (no)alias queries.
"provenance" might indeed be a good name.

There is a big difference between a restrict declaration, and a restrict usage:
- the declaration intrinsic (llvm.noalias.decl) is used to track in the cfg the
location
where the restrict variable was declared. This is important to handle code
motion,
merging, duplication in a correct way (inlining, loop unrolling, ...)
- the restrict usage intrinsics (llvm.noalias and llvm.side.noalias) are used to
indicate
that from that point on, restrict (noalias) properties are introduced for that
pointer.
They can exist without an associated 'llvm.noalias.decl' (when the
declaration is outside
the function.)
Given that, I assume that you mean 'llvm.provenance.noalias' (~
llvm.side.noalias) instead
of 'llvm.restrict.decl'.
>
>
>
> (B) Using operand bundles
>
> Right now, loads and stores are treated differently and given a new
> operand. Then there are intrinsics to decode other kinds of information.
> As an alternative, we could allow operand bundles on all instructions
> and use them to tie information to an instruction. The
"sidechannel"
> operand of a load would then look something like:
> load i32* %p [ "ptr_provenance"(%p_decl) ]
> and for a store we could have
> store i32** %p.addr, i32* %p [ "ptr_provenance"(%p_decl) ]
>
> The benefit is that we do not change the operand count (which causes a
> lot of noise) but we still have to make sure ptr/value uses are not
> confused with operand bundle uses. We can attach the information to more
> than load/store instructions, also to remove the need for some of the
> intrinsics.
To me, operand bundles sound to be more or less equivalent to the current
solution. It might also make the 'instruction cloning' easier, if we can
omit the
'ptr_provenance' there. The change of the number of operands caused some
noise, but it is the changes in the amount of 'uses' of a pointer that
refer to the
same instruction that caused the most problems. Especially when that instruction
was going to be erased. Operand bundles will still need those code changes.
(like in parts of D68516 and D68518)

As the 'Call' instruction already supports operand bundles, it could
eliminate the need
for the 'llvm.noalias.arg.guard' intrinsic, which combines the normal
pointer with the
side channel (aka provenance). But, after inlining, we still need to put that
information
somewhere. Or it should be propagated during inlining.
Care must be taken not to lose that information when the 'call' is
changed by optimizations
as, after inlining, that might result in wrong alias analysis conclusions.

Are you thinking of "operand bundles" support for just
LoadInst/StoreInst, or for all
instructions ?

Greetings,

Jeroen Dobbelaere

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://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/20200521/1944ced4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: graycol.gif
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200521/1944ced4/attachment-0001.gif>

Tarique Islam via llvm-dev

2020-May-25 19:51 UTC

head link

[llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll

Hi Hal,

  If it is okay with the group, we can start looking into the LLVM codebase
for Metadata operations and discuss about the technical details related to
the scalability. In that case, we can start with the following.

    ./llvm/include/llvm/IR/Metadata.h
    ./llvm/lib/IR/Metadata.cpp
    ./llvm/lib/Analysis/ScopedNoAliasAA.cpp

  If needed, we can present some slides for a quick recap of the alias
representation.

  Regarding the hierarchical representation, we can start with your patch
for scoped-noalias metadata.

https://github.com/llvm/llvm-project/commit/9414665a3b0bd525f84d76e24048ca60ebe6c710

Regards,
Tarique Islam
XL Fortran Compiler Development
IBM Toronto Software Lab
tislam at ca.ibm.com (905) 413-3190





From:	"Finkel, Hal J." <hfinkel at anl.gov>
To:	Tarique Islam <tislam at ca.ibm.com>
Cc:	Alina Sbirlea <alina.sbirlea at gmail.com>, "Doerfert,
Johannes"
            <jdoerfert at anl.gov>, Jeroen Dobbelaere
            <Jeroen.Dobbelaere at synopsys.com>, "llvm-dev at
lists.llvm.org"
            <llvm-dev at lists.llvm.org>
Date:	2020-05-21 12:15 PM
Subject:	[EXTERNAL] Re: [llvm-dev] LLVM Alias Analysis Technical Call -
            Doodle Poll



Great, thanks!

Are you planning on just talking about these things with slides? Do we have
other things to which we can link for people to read?

-Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From: Tarique Islam <tislam at ca.ibm.com>
Sent: Thursday, May 21, 2020 8:19:31 AM
To: Finkel, Hal J. <hfinkel at anl.gov>
Cc: Alina Sbirlea <alina.sbirlea at gmail.com>; Doerfert, Johannes
<jdoerfert at anl.gov>; Jeroen Dobbelaere <Jeroen.Dobbelaere at
synopsys.com>;
llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
Subject: RE: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll



Hi Hal,

Thanks very much for scheduling the LLVM Alias Analysis Technical Call. I
have added more details to the Google document.

Regards,
Tarique Islam
XL Fortran Compiler Development
IBM Toronto Software Lab
tislam at ca.ibm.com (905) 413-3190



Inactive hide details for "Finkel, Hal J. via llvm-dev" ---2020-05-18
12:41:56 PM---To join our call on Thursday, May 28th @ 9-"Finkel, Hal J.
via llvm-dev" ---2020-05-18 12:41:56 PM---To join our call on Thursday, May
28th @ 9-10 AM central time / 2-3 PM UTC please use this informati

From: "Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org>
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>, Alina Sbirlea
<alina.sbirlea at gmail.com>
Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>,
"Doerfert,
Johannes" <jdoerfert at anl.gov>
Date: 2020-05-18 12:41 PM
Subject: [EXTERNAL] Re: [llvm-dev] LLVM Alias Analysis Technical Call -
Doodle Poll
Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org>





To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC
please use this information:

Meeting URL
https://bluejeans.com/643493129?src=join_info

Meeting ID
643 493 129

Want to dial in from a phone?

Dial one of the following numbers:
+1.312.216.0325 (US (Chicago))
+1.408.740.7256 (US (San Jose))
+1.866.226.4650 (US Toll Free)
(see all numbers - https://www.bluejeans.com/premium-numbers)

Enter the meeting ID and passcode followed by #

Connecting from a room system?
Dial: bjn.vc or 199.48.152.152 and enter your meeting ID & passcode

On our agenda, we'll have:

1. Scalability challenges and other issues discovered with the current
infrastructure (especially, perhaps, with the noalias metadata).
2. Proposed solutions: progress, outstanding challenges, how to make
progress going forward.

We'll formulate the detailed agenda and take notes from the call using this
Google doc:
https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing


A summary will then be sent to the mailing list after the call. If you
would like to add items to the agenda, please edit the document (or reply
to this email).

Thanks again,
Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From: Finkel, Hal J. <hfinkel at anl.gov>
Sent: Monday, May 18, 2020 10:24 AM
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>; Alina Sbirlea
<alina.sbirlea at gmail.com>; Finkel, Hal J. <hfinkel at anl.gov>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Doerfert,
Johannes
<jdoerfert at anl.gov>
Subject: Re: LLVM Alias Analysis Technical Call - Doodle Poll

Thanks to everyone who participated in the poll. The time that maximizes
availability is:

Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC.

I'll send out meeting information shortly.

-Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Finkel,
Hal
J. via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Wednesday, May 13, 2020 11:14 AM
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>; Alina Sbirlea
<alina.sbirlea at gmail.com>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Doerfert,
Johannes
<jdoerfert at anl.gov>
Subject: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll

Hi, everyone,

We've had a number of discussions recently, including on the Flang
technical call, about potential improvements to LLVM's alias analysis to
support handling restrict and restrict-like semantics.

We would like to try having a call to discuss these issues further. Please,
if you're interested in joining, indicate your availability (prior to the
end of this week):

https://doodle.com/poll/evhwr2eyfvcf8ib3

Thanks again,
Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Alina
Sbirlea
via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Monday, May 11, 2020 9:49 AM
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Doerfert,
Johannes
<jdoerfert at anl.gov>
Subject: Re: [llvm-dev] Full restrict support - status update

Hi Johannes et al,

Trying to revive this discussion, as the restrict support is relevant for
one of our teams.

Thank you,
Alina

On Tue, Nov 12, 2019 at 1:16 PM Jeroen Dobbelaere via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
      Hi Johannes et al,

      > -----Original Message-----
      > From: Doerfert, Johannes <jdoerfert at anl.gov>
      [..]
      > On 11/06, Jeroen Dobbelaere wrote:
      > > >From: Alexey Zhikhartsev
      > > [..]
      > > > We would love to see your patches merged as soon as
possible,
      so I was
      > wondering: do you think the lack of bitcode support will prevent
      that from
      > happening?
      > >
      > > Yes, I think that the lack of bitcode support will prevent it.
      > >
      > > During the Developers meeting, I also talked with Hal and
      Johannes.
      > > They had some extra remarks:
      > > - (1) the restrict implementation deserves a separate document.
      (I am
      > working on that one)
      > > - (2) they don't like the naming of
'noalias_sidechannel'.
      > > - (3) they also have some other mechanisms in mind to add the
      'sidechannel'
      > to the load/store instructions
      > > (and maybe to function calls, intrinsics; currently that is
      handled through
      > llvm.noalias.arg.guard)
      > >
      > > For (2) and (3), I am waiting for a proposal from them ;)
      >
      > I would like to see the restrict support be merged but, as Jeroen
      > mentions above, I feel there are two design choices we have to
      > overthink. Here are short descriptions to get some feedback from
      the
      > community:
      >
      > (A) Naming and restriction
      >
      > The name "sidechannel" is unfortunate, it has various
negative
      > connotations, e.g., the release notes that read:
      > "LLVM 10.0 now has sidechannel support for your restrict
pointer"
      > will raise a lot of follow up questions.
      >
      > What I think we actually do, and what we should call it, is
      "provenance"
      > tracking.
      >
      > Now beyond the pure renaming of "sidechannel" into
"provenance" (or
      sth.
      > similar) I want us to decouple provenance tracking from the noalias
      > logic. Noalias/restrict is one use case in which (pointer)
      provenance
      > information is useful but not the only one. If we add some
      mechanism to
      > track provenance, let's make it generic and reusable. Note that
the
      > basic ideas are not much different to what the noalias RFC
      proposed.
      > The major difference would be that we have provenance information
      and if
      > that originates in an `llvm.restrict.decl` call we can use it for
      > (no)alias queries.

      "provenance" might indeed be a good name.

      There is a big difference between a restrict declaration, and a
      restrict usage:
      - the declaration intrinsic (llvm.noalias.decl) is used to track in
      the cfg the location
      where the restrict variable was declared. This is important to handle
      code motion,
      merging, duplication in a correct way (inlining, loop unrolling, ...)
      - the restrict usage intrinsics (llvm.noalias and llvm.side.noalias)
      are used to indicate
      that from that point on, restrict (noalias) properties are introduced
      for that pointer.
      They can exist without an associated 'llvm.noalias.decl' (when the
      declaration is outside
      the function.)
      Given that, I assume that you mean 'llvm.provenance.noalias' (~
      llvm.side.noalias) instead
      of 'llvm.restrict.decl'.

      >
      >
      >
      > (B) Using operand bundles
      >
      > Right now, loads and stores are treated differently and given a new
      > operand. Then there are intrinsics to decode other kinds of
      information.
      > As an alternative, we could allow operand bundles on all
      instructions
      > and use them to tie information to an instruction. The
      "sidechannel"
      > operand of a load would then look something like:
      > load i32* %p [ "ptr_provenance"(%p_decl) ]
      > and for a store we could have
      > store i32** %p.addr, i32* %p [ "ptr_provenance"(%p_decl) ]
      >
      > The benefit is that we do not change the operand count (which
      causes a
      > lot of noise) but we still have to make sure ptr/value uses are not
      > confused with operand bundle uses. We can attach the information to
      more
      > than load/store instructions, also to remove the need for some of
      the
      > intrinsics.

      To me, operand bundles sound to be more or less equivalent to the
      current
      solution. It might also make the 'instruction cloning' easier, if
we
      can omit the
      'ptr_provenance' there. The change of the number of operands
caused
      some
      noise, but it is the changes in the amount of 'uses' of a pointer
      that refer to the
      same instruction that caused the most problems. Especially when that
      instruction
      was going to be erased. Operand bundles will still need those code
      changes.
      (like in parts of D68516 and D68518)

      As the 'Call' instruction already supports operand bundles, it
could
      eliminate the need
      for the 'llvm.noalias.arg.guard' intrinsic, which combines the
normal
      pointer with the
      side channel (aka provenance). But, after inlining, we still need to
      put that information
      somewhere. Or it should be propagated during inlining.
      Care must be taken not to lose that information when the 'call' is
      changed by optimizations
      as, after inlining, that might result in wrong alias analysis
      conclusions.

      Are you thinking of "operand bundles" support for just
      LoadInst/StoreInst, or for all
      instructions ?

      Greetings,

      Jeroen Dobbelaere


      _______________________________________________
      LLVM Developers mailing list
      llvm-dev at lists.llvm.org
      https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
      _______________________________________________
      LLVM Developers mailing list
      llvm-dev at lists.llvm.org
      https://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/20200525/2df9483f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200525/2df9483f/attachment-0001.gif>

Tarique Islam via llvm-dev

2020-May-26 20:32 UTC

head link

[llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll

Two additional references for the discussion.

1. (IBM) Represent Fortran alias information in LLVM IR -
http://lists.llvm.org/pipermail/llvm-dev/2020-April/140945.html
2. (Jeroen et al.) RFC: Full 'restrict' support in LLVM -
https://lists.llvm.org/pipermail/llvm-dev/2019-October/135672.html

Regards,
Tarique Islam
XL Fortran Compiler Development
IBM Toronto Software Lab
tislam at ca.ibm.com (905) 413-3190





From:	Tarique Islam via llvm-dev <llvm-dev at lists.llvm.org>
To:	"Finkel, Hal J." <hfinkel at anl.gov>
Cc:	"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>,
"Doerfert,
            Johannes" <jdoerfert at anl.gov>
Date:	2020-05-25 08:34 PM
Subject:	[EXTERNAL] Re: [llvm-dev] LLVM Alias Analysis Technical Call -
            Doodle Poll
Sent by:	"llvm-dev" <llvm-dev-bounces at lists.llvm.org>



Hi Hal,

If it is okay with the group, we can start looking into the LLVM codebase
for Metadata operations and discuss about the technical details related to
the scalability. In that case, we can start with the following.

    ./llvm/include/llvm/IR/Metadata.h
    ./llvm/lib/IR/Metadata.cpp
    ./llvm/lib/Analysis/ScopedNoAliasAA.cpp

If needed, we can present some slides for a quick recap of the alias
representation.

Regarding the hierarchical representation, we can start with your patch for
scoped-noalias metadata.
https://github.com/llvm/llvm-project/commit/9414665a3b0bd525f84d76e24048ca60ebe6c710


Regards,
Tarique Islam
XL Fortran Compiler Development
IBM Toronto Software Lab
tislam at ca.ibm.com (905) 413-3190



Inactive hide details for "Finkel, Hal J." ---2020-05-21 12:15:42
PM---Great, thanks! Are you planning on just talking about th"Finkel, Hal
J." ---2020-05-21 12:15:42 PM---Great, thanks! Are you planning on just
talking about these things with slides? Do we have other thi

From: "Finkel, Hal J." <hfinkel at anl.gov>
To: Tarique Islam <tislam at ca.ibm.com>
Cc: Alina Sbirlea <alina.sbirlea at gmail.com>, "Doerfert,
Johannes"
<jdoerfert at anl.gov>, Jeroen Dobbelaere <Jeroen.Dobbelaere at
synopsys.com>,
"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
Date: 2020-05-21 12:15 PM
Subject: [EXTERNAL] Re: [llvm-dev] LLVM Alias Analysis Technical Call -
Doodle Poll



Great, thanks!

Are you planning on just talking about these things with slides? Do we have
other things to which we can link for people to read?

-Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From: Tarique Islam <tislam at ca.ibm.com>
Sent: Thursday, May 21, 2020 8:19:31 AM
To: Finkel, Hal J. <hfinkel at anl.gov>
Cc: Alina Sbirlea <alina.sbirlea at gmail.com>; Doerfert, Johannes
<jdoerfert at anl.gov>; Jeroen Dobbelaere <Jeroen.Dobbelaere at
synopsys.com>;
llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
Subject: RE: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll


Hi Hal,

Thanks very much for scheduling the LLVM Alias Analysis Technical Call. I
have added more details to the Google document.

Regards,
Tarique Islam
XL Fortran Compiler Development
IBM Toronto Software Lab
tislam at ca.ibm.com (905) 413-3190



Inactive hide details for "Finkel, Hal J. via llvm-dev" ---2020-05-18
12:41:56 PM---To join our call on Thursday, May 28th @ 9-"Finkel, Hal J.
via llvm-dev" ---2020-05-18 12:41:56 PM---To join our call on Thursday, May
28th @ 9-10 AM central time / 2-3 PM UTC please use this informati

From: "Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org>
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>, Alina Sbirlea
<alina.sbirlea at gmail.com>
Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>,
"Doerfert,
Johannes" <jdoerfert at anl.gov>
Date: 2020-05-18 12:41 PM
Subject: [EXTERNAL] Re: [llvm-dev] LLVM Alias Analysis Technical Call -
Doodle Poll
Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org>





To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC
please use this information:

Meeting URL
https://bluejeans.com/643493129?src=join_info

Meeting ID
643 493 129

Want to dial in from a phone?

Dial one of the following numbers:
+1.312.216.0325 (US (Chicago))
+1.408.740.7256 (US (San Jose))
+1.866.226.4650 (US Toll Free)
(see all numbers - https://www.bluejeans.com/premium-numbers)

Enter the meeting ID and passcode followed by #

Connecting from a room system?
Dial: bjn.vc or 199.48.152.152 and enter your meeting ID & passcode

On our agenda, we'll have:

1. Scalability challenges and other issues discovered with the current
infrastructure (especially, perhaps, with the noalias metadata).
2. Proposed solutions: progress, outstanding challenges, how to make
progress going forward.

We'll formulate the detailed agenda and take notes from the call using this
Google doc:
https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing


A summary will then be sent to the mailing list after the call. If you
would like to add items to the agenda, please edit the document (or reply
to this email).

Thanks again,
Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From: Finkel, Hal J. <hfinkel at anl.gov>
Sent: Monday, May 18, 2020 10:24 AM
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>; Alina Sbirlea
<alina.sbirlea at gmail.com>; Finkel, Hal J. <hfinkel at anl.gov>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Doerfert,
Johannes
<jdoerfert at anl.gov>
Subject: Re: LLVM Alias Analysis Technical Call - Doodle Poll

Thanks to everyone who participated in the poll. The time that maximizes
availability is:

Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC.

I'll send out meeting information shortly.

-Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Finkel,
Hal
J. via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Wednesday, May 13, 2020 11:14 AM
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>; Alina Sbirlea
<alina.sbirlea at gmail.com>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Doerfert,
Johannes
<jdoerfert at anl.gov>
Subject: [llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll

Hi, everyone,

We've had a number of discussions recently, including on the Flang
technical call, about potential improvements to LLVM's alias analysis to
support handling restrict and restrict-like semantics.

We would like to try having a call to discuss these issues further. Please,
if you're interested in joining, indicate your availability (prior to the
end of this week):

https://doodle.com/poll/evhwr2eyfvcf8ib3

Thanks again,
Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Alina
Sbirlea
via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Monday, May 11, 2020 9:49 AM
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Doerfert,
Johannes
<jdoerfert at anl.gov>
Subject: Re: [llvm-dev] Full restrict support - status update

Hi Johannes et al,

Trying to revive this discussion, as the restrict support is relevant for
one of our teams.

Thank you,
Alina

On Tue, Nov 12, 2019 at 1:16 PM Jeroen Dobbelaere via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
            Hi Johannes et al,

            > -----Original Message-----
            > From: Doerfert, Johannes <jdoerfert at anl.gov>
            [..]
            > On 11/06, Jeroen Dobbelaere wrote:
            > > >From: Alexey Zhikhartsev
            > > [..]
            > > > We would love to see your patches merged as soon as
            possible, so I was
            > wondering: do you think the lack of bitcode support will
            prevent that from
            > happening?
            > >
            > > Yes, I think that the lack of bitcode support will prevent
            it.
            > >
            > > During the Developers meeting, I also talked with Hal and
            Johannes.
            > > They had some extra remarks:
            > > - (1) the restrict implementation deserves a separate
            document. (I am
            > working on that one)
            > > - (2) they don't like the naming of
'noalias_sidechannel'.
            > > - (3) they also have some other mechanisms in mind to add
            the 'sidechannel'
            > to the load/store instructions
            > > (and maybe to function calls, intrinsics; currently that
is
            handled through
            > llvm.noalias.arg.guard)
            > >
            > > For (2) and (3), I am waiting for a proposal from them ;)
            >
            > I would like to see the restrict support be merged but, as
            Jeroen
            > mentions above, I feel there are two design choices we have
            to
            > overthink. Here are short descriptions to get some feedback
            from the
            > community:
            >
            > (A) Naming and restriction
            >
            > The name "sidechannel" is unfortunate, it has various
            negative
            > connotations, e.g., the release notes that read:
            > "LLVM 10.0 now has sidechannel support for your restrict
            pointer"
            > will raise a lot of follow up questions.
            >
            > What I think we actually do, and what we should call it, is
            "provenance"
            > tracking.
            >
            > Now beyond the pure renaming of "sidechannel" into
            "provenance" (or sth.
            > similar) I want us to decouple provenance tracking from the
            noalias
            > logic. Noalias/restrict is one use case in which (pointer)
            provenance
            > information is useful but not the only one. If we add some
            mechanism to
            > track provenance, let's make it generic and reusable. Note
            that the
            > basic ideas are not much different to what the noalias RFC
            proposed.
            > The major difference would be that we have provenance
            information and if
            > that originates in an `llvm.restrict.decl` call we can use it
            for
            > (no)alias queries.

            "provenance" might indeed be a good name.

            There is a big difference between a restrict declaration, and a
            restrict usage:
            - the declaration intrinsic (llvm.noalias.decl) is used to
            track in the cfg the location
            where the restrict variable was declared. This is important to
            handle code motion,
            merging, duplication in a correct way (inlining, loop
            unrolling, ...)
            - the restrict usage intrinsics (llvm.noalias and
            llvm.side.noalias) are used to indicate
            that from that point on, restrict (noalias) properties are
            introduced for that pointer.
            They can exist without an associated 'llvm.noalias.decl'
(when
            the declaration is outside
            the function.)
            Given that, I assume that you mean 'llvm.provenance.noalias'
(~
            llvm.side.noalias) instead
            of 'llvm.restrict.decl'.

            >
            >
            >
            > (B) Using operand bundles
            >
            > Right now, loads and stores are treated differently and given
            a new
            > operand. Then there are intrinsics to decode other kinds of
            information.
            > As an alternative, we could allow operand bundles on all
            instructions
            > and use them to tie information to an instruction. The
            "sidechannel"
            > operand of a load would then look something like:
            > load i32* %p [ "ptr_provenance"(%p_decl) ]
            > and for a store we could have
            > store i32** %p.addr, i32* %p [
"ptr_provenance"(%p_decl) ]
            >
            > The benefit is that we do not change the operand count (which
            causes a
            > lot of noise) but we still have to make sure ptr/value uses
            are not
            > confused with operand bundle uses. We can attach the
            information to more
            > than load/store instructions, also to remove the need for
            some of the
            > intrinsics.

            To me, operand bundles sound to be more or less equivalent to
            the current
            solution. It might also make the 'instruction cloning'
easier,
            if we can omit the
            'ptr_provenance' there. The change of the number of operands
            caused some
            noise, but it is the changes in the amount of 'uses' of a
            pointer that refer to the
            same instruction that caused the most problems. Especially when
            that instruction
            was going to be erased. Operand bundles will still need those
            code changes.
            (like in parts of D68516 and D68518)

            As the 'Call' instruction already supports operand bundles,
it
            could eliminate the need
            for the 'llvm.noalias.arg.guard' intrinsic, which combines
the
            normal pointer with the
            side channel (aka provenance). But, after inlining, we still
            need to put that information
            somewhere. Or it should be propagated during inlining.
            Care must be taken not to lose that information when the
'call'
            is changed by optimizations
            as, after inlining, that might result in wrong alias analysis
            conclusions.

            Are you thinking of "operand bundles" support for just
            LoadInst/StoreInst, or for all
            instructions ?

            Greetings,

            Jeroen Dobbelaere


            _______________________________________________
            LLVM Developers mailing list
            llvm-dev at lists.llvm.org
            https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
            _______________________________________________
            LLVM Developers mailing list
            llvm-dev at lists.llvm.org
            https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev





_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=97AgnMuYWFYpNtPqWWONRW4p70wrj1M73eAjtfHLVt8&m=BF4Eh8uO0Fan8jUkSCQScuR12F6L_6kCwNoo3GE6mWc&s=hGxPOFzdnCWAZOp1Bok1yiVRX32Cw_rAPd6q6IJdOxE&e






-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200526/34d9f589/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200526/34d9f589/attachment-0001.gif>

llvm dev - May 2020 - LLVM Alias Analysis Technical Call - Doodle Poll

[llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll

[llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll

[llvm-dev] LLVM Alias Analysis Technical Call - Doodle Poll