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

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, e.g.
removing/inserting an instruction just requires updating a linked
list.

Michael

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171014/ad90acac/attachment.html>

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>