llvm dev - May 2014 - [LLVMdev] Replacing Platform Specific IR Codes with Generic Implementation and Introducing Macro Facilities

Hi,

This might sound a bit controversial at this stage of maturity for LLVM.
Can the community consider deprecating architecture specific features which
has come into the IR and replacing them with more generic IR codes.

Also some form of powerful macro facility which supports platform specific
macros which can be used to expand generic IRs to a set of IRs which might
have equivalent results and / or the platform specific implementation of
it.

The aim would be that any code in LLVM IR can execute in any architecture
and will get the best possible optimisation and full set of functionality
being available in each architecture.

 Suminda
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140510/69aff738/attachment.html>

On 10 May 2014 12:57, Suminda Dharmasena <sirinath at sakrio.com>
wrote:
> This might sound a bit controversial at this stage of maturity for LLVM.
Can
> the community consider deprecating architecture specific features which has
> come into the IR and replacing them with more generic IR codes.
On a case-by-case basis, certainly. I'm very much in favour of general
mechanisms so that work doesn't have to be duplicated on all targets.

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?
> Also some form of powerful macro facility which supports platform specific
> macros which can be used to expand generic IRs to a set of IRs which might
> have equivalent results and / or the platform specific implementation of
it.
LLVM IR isn't really for humans to write, so macros would likely not
be a popular idea. Reusable APIs to emit the correct target-specific
IR for features would probably be the LLVM equivalent.

We keep meaning to write one to handle the details of emitting
functions compliant with C ABIs, for example.
> The aim would be that any code in LLVM IR can execute in any architecture
> and will get the best possible optimisation and full set of functionality
> being available in each architecture.
Have you looked at what the PNaCl people are doing? As I recall they
have something close to a generic subset of LLVM IR which they then
compile to the various native object formats (they don't care about
matching any particular ABI except their own).

There's inevitably some kind of speed penalty, but I really like the idea.

Cheers.

Tim.

Some target specific IRs do not make sense in other platforms. Perhaps they
should be removed from LLVM but only generated through compilation process.
Speed penalties should be handled by intelligent compilation. It would be
helpful if all the IRs were abstract than you have platform specific IRs.
The final compilation step has more flexibility this way and also more
optimisation can be done optimise. (There could be more efficient
alternatives than explicitly using thus forcing the specific platform
specific ASM.) How I see platform specific IRs is like "register" or
"inline" in C++. With clever compilation techniques they are not
needed and
the compiler can do a better job. Perhaps this should be something to be
explored in the long run.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140510/c4b8666f/attachment.html>

On 10 May 2014, at 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? 
This isn't a great example.  Having load-linked / store-conditional in the
IR would make a number of transforms related to atomics easier.  We currently
can't correctly model the weak compare-and-exchange from the C[++]11 memory
model and we generate terrible code for a number of common atomic idioms on
non-x86 platforms as a result.

David

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