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

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.

All this is to say that I’d prefer to avoid tying it into Value just because
that is an expedient way to get something done.  If tying into Value is the
“right” thing to do for some reason then that is a completely different story.

-Chris




> On Oct 16, 2017, at 5:33 PM, Daniel Berlin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> (I have no beef with using Value, FWIW)
> I believe one of the objections is, for example, lib/IR should not have to
depend on, say, lib/Analysis, which it does if you extend value ;)
> I'm more surfacing the objections i've heard from others, than ones
i have myself.
> I'll forward this thread to them and let them speak for themselves if
they want
>  
> 
> On Sat, Oct 14, 2017 at 4:57 PM, Hal Finkel <hfinkel at anl.gov
<mailto:hfinkel at anl.gov>> wrote:
> 
> On 10/14/2017 05:28 PM, Daniel Berlin via llvm-dev wrote:
>> 
>> 
>> On Sat, Oct 14, 2017 at 2:54 PM, Michael Kruse <llvmdev at
meinersbur.de <mailto:llvmdev at meinersbur.de>> wrote:
>> 2017-10-14 5:03 GMT+02:00 Daniel Berlin <dberlin at dberlin.org
<mailto:dberlin at dberlin.org>>:
>> > FWIW: We hit a subset of this issue with MemorySSA (which
subclasses value
>> > for the MemoryAccess's, etc), and it was discussed as well
during
>> > PredicateInfo.
>> >
>> > NewGVN has a variant the same issue as well, where it actually
creates
>> > unattached (IE not in a basic block) new instructions just so it
can analyze
>> > them.
>> >
>> > IMHO, some nice way to make virtual forms over the instructions
that didn't
>> > require reimplementing the tons of existing functionality that
works with
>> > Value would be much appreciated.
>> >
>> > But maybe the right answer at some point is to just sit down and
build out
>> > such an infrastructure. It certainly sounds like there are enough
clients.
>> 
>> What would be different in such an infrastructure? IMHO the
>> llvm::Value hierarchy is already relatively thin,
>> 
>> I think most people would disagree with "Relatively thin".
>> Given there have also been multiple threads in the past year with most
people not wanting non-actual-IR to derive from Value, i think you may be in the
minority here.
> 
> 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?
> 
>  -Hal
> 
>> 
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20171016/22d49eaf/attachment.html>

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

>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