llvm dev - Sep 2019 - Loop Opt WG Meeting Minutes for Sep 11, 2019

---------------------------
Wed, Sep 11, 2019:
---------------------------

- LICM vs Loop Sink Strategy (Whitney)
    - LICM and SCEV expander host code with no regards to increased
      live-ranges. This is a long standing issue where historically
      preference has been to keep LICM more aggressive.
    - Two questions from IBM side:
      a. This problem is not specific to the POWER platform, so we are
         wondering if other people are interested?
    - b. Where would be the best place to address this issue?
        - Since it's hard to come up with an accurate register pressure
          estimator in opt, it's probably better to be done fairly late,
          maybe after instruction scheduling.
        - A good place to start would be instruction re-materialization in
          the register allocator.
        - Problem is the logic in the register allocator can deal with a
          single instruction (instead of groups of instructions) at a time.
        - Start by handling one single-instruction at a time and apply the
          same logic to groups of instructions iteratively to see the
          impact on performance and compile-time.
        - live-range editor may have utilities to help with code motion.
    - lazy-code-motion may be a good long term solution, but no one seems
      to be actively working on it.

- Announcements:
    - flang call moved so we are no longer in conflict!

    - Philip is working on making loop vectorizer robust in the face of
      multiple exits. There are two subproblems
        1. vectorizer currently gives up because scev is not giving exit
           counts (due to a bug?). This is relatively easy to fix and
           Philip will have a patch for it soon.
        2. loop exit cannot be analyzed due to data dependent exit, which
           is currently handled via predication. There is a lot of room
           for improvement, specially for read-only loops.
           Please let him know if you are interested.


- Status Updates
  - Data Dependence Graph (https://reviews.llvm.org/D65350) (Bardia)
    - All review comments are addressed. Waiting for approval.
  - Bugzilla bugs update (Vivek)
    - Florian has a patch fixing loop bugs related to max trip count.

----------------------------
Tentative Agenda for Sept 25
----------------------------

Presentation from Marc Moreno Maza about his work on delinearization.

- Status Updates
  - Follow up on multi-dimensional array indexing RFC (Siddharth)
  - Impact of Loop Rotation on existing passes (Min-Yih)
  - Data Dependence Graph (https://reviews.llvm.org/D65350) (Bardia)
  - Bugzilla bugs update (Vivek)
  - Others?


Bardia Mahjour
Compiler Optimizations
IBM Toronto Software Lab
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190911/e2eb9ae0/attachment.html>

Hi,

> On Sep 11, 2019, at 17:51, Bardia Mahjour via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> ---------------------------
> Wed, Sep 11, 2019:
> ---------------------------
> 
> - LICM vs Loop Sink Strategy (Whitney)
> - LICM and SCEV expander host code with no regards to increased 
> live-ranges. This is a long standing issue where historically 
> preference has been to keep LICM more aggressive.
> 
This issue also motivated adding metadata to disable LICM
(llvm.loop.licm.disable) recently. https://reviews.llvm.org/D64557
<https://reviews.llvm.org/D64557>
> - Two questions from IBM side:
> a. This problem is not specific to the POWER platform, so we are
> wondering if other people are interested?
> - b. Where would be the best place to address this issue?
> - Since it's hard to come up with an accurate register pressure 
> estimator in opt, it's probably better to be done fairly late,
> maybe after instruction scheduling.
> - A good place to start would be instruction re-materialization in 
> the register allocator.
> - Problem is the logic in the register allocator can deal with a 
> single instruction (instead of groups of instructions) at a time.
> - Start by handling one single-instruction at a time and apply the
> same logic to groups of instructions iteratively to see the 
> impact on performance and compile-time.
> - live-range editor may have utilities to help with code motion.
> - lazy-code-motion may be a good long term solution, but no one seems
> to be actively working on it.
> 
> - Announcements: 
> - flang call moved so we are no longer in conflict!
> 
> - Philip is working on making loop vectorizer robust in the face of 
> multiple exits. There are two subproblems
> 1. vectorizer currently gives up because scev is not giving exit 
> counts (due to a bug?). This is relatively easy to fix and
> Philip will have a patch for it soon.
> 2. loop exit cannot be analyzed due to data dependent exit, which
> is currently handled via predication. There is a lot of room
> for improvement, specially for read-only loops. 
> Please let him know if you are interested.
> 
> 
> - Status Updates
> - Data Dependence Graph (https://reviews.llvm.org/D65350
<https://reviews.llvm.org/D65350>) (Bardia)
> - All review comments are addressed. Waiting for approval.
> - Bugzilla bugs update (Vivek)
> - Florian has a patch fixing loop bugs related to max trip count.
> 
> ----------------------------
> Tentative Agenda for Sept 25
> ----------------------------
> 
> Presentation from Marc Moreno Maza about his work on delinearization.
> 
> - Status Updates
> - Follow up on multi-dimensional array indexing RFC (Siddharth)
> - Impact of Loop Rotation on existing passes (Min-Yih)
> - Data Dependence Graph (https://reviews.llvm.org/D65350
<https://reviews.llvm.org/D65350>) (Bardia)
> - Bugzilla bugs update (Vivek)
> - Others?
> 
> 
> Bardia Mahjour
> Compiler Optimizations
> IBM Toronto Software Lab
> _______________________________________________
> 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/20190913/89eaf8c0/attachment.html>

Thanks Florian.

Tim you said:
> Some cases can be undone by rematerialization, but not all, and it can
involve a lot of effort which increases compile time.

Do you have examples of cases where rematerialization is not possible? We
are interested in learning about any previous attempts at trying to address
the issue in RA. Have you tried it?

Bardia Mahjour
Compiler Optimizations
IBM Toronto Software Lab
bmahjour at ca.ibm.com (905) 413-2336





From:	Florian Hahn <florian_hahn at apple.com>
To:	Bardia Mahjour <bmahjour at ca.ibm.com>
Cc:	via llvm-dev <llvm-dev at lists.llvm.org>, tcorring at amd.com
Date:	2019/09/13 11:16 AM
Subject:	[EXTERNAL] Re: [llvm-dev] Loop Opt WG Meeting Minutes for Sep
            11, 2019
Sent by:	florian_hahn at apple.com



Hi,


      On Sep 11, 2019, at 17:51, Bardia Mahjour via llvm-dev <
      llvm-dev at lists.llvm.org> wrote:



      ---------------------------
      Wed, Sep 11, 2019:
      ---------------------------

      - LICM vs Loop Sink Strategy (Whitney)
      - LICM and SCEV expander host code with no regards to increased
      live-ranges. This is a long standing issue where historically
      preference has been to keep LICM more aggressive.



This issue also motivated adding metadata to disable LICM (l
lvm.loop.licm.disable) recently. https://reviews.llvm.org/D64557


      - Two questions from IBM side:
      a. This problem is not specific to the POWER platform, so we are
      wondering if other people are interested?
      - b. Where would be the best place to address this issue?
      - Since it's hard to come up with an accurate register pressure
      estimator in opt, it's probably better to be done fairly late,
      maybe after instruction scheduling.
      - A good place to start would be instruction re-materialization in
      the register allocator.
      - Problem is the logic in the register allocator can deal with a
      single instruction (instead of groups of instructions) at a time.
      - Start by handling one single-instruction at a time and apply the
      same logic to groups of instructions iteratively to see the
      impact on performance and compile-time.
      - live-range editor may have utilities to help with code motion.
      - lazy-code-motion may be a good long term solution, but no one seems
      to be actively working on it.

      - Announcements:
      - flang call moved so we are no longer in conflict!

      - Philip is working on making loop vectorizer robust in the face of
      multiple exits. There are two subproblems
      1. vectorizer currently gives up because scev is not giving exit
      counts (due to a bug?). This is relatively easy to fix and
      Philip will have a patch for it soon.
      2. loop exit cannot be analyzed due to data dependent exit, which
      is currently handled via predication. There is a lot of room
      for improvement, specially for read-only loops.
      Please let him know if you are interested.


      - Status Updates
      - Data Dependence Graph (https://reviews.llvm.org/D65350) (Bardia)
      - All review comments are addressed. Waiting for approval.
      - Bugzilla bugs update (Vivek)
      - Florian has a patch fixing loop bugs related to max trip count.

      ----------------------------
      Tentative Agenda for Sept 25
      ----------------------------

      Presentation from Marc Moreno Maza about his work on delinearization.

      - Status Updates
      - Follow up on multi-dimensional array indexing RFC (Siddharth)
      - Impact of Loop Rotation on existing passes (Min-Yih)
      - Data Dependence Graph (https://reviews.llvm.org/D65350) (Bardia)
      - Bugzilla bugs update (Vivek)
      - Others?


      Bardia Mahjour
      Compiler Optimizations
      IBM Toronto Software Lab


      _______________________________________________
      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/20190913/8e0c9ce4/attachment.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/20190913/8e0c9ce4/attachment.gif>