gmane.comp.compilers.llvm.devel

Re: vmkit: Getting Started

Nicolas Geoffray — 2012-05-24T06:55:21

Hi Patrick,

On Thu, May 24, 2012 at 2:18 AM, Patrik Plihal <patrik.plihal< at >gmail.com>wrote:


The problem seems to be  that llvm does not compile with gcc 4.7. Could you
try an earlier version of gcc?

Nicolas

                                          ^
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Re: Windows question: Dozens of linker warnings and errors

Albert Graef — 2012-05-24T05:07:40

I can confirm this. Even if you do need to interface to C/C++, clang
works fine for that as long as you stick to the mingw libraries instead
of msvc. There are already a number of full-blown LLVM-based language
projects by 3rd parties you can take a look at, see
http://llvm.org/releases/3.1/docs/ReleaseNotes.html#externalproj.

Speaking about my own project (http://pure-lang.googlecode.com/), we've
had that up and running on Linux, *BSD, OS X and Windows at least since
the days of LLVM 2.5, using first llvm-gcc and then clang as an
LLVM-capable C/C++ compiler for inlining C/C++ in Pure. I vaguely recall
some issues with clang 3.0 on Windows due to hardcoded paths. But clang
2.9 has been working great on Windows for me and other Pure users,
hopefully 3.1 will be the same.

Albert

LTO for smaller memory footprint for Clang

ankur deshwal — 2012-05-24T04:34:46

Hi all,

I was trying to use LTO facility of LLVM to reduce the footprint of
Clang itself. I build the ld-gold and LLVMgold.so as described at [1]
and then set the environment as described too. However, had to add the
path for plugin manually as Clang was not able pass it to ld
automatically. Following is the setting I used before starting to
build (small foot Clang.

CXX=clang++ -flto
-Wl,--plugin=/home/wer/llvm-3.0/build_config_gold_release/Release/lib/LLVMgold.so
CFLAGS=-O3
CC=clang -flto -Wl,--plugin=/home/wer/llvm-3.0/build_config_gold_release/Release/lib/LLVMgold.so
RANLIB=/bin/true

Then configured and did the build for LLVM. While building Clang tool,
there may be large part of LLVM/Clang libraries which are not used by
Clang. So I was expecting appreciable reduction in size for Clang.
However memory savings were minimal.

Also, as explained in [2] in the topic "Compiler driver invokes link
time optimizer separately." , there are many cases when invoking Clang
with -flto may not remove the dead code. However I cannot figure out
how to build the Clang with first compiling all files to LLVM bit code
and then allow linker to treat them as compiled binaries which can be
linked together with LTO pass.

If this is possible by changes in Makefiles or build system, it can
help me a lot in removing some generic parts in Clang too to make a
less generic but lighter compiler tool.

Please help me with the same.

Thanks,
Ankur

[1] http://llvm.org/docs/GoldPlugin.html
[2] http://llvm.org/docs/LinkTimeOptimization.html

Tips for using clang v3.1 on Windows

Mikael Lyngvig — 2012-05-24T02:32:15

Here are the results of me playing around with the new EXPERIMENTAL release
v3.1 of clang for Windows using MinGW32:

   0. You don't need to go through the nightmare of building clang v3.1
yourself - it is right there on the download page, albeit at the very
bottom.
   1. Install MinGW32 in the directory C:\MinGW and nowhere else.
 Otherwise you'll get all sorts of errors about missing include files and
nothing will work at all.
   2. Install all of MinGW32 - MSYS and all of the packages, just to be
sure it all works.
   3. Install Clang in a directory without spaces in it (as the clang docs
say).
   4. Add both c:\MinGW\bin and clang's bin directory to your path using
the PATH command: path
c:\tmp\clang-3.1-win32-mingw32\bin;c:\MinGW\bin;%path%
   5. Be prepared to have to edit your source files a little as MinGW32 is
not entirely Microsoft compatible (there's no GetFileSizeEx() function, for
instance).
   6. Remember to use MinGW's ranlib, not llvm-ranlib, when you create an
indexed archive.  The latter won't work and MinGW's ld will reject the
library.

Sample session:

    clang++ -c -o a.o a.cpp
    clang++ -c -o b.o b.cpp
    llvm-ar rcs Test.lib a.o b.o
    ranlib Test.lib
    clang++ -o c.exe c.cpp Test.lib

Other than that, I have no comments.  I managed to build a support library
without problems and the module tests ran without any problems.  I have not
yet had time to play around with LLVM v3.1.

P.S. Thank you guys, it is wonderful that you are now (again) making a
binary release for Windows.  I think it is the first step in getting rid of
the EXPERIMENTAL tag :-)
P.P.S. And a quick, voiced prayer that we'll one day see a distro of clang
for MinGW64 as well.  If I ever figure out how to build it, I'd be happy to
build it for release purposes.


Cheers,
Mikael
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

About the result of getPointerSizeInBits();

空明流转 — 2012-05-24T01:43:33

Hi guys,

Does getPointerSizeInBits need to return sizeof(void*) in Platform?
I found that getPointerSizeInBits return 8 in x86-32 on win7-64, MSVC 2010.

And if I have a struct { i32, i32* }; the structLayout->getElementOffset(1)
return 8, but I think 4 is right.
In generated ASM, the offset of second element is 4.

Thanks.

Re: Windows question: Dozens of linker warnings and errors

Michael Spencer — 2012-05-24T01:37:02

It should be trivial. Clang already parses it. It just needs to get
hooked up to the attribute system, as we already support the gnu
version of it (I believe alwaysinline).


People are actively working on it, but I have no idea when it will be ready.


LLVM already supports Windows quite well. The issue is clang and the
MS C++ ABI. If you are writing your own language that does not need to
interact with the C++ ABI then everything will be fine.


Increasing support for Windows across LLVM is a welcome addition. My
main area on LLVM currently is actually binary tools, and adding
object file support to llvm-ar is one of the items on my list. You may
also be interested in the lld linker project (lld.llvm.org).


- Michael Spencer

_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Re: Windows question: Dozens of linker warnings and errors

Mikael Lyngvig — 2012-05-24T01:12:20

Thanks for the quick reply.  I had a feeling that it was due to missing
Windows support in clang++ and LLVM.

"""
This is due to clang not understanding force_inline. These functions
are defined in a header included from Windows.h, so it ends up getting
a definition everywhere it is included.
"""

How much work would it take to add support for force_inline?  Are there any
plans for when/if it will be supported?  I don't know anything about
force_inline, but I guess supporting it is a relatively simple matter.
 After all, isn't a forced_inline construct similar to an inlined template
method?  In the old MS-OMF days, we'd start talking about COMDATs and stuff
like that, but I don't know how it is done nowadays.

"""
The rest of the issues are due to clang not supporting the Microsoft
C++ ABI yet. To use clang on Windows for C++ code you will need to use
it with MinGW as it provides libraries that use the GNU C++ ABI.

"""
I guess this is quite a mouthful, but when do you roughly expect the
Microsoft C++ ABI to be supported?  v4.0 or later?  Is there anything not
too overwhelming and/or complex that I can do to speed up this process?

I am asking these questions because I see myself as a wannabe client of the
LLVM tools - I don't know much about code generation and I don't really
want to know much about it, all I want to do is to make my own production
language using LLVM as the portable (also to Windows/M$) backend.  My hope
is that LLVM can save me the hassles of meddling around with assembler and
so on, as I'd much rather spend my energy on my language.  But if the
Windows support is broken, partial beyond use, or never to be finished up,
I cannot use LLVM.  Then I'd have spend my energy on writing my own simple
code generator, which would never generate code of a quality anywhere near
LLVM.  Or, I could go ahead and do my own silly backend and then check up
on LLVM in a couple of years, to see if the Windows support was matured.

By the way, I do have a background in linkers and compilers for Windows
platforms, so if I can help with anything, I'll be glad to do so.  Just
don't expect me to work miracles from day one because it has been almost 15
years since I last worked with compilers and linkers.

Perhaps I can contribute in the field of Windows support?   I once wrote a
librarian for OMF (the ancient object file format used under DOS) and COFF.
 I could probably add support for COFF archives to llvm-ar, if need be.
 And stuff like that.


Sincerely,
Mikael
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Re: Windows question: Dozens of linker warnings and errors

Michael Spencer — 2012-05-24T00:19:21

This is due to clang not understanding force_inline. These functions
are defined in a header included from Windows.h, so it ends up getting
a definition everywhere it is included.


The rest of the issues are due to clang not supporting the Microsoft
C++ ABI yet. To use clang on Windows for C++ code you will need to use
it with MinGW as it provides libraries that use the GNU C++ ABI.

- Michael Spencer

_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

vmkit: Getting Started

Patrik Plihal — 2012-05-24T00:18:20

Hi,

I recently tried to follow the instructions on
    http://vmkit.llvm.org/get_started.html

but all I get is

Re: problem on clang+gold

Guoliang Jin — 2012-05-23T23:55:25

Sebastian's approach is able to let clang to pick gcc-4.4.6. Thanks.

I have not tried Wei-Ren's suggestion yet.

Now the problem seems to be the bug mentioned here:http://llvm.org/bugs/show_bug.cgi?id=5960

Seem std=C89 is a workaround for this.

Windows question: Dozens of linker warnings and errors

Mikael Lyngvig — 2012-05-23T23:38:05

Hi again again,

I'm trying to build my compiler frontend in C++ on Windows 7 x64 using
clang++.exe.  I want to use clang++ for my project so that I get a feel for
how mature and usable the Windows support is as I gradually get up to speed
with LLVM for Windows.  I could develop on Linux, but I need the Windows
support so I figure I might as well do it the hard way.

My code is fairly simple C++ with a few template classes, a rare virtual
function, and nothing very fancy.  I am able to compile my code without
warnings (although clang++ earlier on found a couple of very serious issues
in my code).  But when I get to the link phase, all hell breaks loose:

I get a ton of these warnings:

Memory.o : warning LNK4006: _InterlockedBitTestAndSet already defined
in Stream.o; second definition ignored
Memory.o : warning LNK4006: _InterlockedBitTestAndReset already
defined in Stream.o; second definition ignored
Memory.o : warning LNK4006: _InterlockedBitTestAndComplement already
defined in Stream.o; second definition ignored
Memory.o : warning LNK4006: _MemoryBarrier already defined in
Stream.o; second definition ignored
Memory.o : warning LNK4006: _ReadPMC already defined in Stream.o;
second definition ignored

I don't use InterlockedBitTestAndSet anywhere in my code and the same goes
for the rest of the symbols that are being warned about.

After that, I get a ton of errors form the linker because it complains
about the above symbols already being defined.

I also get a few errors like this:

Bitset_test-423377.o : error LNK2001: unresolved external symbol
__ZTVN10__cxxabiv120__si_class_type_infoE

Any ideas?  Is the Windows support simply not mature enought for real use
or am I doing something wrong?  I invoke the linker through clang++ by
giving the input object files and a library that must be linked against,
made with Microsoft's LIB tool.  I use Microsoft LIB because LINK rejects
libraries created using llvm-ar.

I only use the -c, -o, -v, and -D options to clang++.exe and nothing else.
 Nothing advanced yet.

Is it that clang++/Windows simply don't support the use of libraries yet?
 The hello world example works great, but I do aspire to more than that.

If I have missed an important note in the documentation, then I apologize
greatly in advance.


Sincerely,
Mikael Lyngvig
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

alloc_size metadata

Nuno Lopes — 2012-05-23T23:16:30

Hi,

I'm implementing the alloc_size function attribute in clang. This  
attribute exists in gcc since version 4.3.
The attribute specifies that a function returns a buffer with the size  
given by the multiplication of the specified arguments.  I would like  
to add new metadata to pass this information to LLVM IR.

For example, take the following C code:

void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)));

void* fn() {
   return my_calloc(1, 3);
}


which would get translated to:


define i8* < at >fn() {
entry:
   %call = call i8* < at >my_calloc(i32 1, i32 3), !alloc_size !0
   ret i8* %call
}

declare i8* < at >my_calloc(i32, i32)

!0 = metadata !{i32 0, i32 1}


The downsize is that the metadata is added to all call sites, since  
it's not possible to attach metadata to function declarations.

Any comment, suggestion, etc?

Thanks,
Nuno

tblgen for generation of Haskell bindings to LLVMintrinsics

Henning Thielemann — 2012-05-23T22:38:13

I want to generate Haskell bindings to LLVM intrinsics. In a first attempt I 
wrote a little parser that reads IntrinsicsX86.td and outputs a Haskell module.

E.g. the definition

   def int_x86_avx_max_ps_256 : GCCBuiltin<"__builtin_ia32_maxps256">,
         Intrinsic<[llvm_v8f32_ty], [llvm_v8f32_ty,
                   llvm_v8f32_ty], [IntrNoMem]>;

is turned into

   maxpd256 :: Ext.T (V4Double -> V4Double -> LLVM.CodeGenFunction r V4Double)
   maxpd256 = Ext.intrinsic ExtX86.avx "max.pd.256"


This works for the flat structure of IntrinsicsX86.td, but e.g. 
IntrinsicsPowerPC.td uses tablegen classes.

Now I wonder whether it is better to use tablegen to generate the Haskell code. 
The tblgen man page says, that tablegen emits C++. This would not be a big 
problem, since I could let it write C++ code that in turn writes Haskell code.

Unfortunately the section
   "http://llvm.org/docs/TableGenFundamentals.html#backends"
  is not yet written.

Is it possible to use the llvm-tblgen binary without modification or do I have 
to extend llvm-tblgen or do I have to write my own C++ code that uses some of 
the functions from the tblgen library? Are there any (simple) examples of 
custom tblgen backends?

Minor correction to the Visual Studio documentation

Mikael Lyngvig — 2012-05-23T21:50:06

Hi again,

The Visual Studio getting started guide (
http://llvm.org/docs/GettingStartedVS.html) mentions the "llvm-lit" tool,
but fails to mention these things:

   1. Either you need to run it from bash or a similar Unix shell, as
Windows does not recognize the extensionless Python script that it is.
   2. Alternatively, you can invoke it using Python like this: python
bin/llvm-lit test

I know that the documentation says that I am to install GnuWin32 tools, but
I strongly oppose that idea.  We Windows people have our own tools and
practices and I think the LLVM developers should open up to a more
multi-platform approach than the current (Unix then, perhaps maybe,
Windows) approach.  CMake works brilliantly, though, so there are no issues
in building neither the win32 or win64 versions of LLVM.

As far as I can tell, I don't need the GnuWin32 tools at all.  I can
succesfully build and link a tiny "hello world" sample program without
problems.  I do have many Windows ports of Unix tools in my standard path,
though, and perhaps that is the reason that the build succeds without
GnuWin32.

If I can help, please let me know.  My angle to LLVM is this: I need a
portable, multi-targeting code generator and optimizer, and I happen to
prefer Windows as my platform.  So, perhaps I can write or update some
documentation on how to use LLVM on Windows.


Sincerely,
Mikael Lyngvig
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Minor error message extracting clang-3.0.tar.gz on Windows

Mikael Lyngvig — 2012-05-23T21:18:25

Hi,

I am building LLVM v3.0 for Windows 32-bit and 64-bit, and when I extract
the files from the tar archive, I get the following error:

*********************
c:\tmp\llvm-3.0.src-win32\tools>tar xzf \tmp\clang-3.0.tar.gz
clang-3.0.src/tools/scan-build/c++-analyzer: Can't create
'clang-3.0.src/tools/scan-build/c++-analyzer': No such file or directory
tar: Error exit delayed from previous errors.

c:\tmp\llvm-3.0.src-win32\tools>tar --version
bsdtar 2.4.12 - libarchive 2.4.12
************************

As you can see, I use BSD tar instead of GNU tar because of the former
supports more file formats and for other reasons I can't recall right now.
I don't know if the problem is caused by BSD tar or not.  I don't even know
what the precise problem is, but I guess tar is being instructed to create
a link.

I don't think the above warrants a bug report; perhaps whoever's
responsible for creating the distribution tars can take the above into
consideration when preparing the archives?

I do not know that the above should have caused any problems for me in any
way; I can build fine and the output seems to run more or less sanely (I
still get some odd behavior from clang++, but that's probably due to one or
more errors on my part).


Sincerely,
Mikael Lyngvig
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Thanks LLVM Team!

2012-05-23T20:51:19

A big "congratulations!" to everyone here who contributes to LLVM.  I
missed the official announcement but I wanted to make sure to express my
thanks.  We are really looking forward to integrating 3.1 and pushing
back many of our enhancements.  Thanks to the release team for making it
happen!

                               -Dave

Re: VMKit build broken

Nicolas Geoffray — 2012-05-23T20:39:18

Hi Balachandran,

On Tue, May 22, 2012 at 8:45 PM, Balachandran Sivakumar <
benignbala< at >gmail.com> wrote:


I have just fixed the problem (vmkit used to use llvm-ld but llvm-ld has
been replaced with llvm-link). Please  try to update both llvm and vmkit
repos and compile. Let me know if it worked for you!

Nicolas

--
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Re: buildslave: gcc14 ran out of space on disk

Duncan Sands — 2012-05-23T20:14:41

Hi Anna,


I've asked users of this machine to clean up.

Ciao, Duncan.

Re: problem on clang+gold

Wei-Ren Chen — 2012-05-23T13:57:36

  From the top of my head, perhaps you can look into 
clang/lib/Frontend/InitHeaderSearch.cpp and try to use the GCC path you want.

HTH, 
chenwj

--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj


_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Assembly macros instantiation problem

Nikita Shulga — 2012-05-23T18:36:45

Hello,

I've noticed a following strange behavior:
clang-3.2 fails to compile/parse any assembly code that invokes macros which named arguments contains non alphanumeric characters.
For example, compilation of the following code snippet would fail with "Parameter not found" error:
.macro mov_macro reg_1,    reg_2
movl %\reg_1, %\reg_2
.endm
mov_macro eax, ebx

Although, if one removes underscores from mov_macro argument names, compilation would succeed.
Such behavior is due to the glitch in AsmParser::expandMacro() logic: it treats first non-alphanumeric character as the end of argument instantiation token.

Following patch fixes the issue (IsIdentifierChar routine implementation was borrowed from lib/MC/MCParser/AsmLexer.cpp):
===================================================================
--- lib/MC/MCParser/AsmParser.cpp(revision 157279)
+++ lib/MC/MCParser/AsmParser.cpp(working copy)
< at >< at > -1436,6 +1436,11 < at >< at >
     NewDiag.print(0, OS);
 }
 
+/// LexIdentifier: [a-zA-Z_.][a-zA-Z0-9_$.< at >]*
+static bool IsIdentifierChar(char c) {
+  return isalnum(c) || c == '_' || c == '$' || c == '.' || c == '< at >';
+}
+
 bool AsmParser::expandMacro(SmallString<256> &Buf, StringRef Body,
                             const std::vector<StringRef> &Parameters,
                             const std::vector<std::vector<AsmToken> > &A,
< at >< at > -1501,7 +1506,7 < at >< at >
       Pos += 2;
     } else {
       unsigned I = Pos + 1;
-      while (isalnum(Body[I]) && I + 1 != End)
+      while (IsIdentifierChar(Body[I]) && I + 1 != End)
         ++I;
 
       const char *Begin = Body.data() + Pos +1;
===================================================================


Regards,
Nikita

Sink Store Operations in Branch Paths?

Ryan Taylor — 2012-05-23T18:16:37

Is there a pass/opt that will sink (via a phi and new store in post
dominator for example) store operations in different paths to the post
dominator (providng each path does not include a loop)?
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev