llvm dev - Oct 2017 - [RFC] Polly Status and Integration

>I think we need to get that story right for both cases up front.
Renato, I kicked off this secondary discussion, borrowing the opportunity from
Michael's RFC,
but to the point of reviewing https://reviews.llvm.org/D38676, I'd like the
review to proceed
separately from this bigger (and most likely longer) discussion. We
intentionally made the interfaces
similar such that whatever the outcome of this discussion would be, the changes
we have to make later,
if any, is small and mechanical. We just need to agree that
	VPValue/VPUser/VPInstruction
is not a precedence, i.e., still subject to ongoing discussion and is expected
to abide by the eventual
outcome of this discussion.

To the best of my understanding, if we do not want to modify the IR (i.e., CFG,
Instructions, and Uses/Defs hooked up
in the Function) before we decide to let vectorizer transform (i.e., cost
modeling phase of LV), we really don't have anything
that we can use today in the LLVM infrastructure. If the collective wisdom
concludes investment into that, we are more than
happy to contribute our share of effort, but that longer term work (one year is
probably too optimistic) should not block shorter
term development of vectorizer.

More inputs from other optimizers would greatly help build up the context of
this discussion. Please speak up
if you felt similarly to us in the past. I'll be at the LLVM Conference if
anyone is interested in in-person discussions.

Thanks,
Hideki

-----Original Message-----
From: Renato Golin [mailto:renato.golin at linaro.org] 
Sent: Monday, October 16, 2017 4:59 AM
To: Hal Finkel <hfinkel at anl.gov>
Cc: Daniel Berlin <dberlin at dberlin.org>; Michael Kruse <llvmdev at
meinersbur.de>; llvm-dev at lists.llvm.org; Saito, Hideki <hideki.saito at
intel.com>; Rapaport, Gil <gil.rapaport at intel.com>; Zaks, Ayal
<ayal.zaks at intel.com>
Subject: Re: [llvm-dev] [RFC] Polly Status and Integration

On 15 October 2017 at 00:57, Hal Finkel via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> I think the way that we generally look at this is: Our IR data types 
> (Value, User, Instruction, Constant, and so on) are the most efficient 
> representation we have of the IR. There are a lot of capabilities that 
> come along with that hierarchy (use lists, value handles, metadata, 
> names). Value has a non-inline destructor to deal with all of these 
> capabilities, as does Instruction. Each individual instance of these 
> types allocate memory. The question is then: For any particular use 
> case, do you need those capabilities/properties? If not, is there a 
> more succinct representation that can be used efficiently?
There's also the case where we want *more* information than what the IR
constructs can provide us (like temporary state for the vectoriser), in which
case we can easily wrap the IR values in a small class with a pointer to the
Instruction/Value and the extra bits.

However, the current proposal for the VPlan goes well beyond that:

https://reviews.llvm.org/D38676

and makes VPValue and VPInstruction full-fledged implementations that have some
parts in common of what we already have (like Users).

I think we need to get that story right for both cases up front.

cheers,
--renato

On 17 October 2017 at 00:51, Saito, Hideki <hideki.saito at intel.com>
wrote:
> Renato, I kicked off this secondary discussion, borrowing the opportunity
from Michael's RFC,
> but to the point of reviewing https://reviews.llvm.org/D38676, I'd like
the review to proceed
> separately from this bigger (and most likely longer) discussion. We
intentionally made the interfaces
> similar such that whatever the outcome of this discussion would be, the
changes we have to make later,
> if any, is small and mechanical. We just need to agree that
>         VPValue/VPUser/VPInstruction
> is not a precedence, i.e., still subject to ongoing discussion and is
expected to abide by the eventual
> outcome of this discussion.
Agreed.

> To the best of my understanding, if we do not want to modify the IR (i.e.,
CFG, Instructions, and Uses/Defs hooked up
> in the Function) before we decide to let vectorizer transform (i.e., cost
modeling phase of LV), we really don't have anything
> that we can use today in the LLVM infrastructure. If the collective wisdom
concludes investment into that, we are more than
> happy to contribute our share of effort, but that longer term work (one
year is probably too optimistic) should not block shorter
> term development of vectorizer.
We don't want to change the IR, no.

My point was to take whatever already exists from Value and do the
rest in VPValue (same for Inst), but I don't know if that's desirable,
I was just raising the issue.

cheers,
--renato

>My point was to take whatever already exists from Value and do the rest in
VPValue (same for Inst), but I don't know if that's desirable, I was
just raising the issue.
Please continue to monitor our future patches as we expand VPInstruction usage
(we'll be sure to include you) and provide valuable feedback.

FWIW, for example, at this point, we don't think it's feasible to derive
VPInstruction from llvm::User, e.g., since we have a need to create VPUser class
instances, but as we evolve VPInstruction usage in future patches, we'll
look into such a possibility and come back to report our findings.

Thanks,
Hideki

-----Original Message-----
From: Renato Golin [mailto:renato.golin at linaro.org] 
Sent: Friday, October 20, 2017 1:50 PM
To: Saito, Hideki <hideki.saito at intel.com>
Cc: Hal Finkel <hfinkel at anl.gov>; Daniel Berlin <dberlin at
dberlin.org>; Michael Kruse <llvmdev at meinersbur.de>; llvm-dev at
lists.llvm.org; Rapaport, Gil <gil.rapaport at intel.com>; Zaks, Ayal
<ayal.zaks at intel.com>
Subject: Re: [llvm-dev] [RFC] Polly Status and Integration

On 17 October 2017 at 00:51, Saito, Hideki <hideki.saito at intel.com>
wrote:
> Renato, I kicked off this secondary discussion, borrowing the 
> opportunity from Michael's RFC, but to the point of reviewing 
> https://reviews.llvm.org/D38676, I'd like the review to proceed 
> separately from this bigger (and most likely longer) discussion. We 
> intentionally made the interfaces similar such that whatever the outcome of
this discussion would be, the changes we have to make later, if any, is small
and mechanical. We just need to agree that
>         VPValue/VPUser/VPInstruction
> is not a precedence, i.e., still subject to ongoing discussion and is 
> expected to abide by the eventual outcome of this discussion.
Agreed.

> To the best of my understanding, if we do not want to modify the IR 
> (i.e., CFG, Instructions, and Uses/Defs hooked up in the Function) 
> before we decide to let vectorizer transform (i.e., cost modeling 
> phase of LV), we really don't have anything that we can use today in 
> the LLVM infrastructure. If the collective wisdom concludes investment into
that, we are more than happy to contribute our share of effort, but that longer
term work (one year is probably too optimistic) should not block shorter term
development of vectorizer.
We don't want to change the IR, no.

My point was to take whatever already exists from Value and do the rest in
VPValue (same for Inst), but I don't know if that's desirable, I was
just raising the issue.

cheers,
--renato