[LLVMdev] Replacing Platform Specific IR Codes with Generic Implementation and Introducing Macro Facilities
Renato Golin
renato.golin at linaro.org
Sat May 10 13:17:15 PDT 2014
On 10 May 2014 13:53, Tim Northover <t.p.northover at gmail.com> wrote:
> It doesn't make sense for everything though, particularly if you want
> target-specific IR to simply not exist. What would you map ARM's
> "ldrex" to on x86? Or an inline assembly block?
Another class of problems is ABI compatibility. While procedure calls
could generally be dealt with by an IR wrapper, different languages
have different meanings for structures, bitfields, unions, lists.
If the IR has only one type of "structure", padding and casts have to
be made to accommodate language ABIs. If the IR has only one type of
"bitfield", it'll behave differently on different architectures and
there will be no way to represent it in the IR, unless you introduce
target specific attributes.
LLVM IR is not the same as Java bytecode. It doesn't have the same
purpose, and making it more like bytecode will make it harder to
reason about intermediate level semantics.
There is a number of things that could be simplified with IR-wrappers
to lower high-level IR (target independent) into low-level IR (target
specific), which would make it a lot easier to port IR between
architectures, but I don't believe it's possible to do that to *all*
classes of architectural problems that we currently have without
transforming it into something like the Java bytecode.
Even though "virtual machine" is part of the name, the focus on
running IR on a virtual machine is ancient history. There are still
many people doing it, but LLVM is now much more a compilation
infrastructure than anything else. Kind of "build your own compiler"
or "mix-and-match".
cheers,
--renato
More information about the llvm-dev
mailing list