[LLVMdev] LLVM IR is a compiler IR

[Óscar Fuentes]

Hello Duncan.

Duncan Sands <baldrick at free.fr> writes:

> it's not doing what *you* expect: it doesn't match your mental model of what
> it is for (or should be for).  The question is whether LLVM should be changed
> or your expectations should be changed.  Just observing the mismatch between
> your expectations and current reality is not in itself an argument that LLVM
> should be changed.

I see Module:setDataLayout, look at the documentation for the method,
see "Set the data layout" and think "gee, this is for setting the data
layout." I have no reason for thinking that the setting is only used on
parts of LLVM and ignored on others.

>> You focus your reasoning on possible wrong uses of the data layout
>> setting (endianness) when, as you say, there are other uses which are
>> perfectly legit (using a specific alignment within the limits allowed by
>> the processor.)  So if I need to align my data on a different way of
>> what the C ABI requires or generate code for a platform that LLVM still
>> does not know about, my only solution is to patch LLVM because the value
>> setted through one of its APIs is ignored on key places, as LLVM assumes
>> that everybody wants full interoperability with C. This is the kind of
>> logic that tells me that LLVM is a C-obsessed project: any requirement
>> that falls outside the needs of a C compiler writer is seen as
>> superfluous even if it does not conflict with the rest of LLVM.
>
> You are talking to the wrong person: I pretty much only use Ada not C, so I
> don't think I'm C obsessed.  Yet I never had any problems using LLVM
> with Ada.

I guess that your Ada compiler is required to be compatible with the
platform's C ABI, then.

> LLVM gives you several mechanisms for aligning things the way you
> like.

My problem is with the aligment of struct members. The programmer's
guide says that I can create packed structs (1-byte aligned) and

"In non-packed structs, padding between field types is inserted as
defined by the TargetData string in the module, which is required to
match what the underlying processor expects."

which is not true, unless "TargetData string" refers to what is
hard-coded into the LLVM backend, not to what is setted by
Module::setDataLayout. In any case, a clarification is highly needed
both on the method's documentation and on the programmer's guide.

It is true that I could pack all structs generated by my compiler and
insert padding as necessary, but this is really undesirable.

> Are
> they inadequate?  Do you have a specific example of something you find
> problematic?

My compiler generates intructions for a virtual stack machine. It is
required to work wherever a good enough C++ compiler is available, with
no further intervention, so the arrangement of members in structures
assume a fixed data layout wich is conservative enough to not violate
any reasonable processor rules. The next key factor is that the language
allows execution of arbitrary code at compile-time (think of a Lisp-like
macro system) which includes the possibility of creating instances of
structs (not to confuse with C structs, which my implementation accesses
only through accessor functions.)  Enter LLVM. As LLVM generates code
following the platform's C ABI, which is not necessarily the same as
what my compiler assumes, whenever code generated by LLVM accesses
structures instantiated by running code at compile-time (which was
executed by the virtual stack machine) nasty things happen.