[LLVMdev] LLVM IR is a compiler IR

[Duncan Sands]

Hi Óscar,

> There are places where compatibility with the native C ABI is taken too
> far. For instance, time ago I noted that what the user sets through
> Module::setDataLayout is simply ignored.

it's not ignored, it's used by the IR level optimizers.  That way these
optimizers can know stuff about the target without having to be linked
to a target backend.

  LLVM uses the data layout
> required by the native C ABI, which is hardcoded into LLVM's source
> code. So I asked: pass the value setted by Module::setDataLayout to the
> layers that are interested on it, as any user would expect.

There are two classes of information in datalayout: things which correspond
to stuff hard-wired into the target processor (for example that x86 is little
endian), and stuff which is not hard-wired in (for example the alignment of
x86 long double, which is 4 or 8 bytes on x86-32 depending on whether you are
on linux, darwin or windows).  Hoping to have code generators override the
hard-wired stuff if they see something different in the data layout is just
too much to ask for - eg the x86 code generators are never going to produce big
endian code just because you set big-endianness in the datalayout.  Even the
second class of "soft" parameters is not completely flexible: for example most
processors enforce a minimum alignment for types, and trying to reduce it by
giving types a lesser alignment in the datalayout just isn't going to work.
So given that the ways in which codegen could adapt to various datalayout
settings are quite limited and constrained by the target, does it really make
sense to try to parametrize the codegenerators by the datalayout at all?
In any case, it might be good if the code generators produced a warning if they
see that the datalayout string doesn't correspond to what codegen thinks it
should be (I though someone added that already?).

Ciao, Duncan.

  The response
> I got was, in essence, "As you are not working on C/C++, I couldn't care
> less about your language's requirements." So I have a two-line patch on
> my LLVM local copy, which has the effect of making the IR code generated
> by my compiler portable across Linux/x86 and Windows/x86 (although that
> was not the reason I wanted the change.)
>
> So it is true that LLVM IR has portability limitations, but not all of
> them are intrinsic to the LLVM IR nature.
>
> [snip]
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev