llvm dev - Oct 2016 - What was the IR made for precisely?

Thank you for your answers.

In fact I'm still hesitating between C and C++, sorry for my incomplete
message. What I want to write is some sort of DSL; so I can afford both I think.
I'm thinking about generating standard-compliant code using numeric limits
and stuff; given that I don't care about compilation time or debugging, I
think I can still use C++ in case I decide to include exceptions or other things
hard to implement in C.

I understood from your replies that I still have a small part of target specific
code to write, but honestly I don't know about all the main targets enough
to do this correctly and efficiently I think. I would need to sum up all the
rules and ABIs and sizes for all the targets I need and generate different IR
for each, am I correct? I don't even know if there are many off such rules,
or even where they are all defined precisely. I have used assembly and read
processor manuals etc before but that was obviously never for writing cross
platform code.

On 28 Oct 2016, at 02:43, ジョウェットジェームス <b3i4zz1gu1 at docomo.ne.jp>
wrote:
> 
>  I would need to sum up all the rules and ABIs and sizes for all the
targets I need and generate different IR for each, am I correct?
This is a long-known limitation of LLVM IR and there are a lot of proposals to
fix it.  It would be great if the LLVM Foundation would fund someone to do the
work, as it isn’t a sufficiently high priority for any of the large LLVM
consumers and would make a huge difference to the utility of LLVM for a lot of
people.

David

> On Oct 28, 2016, at 1:21 AM, David Chisnall via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 28 Oct 2016, at 02:43, ジョウェットジェームス <b3i4zz1gu1 at docomo.ne.jp>
wrote:
>> 
>> I would need to sum up all the rules and ABIs and sizes for all the
targets I need and generate different IR for each, am I correct?
> 
> This is a long-known limitation of LLVM IR and there are a lot of proposals
to fix it.  It would be great if the LLVM Foundation would fund someone to do
the work, as it isn’t a sufficiently high priority for any of the large LLVM
consumers and would make a huge difference to the utility of LLVM for a lot of
people.
It seems to me that it could be a good fit for the scope of a GSoC project.

— 
Mehdi

On 28 October 2016 at 02:43, ジョウェットジェームス <b3i4zz1gu1 at docomo.ne.jp>
wrote:
> Thank you for your answers.
>
> In fact I'm still hesitating between C and C++, sorry for my incomplete
> message. What I want to write is some sort of DSL; so I can afford both I
> think.
> I'm thinking about generating standard-compliant code using numeric
limits
> and stuff; given that I don't care about compilation time or debugging,
I
> think I can still use C++ in case I decide to include exceptions or other
> things hard to implement in C.
>
So, you basically don't care if you can debug your DSL at all? It's
actually quite nice to NOT have to add code to print value of X during
debugging, or type "bt" to see how you got to a crash-point - but I
got a
long way in my compiler project before I started adding debug symbol
support. However, if you EVER want to add that, it's MUCH easier to achieve
that in LLVM-IR than in C - and if you machine generate C, it can be very
hard to follow what of the C code is what of the original language
(depending on how different they are, and what happens during the
translation - I have seen 50k lines in one function being the result of a
"generate C code" project, and none of the generated variables had
sensible
names, they were just called a1, a2, a3, ... a9345 ... a12345 or some such
- there were some struct fields with names from the original input, but
everything else was just meaningless - it was also completely unformatted -
do try to format the output code for human readability, if you can).

> I understood from your replies that I still have a small part of target
> specific code to write, but honestly I don't know about all the main
> targets enough to do this correctly and efficiently I think. I would need
> to sum up all the rules and ABIs and sizes for all the targets I need and
> generate different IR for each, am I correct? I don't even know if
there
> are many off such rules, or even where they are all defined precisely. I
> have used assembly and read processor manuals etc before but that was
> obviously never for writing cross platform code.
>
LLVM-IR is less target-specific than assembler, and more so than C or C++ -
the biggest difference is that uses specific types of 1, 8, 16, 17, 32, 36
or 64 bit integer types, so you need to KNOW what size integer you want for
some function call. If you are interfacing your DSL to some existing
libraries or OS's (and other such things), then perhaps a solution would be
to write an interface library in C or C++, that uses a fixed ABI, and let
the C compiler deal with the conversions there. This is how I've solved
such problems in my Pascal compiler for things like text and binary
file-I/O functions, some math functions, and so on, that are hard to
implement in Pascal, and also hard to write as LLVM-IR (not necessarily for
size and ABI functionality, but simply that "it's a fair bit of code to
write").

--
Mats
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161028/4691e14a/attachment.html>

> On Oct 28, 2016, at 1:21 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> 
> On 28 Oct 2016, at 02:43, ジョウェットジェームス <b3i4zz1gu1 at docomo.ne.jp>
wrote:
>> 
>> I would need to sum up all the rules and ABIs and sizes for all the
targets I need and generate different IR for each, am I correct?
> 
> This is a long-known limitation of LLVM IR and there are a lot of proposals
to fix it.  It would be great if the LLVM Foundation would fund someone to do
the work, as it isn’t a sufficiently high priority for any of the large LLVM
consumers and would make a huge difference to the utility of LLVM for a lot of
people.
…
> I think it would be difficult to do it within the timescale of the GSoC
unless the student was already an experienced LLVM developer.  It would likely
involve designing some good APIs (difficult!), refactoring a bunch of Clang
code, and creating a new LLVM library.  I’ve not seen a GSoC project on this
scale succeed in any of the open source projects that I’ve been involved with. 
If we had a good design doc and a couple of engaged mentors then it might stand
a chance.
Is there a specific design that you think would work?  One of the major problems
with this sort of proposal is that you need the entire clang type system to do
this, which means it depends on a huge chunk of the Clang AST.  At that point,
this isn’t a small library that clang uses, this is a library layered on top of
Clang itself.

-Chris