[LLVMdev] "Mapping High-Level Constructs to LLVM IR" Github URL

[Mikael Lyngvig]

Hi Chris,

I just had the joy of reading Regehr's and your articles on undefined
behavior in C and C++.  Thank you for those.  They sort of put words on
things that I have felt for a decade or so - that C and C++ are too unsafe
languages to be used in all but the most "masochistic" environments (sorry,
you guys who love C++ out there - please don't get offended just because I
personally happen to have grown very tired of the C/C++ universe long ago,
I once lived and breathed C and C++ like you do now!).

Anyways, I just wanted to suggest something that I have been doing for a
few decades.  And that is to increase the reliability of the output program
by using at least four different compilers.  Not three times GNU and one
time MSVC, but four different vendors' compilers.  I believe LLVM already
does this, but I also know of many projects that do the "fatal" mistake of
tying themselves in with a single compiler, like MSVC, and then sort of
lean on the implied behavior in undefined cases.  Obviously, such projects
are in for a rough ride the first time they ever get ported to another
compiler.

Like I always say: Windows didn't become stable until the time that
Microsoft was forced, by business plans, into porting Windows to four
different architectures.  And the same goes with many software projects
that only use a single compiler on a single platform - they are, in your
words, mines waiting to explode.

I'm confident that you know all this well, but you write "There is No
Reliable Way to Determine if a Large Codebase Contains Undefined Behavior".
 True indeed, but if you use 4+ compilers, perhaps combined with building
on both big-endian and little-endian platforms, and do both debug and
release builds, you get much closer to the magic point where you can
actually sleep soundly knowing that your code is mostly okay :-)


-- Mikael


2013/12/4 Chris Lattner <clattner at apple.com>

>
> On Nov 28, 2013, at 6:07 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote:
>
> Hi,
>
> It will probably take a few weeks or a month before the "Mapping
> High-Level Constructs to LLVM IR" document is ready for prime time.  Until
> then, you can review and study it at this URL:
>
>
> https://github.com/archfrog/llvm-doc/blob/master/MappingHighLevelConstructsToLLVMIR.rst
>
>
> Please notice that I specifically do not advocate reviewing the document
> for a week or two.  But feel free to give me any feedback, comments, and
> criticism that you may have to share.
>
>
> This looks really awesome!  Great idea starting this, and thank you for
> pushing it forward.  Some thoughts:
>
> - In "local variables", it would be great to talk about how the "alloca
> trick" avoids forcing your frontend to build SSA.  You could even include
> an example.
>
> - In the "constants" section, it is probably best to say that "constants
> that allocate memory" are just global variables in LLVM IR, marked with the
> 'constant' keyword.  It would also be great to mention constant exprs here,
> since they are a point of confusion (and you introduce them in sizeof).
>
> - Having something that talks about lowering C-style unions to llvm IR
> would be great :-)
>
> - A nice new top-level section would be "interoperating with a runtime
> library", pointing out that not everything needs to be emitted as inline
> LLVM IR: a frontend can either just call into a runtime library, or it can
> even emit a call to a runtime library (whose body is also available as IR)
> and then have the optimizer inline it if run.
>
>
> Once the document has been finalized and comitted to LLVM, I'll delete the
> repository at Github - or, perhaps even better, simply make a small page
> that refers to the official copy in LLVM.
>
>
> Are you interested in just building it in llvm.org/docs?  Unless your
> workflow is better on github, it seems easier to do it on llvm.org - it
> would make it easier for other people to chip in.
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131204/bb9a65e4/attachment.html>