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

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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171014/06c157fc/attachment.html>

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

>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

(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> 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>
> wrote:
>
>> 2017-10-14 5:03 GMT+02:00 Daniel Berlin <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 listllvm-dev at
lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171016/1412a8fc/attachment.html>

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>