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

[Daniel Berlin via llvm-dev]

(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>