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

[Saito, Hideki via llvm-dev]

>one could construct a 1:1 relationship between them and vectorized IR instructions.

Doesn't have to be 1:1 to the output widened IR instruction sequences as long as cost modeling (inside vectorizer and also hopefully downstream
optimizers) can be done properly.

Earlier study in "Vector Idioms" study group (loosely formed as a result of 2016 Dev Con Hackers Lab, had active e-mail discussions in Q1/Q2) found
that LLVM already handles multiple forms of some of the common idiomatic forms (e.g., ABS). As such, we semi-concluded that having a utility to
capture all the different sequences of the same idiom is more important than trying to come up with a single "canonical form" and try to preserve it
---- as long as the complexity of the utility is reasonable. Such a utility should also help in this context (i.e., inside vectorizer and downstream optimizers).

>>If tying into Value is the “right” thing to do for some reason

In some sense, we are trying the opposite from the historical example ------ start from untied version and see whether the rest of the community thinks
tying is the "right" thing to do, at any moment of the evolution of the untied version. For that, we will try to keep the interface as identical as possible
such that the cost of tying back, if such time ever comes, is minimal ---- and also template based code sharing idea can be kept open that way if we aren't
completely tying.

Thanks,
Hideki

-----Original Message-----
From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com] On Behalf Of Michael Kruse
Sent: Monday, October 16, 2017 10:58 PM
To: Chris Lattner <clattner at nondot.org>
Cc: Daniel Berlin <dberlin at dberlin.org>; llvm-dev at lists.llvm.org; Saito, Hideki <hideki.saito at intel.com>
Subject: Re: [llvm-dev] [RFC] Polly Status and Integration

2017-10-17 7:37 GMT+02:00 Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>:
> Disclaimer: I haven’t been following this discussion closely, nor do I 
> know what is going on in the modern AA/MemorySSA/GVN infra, but:
>
> I’d prefer to avoid abusing the Value* class hierarchy if reasonable.
> Adding new subclasses that only occur in special cases makes it more 
> difficult to reason about what can occur and when.  A historical 
> example that always grated against my sensibilities was 
> CodeGen/PseudoSourceValue, which originally inherited from Value in 
> order to make it “fit better” into the AA infra.  Thankfully Nick 
> Lewycky broke that tie back in a patch on Tue Apr 15 07:22:52 2014, and the codebase has been better off for that change.

The idea I was proposing is to move instructions to different places because it helps some kinds of analyses, but could be more expensive to executes there. This could also be undone again by passes such as GVN and LICM. Would this also be an abuse of the IR? It does not involve extending the llvm::Value hierarchy.

This is different for VPlan. VPRecipe has its own class hierarchy (VPRecipeTy), but I am not sure whethere one could construct a 1:1 relationship between them and vectorized IR instructions.

Michael