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

[Saito, Hideki via llvm-dev]

>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