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

[Hal Finkel via llvm-dev]

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>