derek.holloway
7502bf64a4
CodeQL / Analyze (actions) (push) Canceled after 0s
CodeQL / Analyze (python) (push) Canceled after 0s
pre-commit / pre-commit (push) Canceled after 0s
Multi-Arch CI / setup (push) Canceled after 0s
Publish build_manylinux_x86_64 images / publish_build_manylinux_x86_64 (push) Canceled after 0s
Setup (Multi-Arch) / setup (push) Canceled after 0s
Multi-Arch CI / Linux::${{ fromJSON(needs.setup.outputs.linux_build_config || '{}').build_variant_label || 'skip' }} (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Publish no_rocm_image_ubi10 image / publish_no_rocm_image_ubi10 (push) Canceled after 0s
Multi-Arch CI / Windows::${{ fromJSON(needs.setup.outputs.windows_build_config || '{}').build_variant_label || 'skip' }} (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Multi-Arch CI / Manifest Diff (push) Canceled after 0s
TheRock Manifest Diff Report / Generate Manifest Diff Report (push) Canceled after 0s
Multi-Arch CI / CI Summary (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04 (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04_ocl_rt images / publish_no_rocm_image_ubuntu24_04_ocl_rt (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04_rocgdb (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04_rocgdb images / publish_no_rocm_image_ubuntu24_04_rocgdb (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04_ocl_rt (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Unit Tests / Unit Tests :: ubuntu-24.04 (push) Canceled after 0s
Unit Tests / Unit Tests :: windows-2022 (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04_media (push) Canceled after 0s
Unit Tests / Unit Tests Summary (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04_openmpi (push) Canceled after 0s
48 lines
2.2 KiB
Plaintext
48 lines
2.2 KiB
Plaintext
Date: Tue, 13 Feb 2001 18:25:42 -0600
|
|
From: Vikram S. Adve <vadve@cs.uiuc.edu>
|
|
To: Chris Lattner <sabre@nondot.org>
|
|
Subject: RE: LLVM Concerns...
|
|
|
|
> 1. Reference types
|
|
> Right now, I've spec'd out the language to have a pointer type, which
|
|
> works fine for lots of stuff... except that Java really has
|
|
> references: constrained pointers that cannot be manipulated: added and
|
|
> subtracted, moved, etc... Do we want to have a type like this? It
|
|
> could be very nice for analysis (pointer always points to the start of
|
|
> an object, etc...) and more closely matches Java semantics. The
|
|
> pointer type would be kept for C++ like semantics. Through analysis,
|
|
> C++ pointers could be promoted to references in the LLVM
|
|
> representation.
|
|
|
|
|
|
You're right, having references would be useful. Even for C++ the *static*
|
|
compiler could generate references instead of pointers with fairly
|
|
straightforward analysis. Let's include a reference type for now. But I'm
|
|
also really concerned that LLVM is becoming big and complex and (perhaps)
|
|
too high-level. After we get some initial performance results, we may have
|
|
a clearer idea of what our goals should be and we should revisit this
|
|
question then.
|
|
|
|
> 2. Our "implicit" memory references in assembly language:
|
|
> After thinking about it, this model has two problems:
|
|
> A. If you do pointer analysis and realize that two stores are
|
|
> independent and can share the same memory source object,
|
|
|
|
not sure what you meant by "share the same memory source object"
|
|
|
|
> there is
|
|
> no way to represent this in either the bytecode or assembly.
|
|
> B. When parsing assembly/bytecode, we effectively have to do a full
|
|
> SSA generation/PHI node insertion pass to build the dependencies
|
|
> when we don't want the "pinned" representation. This is not
|
|
> cool.
|
|
|
|
I understand the concern. But again, let's focus on the performance first
|
|
and then look at the language design issues. E.g., it would be good to know
|
|
how big the bytecode files are before expanding them further. I am pretty
|
|
keen to explore the implications of LLVM for mobile devices. Both bytecode
|
|
size and power consumption are important to consider there.
|
|
|
|
--Vikram
|
|
|