From vanboxem.ruben at gmail.com  Sat Jan  1 06:23:39 2011
From: vanboxem.ruben at gmail.com (Ruben Van Boxem)
Date: Sat, 1 Jan 2011 13:23:39 +0100
Subject: [LLVMdev] "nmake check" doesn't work for MSVC
Message-ID: <AANLkTi=-pxN_6g0AYRnuRLPy5uO_+WCqzXs-CogdSLi1@mail.gmail.com>

Hi,

I built llvm+Clang for MSVC 10 with

cmake ../../Source/LLVM -G"NMake Makefiles"
nmake

And I tried to do a
nmake check

(which works for MinGW and "mingw32-make check")

and get the following error:
>Scanning dependencies of target check
>[100%] Running LLVM regression tests
>Traceback (most recent call last):
>  File "M:/Development/Source/LLVM/utils/lit/lit.py", line 5, in <module>
>    lit.main()
>  File "M:\Development\Source\LLVM\utils\lit\lit\main.py", line 515, in main
>    testSuiteCache, localConfigCache)[1])
>  File "M:\Development\Source\LLVM\utils\lit\lit\main.py", line 230, in getTests
>    ts,path_in_suite = getTestSuite(path, litConfig, testSuiteCache)
>  File "M:\Development\Source\LLVM\utils\lit\lit\main.py", line 199, in getTestSuite
>    ts, relative = search(item)
>  File "M:\Development\Source\LLVM\utils\lit\lit\main.py", line 183, in search
>    cache[path] = res = search1(path)
>  File "M:\Development\Source\LLVM\utils\lit\lit\main.py", line 174, in search1
>    cfg = TestingConfig.frompath(cfgpath, None, litConfig, mustExist = True)
>  File "M:\Development\Source\LLVM\utils\lit\lit\TestingConfig.py", line 44, in frompath
>    exec f in cfg_globals
>  File "M:\Development\x64-msvc\llvm\test\lit.site.cfg", line 19, in <module>
>    lit.load_config(config, "M:/Development/Source/LLVM/test/lit.cfg")
>  File "M:\Development\Source\LLVM\utils\lit\lit\LitConfig.py", line 65, in load_config
>    config = config)
>  File "M:\Development\Source\LLVM\utils\lit\lit\TestingConfig.py", line 44, in frompath
>    exec f in cfg_globals
>  File "M:/Development/Source/LLVM/test/lit.cfg", line 147, in <module>
>    site_exp[sub].replace('-fno-exceptions', '')))
>KeyError: 'compile_cxx'
>NMAKE : fatal error U1077: 'M:\Development\utils\Python\python.exe' : return code '0x1'
>Stop.
>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>Stop.
>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>Stop.
>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>Stop.

What to do? Thanks!

Ruben

From yuri at rawbw.com  Sat Jan  1 06:26:21 2011
From: yuri at rawbw.com (Yuri)
Date: Sat, 01 Jan 2011 04:26:21 -0800
Subject: [LLVMdev] misaligned_stack_error caused by LLVM code on MacOS: how
	to fix?
Message-ID: <4D1F1D6D.4090608@rawbw.com>

llvm-generated code that runs fine on linux/i386 causes EXC_BAD_ACCESS 
with misaligned_stack_error_ on MacOS/i386.

I read online that each function should have stack aligned by 16 on 
MacOS/i386 and such code should be used:

Fn->addAttribute(~0U, llvm::Attribute::constructStackAlignmentFromInt(16));

But when I run clang on some C++ code I don't see alignstack 
instructions generated at all.

What is the right way for fix this misaligned_stack_error?

Yuri

From geek4civic at gmail.com  Sat Jan  1 08:40:06 2011
From: geek4civic at gmail.com (NAKAMURA Takumi)
Date: Sat, 1 Jan 2011 23:40:06 +0900
Subject: [LLVMdev] "nmake check" doesn't work for MSVC
In-Reply-To: <AANLkTi=-pxN_6g0AYRnuRLPy5uO_+WCqzXs-CogdSLi1@mail.gmail.com>
References: <AANLkTi=-pxN_6g0AYRnuRLPy5uO_+WCqzXs-CogdSLi1@mail.gmail.com>
Message-ID: <AANLkTin7u2tO-ZdSbS=ZWe2rdZLSpqv6CJwiLo_=zV8a@mail.gmail.com>

Hello Ruben,

Did you try one on Visual Studio IDE and msbuild.exe?

AFAIK, "nmake check" doesn't work.
I gave up to tweak for one in past.

Patches are welcome!

...Takumi

From anton at korobeynikov.info  Sat Jan  1 12:17:40 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Sat, 1 Jan 2011 21:17:40 +0300
Subject: [LLVMdev] misaligned_stack_error caused by LLVM code on MacOS:
 how to fix?
In-Reply-To: <4D1F1D6D.4090608@rawbw.com>
References: <4D1F1D6D.4090608@rawbw.com>
Message-ID: <AANLkTik4OtnpBHgVgnLQa5JA=wa0-4=dOwcCtZHrKV+m@mail.gmail.com>

Hello

> What is the right way for fix this misaligned_stack_error?
Codegen stuff for darwin, there are many other differences in Linux/Darwin ABIs.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From yuri at rawbw.com  Sat Jan  1 16:15:19 2011
From: yuri at rawbw.com (Yuri)
Date: Sat, 01 Jan 2011 14:15:19 -0800
Subject: [LLVMdev] misaligned_stack_error caused by LLVM code on MacOS:
 how to fix?
In-Reply-To: <AANLkTik4OtnpBHgVgnLQa5JA=wa0-4=dOwcCtZHrKV+m@mail.gmail.com>
References: <4D1F1D6D.4090608@rawbw.com>
	<AANLkTik4OtnpBHgVgnLQa5JA=wa0-4=dOwcCtZHrKV+m@mail.gmail.com>
Message-ID: <4D1FA777.4030000@rawbw.com>

On 01/01/2011 10:17, Anton Korobeynikov wrote:
> Codegen stuff for darwin, there are many other differences in 
> Linux/Darwin ABIs.

Calling set_module_triple with "i386-apple-darwin10.0.0" fixes the issue.

But I notice that when clang generates code the other difference is that 
all functions have ssp attribute on darwin which doesn't appear on linux 
and freebsd.
Why there is such a difference between MacOS and Linux?

Yuri

From geek4civic at gmail.com  Sat Jan  1 18:20:46 2011
From: geek4civic at gmail.com (NAKAMURA Takumi)
Date: Sun, 2 Jan 2011 09:20:46 +0900
Subject: [LLVMdev] X86 -tailcallopt and C calling conversion
Message-ID: <AANLkTinf4NsysfiXSOOSh2hv9WfaUUM+rfzzL-wEi7b0@mail.gmail.com>

Happy 2011, everybody!

It seems -tailcallopt prevents tailcall optimization when both caller
and callee have ccc,
even when it is optimized without an option -tailcallopt.
Is it intended or misoptimized?

In X86ISelLowering.cpp:X86TargetLowering::IsEligibleForTailCallOptimization():

  if (GuaranteedTailCallOpt) {
    if (IsTailCallConvention(CalleeCC) && CCMatch)
      return true;
    return false;
  }

I know -tailcallopt changes calling conversion of fastcc to callee-pop.

ps. I am tweaking tailcallopt on Win64.

...Takumi

From kledzik at apple.com  Sat Jan  1 19:52:58 2011
From: kledzik at apple.com (Nick Kledzik)
Date: Sat, 1 Jan 2011 17:52:58 -0800
Subject: [LLVMdev] misaligned_stack_error caused by LLVM code on MacOS:
	how	to fix?
In-Reply-To: <4D1F1D6D.4090608@rawbw.com>
References: <4D1F1D6D.4090608@rawbw.com>
Message-ID: <F2AAD12B-9C84-49E0-879A-BEB017849011@apple.com>

That stack alignment check only happens when a lazy pointer is resolved, which happens the first time each external function is called.  For example, if your program calls malloc() the first time malloc is called from any site in your program, the stack alignment is checked.  After that, if your program calls malloc, no alignment checking is done.  

So, not seeing a misaligned_stack_error does not mean the program is correct.  It may be that in the code path you exercised the first time a function was called had the stack aligned.  But there may be another code path involving a function that misaligns the stack, which could trigger the misaligned_stack_error.

-Nick

On Jan 1, 2011, at 4:26 AM, Yuri wrote:
> llvm-generated code that runs fine on linux/i386 causes EXC_BAD_ACCESS 
> with misaligned_stack_error_ on MacOS/i386.
> 
> I read online that each function should have stack aligned by 16 on 
> MacOS/i386 and such code should be used:
> 
> Fn->addAttribute(~0U, llvm::Attribute::constructStackAlignmentFromInt(16));
> 
> But when I run clang on some C++ code I don't see alignstack 
> instructions generated at all.
> 
> What is the right way for fix this misaligned_stack_error?
> 
> Yuri
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From bijoy123_8 at yahoo.com  Sat Jan  1 22:29:44 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Sat, 1 Jan 2011 20:29:44 -0800 (PST)
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <AANLkTimyihewWW4k1v8mwNUL9GDLfuJskMHLVrchW1J_@mail.gmail.com>
Message-ID: <124838.52304.qm@web121705.mail.ne1.yahoo.com>

Hi,
??? I am planning to follow the steps to install LLVM for the ARM-target (Processor: Xscale, Architecture: armv5te):
?
1. Install binutils-2.21 (downloaded from gnu.org)
?
Steps: 
?
$ ./configure --target=arm-unknown-linux-gnueabi --program-prefix=arm- --prefix
=/llvm/arm --with-sysroot=/llvm/arms/sys-root
?
$ make
?
$ make install
?

2. Install LLVM
?
Steps
?
$ ../llvm-src/configure --target=arm-linux --prefix=/llvm/arm --disable-optimiz
ed --enable-bindings=none --disable-multilib --disable-bootstrap --with-sysroot
=/llvm/arms/sys-root --with-binutils-include=/llvm/binutils-2.21/include --with
-llvmgccdir=/llvm/llvm-gcc-4.2
?
$ make
?
$ make install
?
3. Install LLVM-GCC
?
Steps:
?
$ ../llvm-gcc/configure --target=arm-linux --program-prefix=arm- --prefix=$PWD/
../install --disable-optimized --enable-bindings=none --enable-llvm=$PWD/../llv
m-2.8 --enable-languages=c,c++ --disable-multilib --disable-bootstrap

$ make
?
$ make install
?
?
However, when I try to build LLVM source (second step) by make, I get the following error:
?
llvm[2]: Linking Debug Loadable Module LLVMgold.dll
/llvm/llvm-src/tools/gold/Debug/gold-plugin.o: In function `all_symbols_read_hoo
k':
/llvm/llvm-src/tools/gold/gold-plugin.cpp:364: undefined reference to `_lto_code
gen_create'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:368: undefined reference to `_lto_code
gen_add_module'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:387: undefined reference to `_lto_code
gen_add_must_preserve_symbol'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:401: undefined reference to `_lto_code
gen_dispose'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:405: undefined reference to `_lto_code
gen_set_pic_model'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:406: undefined reference to `_lto_code
gen_set_debug_model'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:409: undefined reference to `_lto_code
gen_set_assembler_path'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:417: undefined reference to `_lto_code
gen_set_assembler_args'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:420: undefined reference to `_lto_code
gen_set_cpu'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:426: undefined reference to `_lto_code
gen_debug_options'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:439: undefined reference to `_lto_code
gen_write_merged_modules'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:447: undefined reference to `_lto_code
gen_compile'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:473: undefined reference to `_lto_code
gen_dispose'
/llvm/llvm-src/tools/gold/Debug/gold-plugin.o: In function `claim_file_hook':
/llvm/llvm-src/tools/gold/gold-plugin.cpp:264: undefined reference to `_lto_modu
le_is_object_file_in_memory'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:268: undefined reference to `_lto_modu
le_is_object_file'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:276: undefined reference to `_lto_modu
le_create_from_memory'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:276: undefined reference to `_lto_modu
le_create'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:280: undefined reference to `_lto_get_
error_message'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:285: undefined reference to `_lto_modu
le_set_target_triple'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:288: undefined reference to `_lto_modu
le_get_num_symbols'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:292: undefined reference to `_lto_modu
le_get_symbol_attribute'
/llvm/llvm-src/tools/gold/gold-plugin.cpp:298: undefined reference to `_lto_modu
le_get_symbol_name'
collect2: ld returned 1 exit status
make[2]: *** [/llvm/llvm-src/Debug/bin/LLVMgold.dll] Error 1
make[2]: Leaving directory `/llvm/llvm-src/tools/gold'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/llvm/llvm-src/tools'
make: *** [all] Error 1
?
Can anyone please tell me is there any problem on my plan to build LLVM for the ARM target (for armv5te) and why I get the errors when building LLVM (make)?
?
?
Thanks,
Akramul

--- On Thu, 30/12/10, Anton Korobeynikov <anton at korobeynikov.info> wrote:


From: Anton Korobeynikov <anton at korobeynikov.info>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "akramul azim" <bijoy123_8 at yahoo.com>
Cc: "Bill Wendling" <wendling at apple.com>, llvmdev at cs.uiuc.edu
Date: Thursday, 30 December, 2010, 1:29 PM


Hello

> ????????? -c ../../llvm-gcc-4.8/gcc/crtstuff.c -DCRT_BEGIN \
> ????????? -o crtbegin.o
> C:/MinGW/llvm/arm_objects/gcc/as: line 2: exec: -o: invalid option
You don't have cross ARM binutils installed.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110101/f85ec025/attachment.html 

From wendling at apple.com  Sun Jan  2 00:07:04 2011
From: wendling at apple.com (Bill Wendling)
Date: Sat, 1 Jan 2011 22:07:04 -0800
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <124838.52304.qm@web121705.mail.ne1.yahoo.com>
References: <124838.52304.qm@web121705.mail.ne1.yahoo.com>
Message-ID: <34AE5D31-1133-41AF-AE5E-F09C4B9DB774@apple.com>

On Jan 1, 2011, at 8:29 PM, akramul azim wrote:

> Hi,
>     I am planning to follow the steps to install LLVM for the ARM-target (Processor: Xscale, Architecture: armv5te):
>  
> 1. Install binutils-2.21 (downloaded from gnu.org)
>  
> Steps:
>  
> $ ./configure --target=arm-unknown-linux-gnueabi --program-prefix=arm- --prefix
> =/llvm/arm --with-sysroot=/llvm/arms/sys-root
>  
> $ make
>  
> $ make install
>  
> 
> 2. Install LLVM
>  
> Steps
>  
> $ ../llvm-src/configure --target=arm-linux --prefix=/llvm/arm --disable-optimiz
> ed --enable-bindings=none --disable-multilib --disable-bootstrap --with-sysroot
> =/llvm/arms/sys-root --with-binutils-include=/llvm/binutils-2.21/include --with
> -llvmgccdir=/llvm/llvm-gcc-4.2
>  
> $ make
>  
> $ make install
>  
> 3. Install LLVM-GCC
>  
> Steps:
>  
> $ ../llvm-gcc/configure --target=arm-linux --program-prefix=arm- --prefix=$PWD/
> ../install --disable-optimized --enable-bindings=none --enable-llvm=$PWD/../llv
> m-2.8 --enable-languages=c,c++ --disable-multilib --disable-bootstrap
> $ make
>  
> $ make install
>  
>  
> However, when I try to build LLVM source (second step) by make, I get the following error:
>  
> llvm[2]: Linking Debug Loadable Module LLVMgold.dll
> /llvm/llvm-src/tools/gold/Debug/gold-plugin.o: In function `all_symbols_read_hoo
> k':
> /llvm/llvm-src/tools/gold/gold-plugin.cpp:364: undefined reference to `_lto_code
> gen_create'

It looks like llvm/tools/lto wasn't built in step 1 (you can check to see if this is so). From the Makefile, it will built tools/lto when ENABLE_PIC is 1. Check to see what ENABLE_PIC is set to in the Makefile.config file. If it's not set, try using the --enable-pic flag during LLVM's configure.

-bw




From vanboxem.ruben at gmail.com  Sun Jan  2 06:35:54 2011
From: vanboxem.ruben at gmail.com (Ruben Van Boxem)
Date: Sun, 2 Jan 2011 13:35:54 +0100
Subject: [LLVMdev] LLVM on Windows MSVC 10
In-Reply-To: <87sjxe2g42.fsf@telefonica.net>
References: <AANLkTimUo+gnbWhr+kt7=HnoLCLz3-mEQL4KxJaSR3iE@mail.gmail.com>
	<AANLkTi=rfDKFosWhJ5Kb5koL_SA9Y5Y0KrJ_yqZVDEU6@mail.gmail.com>
	<AANLkTikuFaXkze1UJQdWZ2NAB1UZMZ0F1oDtGzcU4VYA@mail.gmail.com>
	<AANLkTim9hBr9ty4rRS0dZsC0iiJ8dwwtcgzMsqEMrr9k@mail.gmail.com>
	<87sjxe2g42.fsf@telefonica.net>
Message-ID: <AANLkTik_-d2oL-Hq0CTqoRAYzE4h5M=PV9aadH3rMfmR@mail.gmail.com>

2010/12/31 ?scar Fuentes <ofv at wanadoo.es>:
> Ruben Van Boxem <vanboxem.ruben at gmail.com> writes:
>
>>>> I'm trying to build svn LLVM with Visual Studio 2010:
>>>>
>>>> cd build
>>>> cmake .. -G"NMake Makefiles"
>>>> nmake
>>>>
>>>> and several link steps fail due to a missing symbol:
>>>>
>>>> > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error LNK2019: unresolved
>>>> > external symbol X86CompilationCallback referenced in function "public:
>>>> > virtual void (__cdecl*__cdecl llvm::X86JITInfo::getLazyResolverFunction(void
>>>> > * (__cdecl*)(void *)))(void)"
>>>> > (?getLazyResolverFunction at X86JITInfo@llvm@@UEAAP6AXXZP6APEAXPEAX at Z@Z)
>>>>
>>>> What can/should I do?
>>
>> I'm using SVN Rev. 122644 (trunk), and building for Windows x64 (from
>> the MSVC Command prompt).
>
> This is probably a bug with Windows64 support. Please file a bug report.
>

To follow up on MSVC x64 problems: running CMake like this:

cmake ../../Source/LLVM -G"Visual Studio 10 Win64"

causes following error:
>-- Targeting X86
>CMake Error at M:/Development/utils/cmake/share/cmake-2.8/Modules/CMakeDetermineASMCompiler.cmake:68 (CMAKE_DETERMINE_COMPILER_ID_VENDOR):
>  Unknown CMake command "CMAKE_DETERMINE_COMPILER_ID_VENDOR".
>Call Stack (most recent call first):
>  M:/Development/utils/cmake/share/cmake-2.8/Modules/CMakeDetermineASM_MASMCompiler.cmake:26 (INCLUDE)
>  lib/Target/X86/CMakeLists.txt:44 (enable_language)
>
>
>CMake Error: Could not find cmake module file:M:/Development/x64-msvc/llvm/CMakeFiles/CMakeASM_MASMCompiler.cmake
>-- Configuring incomplete, errors occurred!

I have filed a bug report: http://llvm.org/bugs/show_bug.cgi?id=8885

Thanks!

Ruben


From bijoy123_8 at yahoo.com  Sun Jan  2 08:59:20 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Sun, 2 Jan 2011 06:59:20 -0800 (PST)
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <34AE5D31-1133-41AF-AE5E-F09C4B9DB774@apple.com>
Message-ID: <77144.38560.qm@web121707.mail.ne1.yahoo.com>

I tried adding --enable-pics but getting the same error. I opened the make file but don't see any flag of enable_pics :-(. Is there any way to get around the problem?
Akramul

--- On Sun, 2/1/11, Bill Wendling <wendling at apple.com> wrote:

From: Bill Wendling <wendling at apple.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "akramul azim" <bijoy123_8 at yahoo.com>
Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 6:07 AM

On Jan 1, 2011, at 8:29 PM, akramul azim wrote:

> Hi,
>? ???I am planning to follow the steps to install LLVM for the ARM-target (Processor: Xscale, Architecture: armv5te):
>? 
> 1. Install binutils-2.21 (downloaded from gnu.org)
>? 
> Steps:
>? 
> $ ./configure --target=arm-unknown-linux-gnueabi --program-prefix=arm- --prefix
> =/llvm/arm --with-sysroot=/llvm/arms/sys-root
>? 
> $ make
>? 
> $ make install
>? 
> 
> 2. Install LLVM
>? 
> Steps
>? 
> $ ../llvm-src/configure --target=arm-linux --prefix=/llvm/arm --disable-optimiz
> ed --enable-bindings=none --disable-multilib --disable-bootstrap --with-sysroot
> =/llvm/arms/sys-root --with-binutils-include=/llvm/binutils-2.21/include --with
> -llvmgccdir=/llvm/llvm-gcc-4.2
>? 
> $ make
>? 
> $ make install
>? 
> 3. Install LLVM-GCC
>? 
> Steps:
>? 
> $ ../llvm-gcc/configure --target=arm-linux --program-prefix=arm- --prefix=$PWD/
> ../install --disable-optimized --enable-bindings=none --enable-llvm=$PWD/../llv
> m-2.8 --enable-languages=c,c++ --disable-multilib --disable-bootstrap
> $ make
>? 
> $ make install
>? 
>? 
> However, when I try to build LLVM source (second step) by make, I get the following error:
>? 
> llvm[2]: Linking Debug Loadable Module LLVMgold.dll
> /llvm/llvm-src/tools/gold/Debug/gold-plugin.o: In function `all_symbols_read_hoo
> k':
> /llvm/llvm-src/tools/gold/gold-plugin.cpp:364: undefined reference to `_lto_code
> gen_create'

It looks like llvm/tools/lto wasn't built in step 1 (you can check to see if this is so). From the Makefile, it will built tools/lto when ENABLE_PIC is 1. Check to see what ENABLE_PIC is set to in the Makefile.config file. If it's not set, try using the --enable-pic flag during LLVM's configure.

-bw




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110102/2db88a5e/attachment.html 

From bijoy123_8 at yahoo.com  Sun Jan  2 09:12:15 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Sun, 2 Jan 2011 07:12:15 -0800 (PST)
Subject: [LLVMdev] LLVM for ARM target
Message-ID: <160258.75367.qm@web121704.mail.ne1.yahoo.com>

Sorry I used --enable-pic, not --enable-pics. It was a typo.
Akramul

--- On Sun, 2/1/11, akramul azim <bijoy123_8 at yahoo.com> wrote:

From: akramul azim <bijoy123_8 at yahoo.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "Bill Wendling" <wendling at apple.com>
Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 2:59 PM

I tried adding --enable-pics but getting the same error. I opened the make file but don't see any flag of enable_pics :-(. Is there any way to get around the problem?
Akramul

--- On Sun, 2/1/11, Bill Wendling <wendling at apple.com> wrote:

From: Bill Wendling <wendling at apple.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "akramul azim" <bijoy123_8 at yahoo.com>
Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 6:07 AM

On Jan 1, 2011, at 8:29 PM, akramul azim wrote:

> Hi,
>? ???I am planning to follow the steps to install LLVM for the ARM-target (Processor: Xscale,
 Architecture: armv5te):
>? 
> 1. Install binutils-2.21 (downloaded from gnu.org)
>? 
> Steps:
>? 
> $ ./configure --target=arm-unknown-linux-gnueabi --program-prefix=arm- --prefix
> =/llvm/arm --with-sysroot=/llvm/arms/sys-root
>? 
> $ make
>? 
> $ make install
>? 
> 
> 2. Install LLVM
>? 
> Steps
>? 
> $ ../llvm-src/configure --target=arm-linux --prefix=/llvm/arm --disable-optimiz
> ed --enable-bindings=none --disable-multilib --disable-bootstrap --with-sysroot
> =/llvm/arms/sys-root --with-binutils-include=/llvm/binutils-2.21/include --with
> -llvmgccdir=/llvm/llvm-gcc-4.2
>? 
> $ make
>? 
> $ make install
>? 
> 3. Install LLVM-GCC
>? 
> Steps:
>? 
> $ ../llvm-gcc/configure --target=arm-linux
 --program-prefix=arm- --prefix=$PWD/
> ../install --disable-optimized --enable-bindings=none --enable-llvm=$PWD/../llv
> m-2.8 --enable-languages=c,c++ --disable-multilib --disable-bootstrap
> $ make
>? 
> $ make install
>? 
>? 
> However, when I try to build LLVM source (second step) by make, I get the following error:
>? 
> llvm[2]: Linking Debug Loadable Module LLVMgold.dll
> /llvm/llvm-src/tools/gold/Debug/gold-plugin.o: In function `all_symbols_read_hoo
> k':
> /llvm/llvm-src/tools/gold/gold-plugin.cpp:364: undefined reference to `_lto_code
> gen_create'

It looks like llvm/tools/lto wasn't built in step 1 (you can check to see if this is so). From the Makefile, it will built tools/lto when ENABLE_PIC is 1. Check to see what ENABLE_PIC is set to in the Makefile.config file. If it's not set, try using the --enable-pic flag during LLVM's
 configure.

-bw





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110102/cb5fd036/attachment.html 

From bijoy123_8 at yahoo.com  Sun Jan  2 10:41:26 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Sun, 2 Jan 2011 08:41:26 -0800 (PST)
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <160258.75367.qm@web121704.mail.ne1.yahoo.com>
Message-ID: <499200.9683.qm@web121707.mail.ne1.yahoo.com>

Sorry again, my bad. I actually was using --enable-pics instead of --enable-pic. Now LLVM is being compiled. Hope the last phase llvm-gcc compilation would be a success. Thanks a lot.
Akramul

--- On Sun, 2/1/11, akramul azim <bijoy123_8 at yahoo.com> wrote:

From: akramul azim <bijoy123_8 at yahoo.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "Bill Wendling" <wendling at apple.com>
Cc: llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 3:12 PM

Sorry I used --enable-pic, not --enable-pics. It was a typo.
Akramul

--- On Sun, 2/1/11, akramul azim <bijoy123_8 at yahoo.com> wrote:

From: akramul azim <bijoy123_8 at yahoo.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "Bill Wendling" <wendling at apple.com>
Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 2:59 PM

I tried adding --enable-pics but getting the same error. I opened the make file but don't see any flag of enable_pics :-(. Is there any way to get around the problem?
Akramul

--- On Sun, 2/1/11, Bill Wendling <wendling at apple.com> wrote:

From: Bill Wendling <wendling at apple.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "akramul azim" <bijoy123_8 at yahoo.com>
Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 6:07 AM

On Jan 1, 2011, at 8:29 PM, akramul azim wrote:

> Hi,
>? ???I am planning to follow the steps to install LLVM for the ARM-target (Processor: Xscale,
 Architecture: armv5te):
>? 
> 1. Install binutils-2.21 (downloaded from gnu.org)
>? 
> Steps:
>? 
> $ ./configure --target=arm-unknown-linux-gnueabi --program-prefix=arm- --prefix
> =/llvm/arm --with-sysroot=/llvm/arms/sys-root
>? 
> $ make
>? 
> $ make install
>? 
> 
> 2. Install LLVM
>? 
> Steps
>? 
> $ ../llvm-src/configure --target=arm-linux --prefix=/llvm/arm --disable-optimiz
> ed --enable-bindings=none --disable-multilib --disable-bootstrap --with-sysroot
> =/llvm/arms/sys-root --with-binutils-include=/llvm/binutils-2.21/include --with
> -llvmgccdir=/llvm/llvm-gcc-4.2
>? 
> $ make
>? 
> $ make install
>? 
> 3. Install LLVM-GCC
>? 
> Steps:
>? 
> $ ../llvm-gcc/configure --target=arm-linux
 --program-prefix=arm- --prefix=$PWD/
> ../install --disable-optimized --enable-bindings=none --enable-llvm=$PWD/../llv
> m-2.8 --enable-languages=c,c++ --disable-multilib --disable-bootstrap
> $ make
>? 
> $ make install
>? 
>? 
> However, when I try to build LLVM source (second step) by make, I get the following error:
>? 
> llvm[2]: Linking Debug Loadable Module LLVMgold.dll
> /llvm/llvm-src/tools/gold/Debug/gold-plugin.o: In function `all_symbols_read_hoo
> k':
> /llvm/llvm-src/tools/gold/gold-plugin.cpp:364: undefined reference to `_lto_code
> gen_create'

It looks like llvm/tools/lto wasn't built in step 1 (you can check to see if this is so). From the Makefile, it will built tools/lto when ENABLE_PIC is 1. Check to see what ENABLE_PIC is set to in the Makefile.config file. If it's not set, try using the --enable-pic flag during LLVM's
 configure.

-bw





-----Inline Attachment Follows-----

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110102/1d1af079/attachment.html 

From bijoy123_8 at yahoo.com  Sun Jan  2 17:49:02 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Sun, 2 Jan 2011 15:49:02 -0800 (PST)
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <499200.9683.qm@web121707.mail.ne1.yahoo.com>
Message-ID: <393563.38581.qm@web121706.mail.ne1.yahoo.com>

In the last step after building and installing binutils 2.21 for ARM and LLVM-src, I am trying to build LLVM-GCC. However, I get the repeated system config checking promt. I used the following configuration:
?
I created a directory called arm_objects and then I write:
?
$ ../llvm-gcc-4.2/configure --target=arm-linux --program-prefix=llvm- --prefix=/llv
m/arm --enable-pic --disable-optimized --enable-bindings=none --enable-llvm=$PW
D/../llvm-src --enable-languages=c,c++ --disable-multilib --disable-bootstrap -
-with-sysroot=/llvm/arms/sys-root --with-arch=armv5te --disable-libssp --with-g
nu-ld --with-gnu-as
?
$ make
?
when I run make I get the following promt again and again:
?
CONFIG_SHELL="/bin/sh" /bin/sh ./config.status --recheck
running /bin/sh ../llvm-gcc-4.2/configure?? --target=arm-linux --program-prefix=
llvm- --prefix=/llvm/arm --disable-optimized --enable-bindings=none --enable-llv
m=/llvm/arm_objects/../llvm-src --disable-multilib --disable-bootstrap --with-sy
sroot=/llvm/arms/sys-root --enable-languages=c,c++ --no-create --no-recursion
loading cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... arm-unknown-linux-gnu
checking build system type... i686-pc-cygwin
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether ln works... (cached) yes
checking whether ln -s works... (cached) yes
checking for gcc... (cached) gcc
checking whether the C compiler (gcc? ) works... yes
checking whether the C compiler (gcc? ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gnatbind... (cached) gnatbind
checking whether compiler driver understands Ada... (cached) yes
checking how to compare bootstrapped objects... (cached) cmp --ignore-initial=16
?$$f1 $$f2
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for any version of mpfr.h... yes
*** This configuration is not supported in the following subdirectories:
???? target-libada gnattools target-libgfortran target-libffi target-zlib target
-libjava zlib target-libobjc target-boehm-gc
??? (Any other directories should still work fine.)
checking for bison... (cached) bison -y
checking for bison... (cached) bison
checking for gm4... (cached) m4
checking for flex... (cached) flex
checking for flex... (cached) flex
checking for makeinfo... (cached) makeinfo
checking for expect... (cached) expect
checking for runtest... (cached) runtest
checking for i686-pc-cygwin-ar... (cached) ar
checking for i686-pc-cygwin-as... (cached) as
checking for i686-pc-cygwin-dlltool... (cached) dlltool
checking for i686-pc-cygwin-ld... (cached) /usr/lib/gcc/i686-pc-cygwin/4.3.4/../
../../../i686-pc-cygwin/bin/ld.exe
checking for i686-pc-cygwin-lipo... no
checking for lipo... no
checking for i686-pc-cygwin-nm... (cached) nm
checking for i686-pc-cygwin-ranlib... (cached) ranlib
checking for i686-pc-cygwin-strip... (cached) strip
checking for i686-pc-cygwin-windres... (cached) windres
checking for i686-pc-cygwin-objcopy... (cached) objcopy
checking for i686-pc-cygwin-objdump... (cached) objdump
checking for arm-linux-cc... no
checking for arm-linux-gcc... no
checking for arm-linux-c++... no
checking for arm-linux-g++... no
checking for arm-linux-cxx... no
checking for arm-linux-gxx... no
checking for arm-linux-gcc... no
checking for arm-linux-gcj... no
checking for arm-linux-gfortran... no
checking for ar... no
checking for arm-linux-ar... no
checking for as... no
checking for arm-linux-as... no
checking for dlltool... no
checking for arm-linux-dlltool... no
checking for ld... no
checking for arm-linux-ld... no
checking for lipo... no
checking for arm-linux-lipo... no
checking for nm... no
checking for arm-linux-nm... no
checking for objdump... no
checking for arm-linux-objdump... no
checking for ranlib... no
checking for arm-linux-ranlib... no
checking for strip... no
checking for arm-linux-strip... no
checking for windres... no
checking for arm-linux-windres... no
checking where to find the target ar... pre-installed
checking where to find the target as... pre-installed
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... pre-installed
checking where to find the target gcc... just compiled
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... pre-installed
checking where to find the target ld... pre-installed
checking where to find the target lipo... pre-installed
checking where to find the target nm... pre-installed
checking where to find the target objdump... pre-installed
checking where to find the target ranlib... pre-installed
checking where to find the target strip... pre-installed
checking where to find the target windres... pre-installed
checking whether to enable maintainer-specific portions of Makefiles... no
?
CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status
creating Makefile
make: Warning: File `../llvm-gcc-4.2/Makefile.in' has modification time 2.1e+07
s in the future
CONFIG_SHELL="/bin/sh" /bin/sh ./config.status --recheck
running /bin/sh ../llvm-gcc-4.2/configure?? --target=arm-linux --program-prefix=
llvm- --prefix=/llvm/arm --disable-optimized --enable-bindings=none --enable-llv
m=/llvm/arm_objects/../llvm-src --disable-multilib --disable-bootstrap --with-sy
sroot=/llvm/arms/sys-root --enable-languages=c,c++ --no-create --no-recursion
loading cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... arm-unknown-linux-gnu
checking build system type... i686-pc-cygwin
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether ln works... (cached) yes
checking whether ln -s works... (cached) yes
checking for gcc... (cached) gcc
checking whether the C compiler (gcc? ) works... yes
checking whether the C compiler (gcc? ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gnatbind... (cached) gnatbind
checking whether compiler driver understands Ada... (cached) yes
checking how to compare bootstrapped objects... (cached) cmp --ignore-initial=16
?$$f1 $$f2
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for any version of mpfr.h... yes
*** This configuration is not supported in the following subdirectories:
???? target-libada gnattools target-libgfortran target-libffi target-zlib target
-libjava zlib target-libobjc target-boehm-gc
??? (Any other directories should still work fine.)
checking for bison... (cached) bison -y
checking for bison... (cached) bison
checking for gm4... (cached) m4
checking for flex... (cached) flex
checking for flex... (cached) flex
checking for makeinfo... (cached) makeinfo
checking for expect... (cached) expect
checking for runtest... (cached) runtest
checking for i686-pc-cygwin-ar... (cached) ar
checking for i686-pc-cygwin-as... (cached) as
checking for i686-pc-cygwin-dlltool... (cached) dlltool
checking for i686-pc-cygwin-ld... (cached) /usr/lib/gcc/i686-pc-cygwin/4.3.4/../
../../../i686-pc-cygwin/bin/ld.exe
checking for i686-pc-cygwin-lipo... no
checking for lipo... no
checking for i686-pc-cygwin-nm... (cached) nm
checking for i686-pc-cygwin-ranlib... (cached) ranlib
checking for i686-pc-cygwin-strip... (cached) strip
checking for i686-pc-cygwin-windres... (cached) windres
checking for i686-pc-cygwin-objcopy... (cached) objcopy
checking for i686-pc-cygwin-objdump... (cached) objdump
checking for arm-linux-cc... no
checking for arm-linux-gcc... no
checking for arm-linux-c++... no
checking for arm-linux-g++... no
checking for arm-linux-cxx... no
checking for arm-linux-gxx... no
checking for arm-linux-gcc... no
checking for arm-linux-gcj... no
checking for arm-linux-gfortran... no
checking for ar... no
checking for arm-linux-ar... no
checking for as... no
checking for arm-linux-as... no
checking for dlltool... no
checking for arm-linux-dlltool... no
checking for ld... no
checking for arm-linux-ld... no
checking for lipo... no
checking for arm-linux-lipo... no
checking for nm... no
checking for arm-linux-nm... no
checking for objdump... no
checking for arm-linux-objdump... no
checking for ranlib... no
checking for arm-linux-ranlib... no
checking for strip... no
checking for arm-linux-strip... no
checking for windres... no
checking for arm-linux-windres... no
checking where to find the target ar... pre-installed
checking where to find the target as... pre-installed
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... pre-installed
checking where to find the target gcc... just compiled
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... pre-installed
checking where to find the target ld... pre-installed
checking where to find the target lipo... pre-installed
checking where to find the target nm... pre-installed
checking where to find the target objdump... pre-installed
checking where to find the target ranlib... pre-installed
checking where to find the target strip... pre-installed
checking where to find the target windres... pre-installed
checking whether to enable maintainer-specific portions of Makefiles... no
creating ./config.status
CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status
creating Makefile
?
?
Can you please tell where is the problem?
?
Akramul


--- On Sun, 2/1/11, akramul azim <bijoy123_8 at yahoo.com> wrote:


From: akramul azim <bijoy123_8 at yahoo.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "Bill Wendling" <wendling at apple.com>
Cc: llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 4:41 PM






Sorry again, my bad. I actually was using --enable-pics instead of --enable-pic. Now LLVM is being compiled. Hope the last phase llvm-gcc compilation would be a success. Thanks a lot.


Akramul

--- On Sun, 2/1/11, akramul azim <bijoy123_8 at yahoo.com> wrote:


From: akramul azim <bijoy123_8 at yahoo.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "Bill Wendling" <wendling at apple.com>
Cc: llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 3:12 PM






Sorry I used --enable-pic, not --enable-pics. It was a typo.


Akramul

--- On Sun, 2/1/11, akramul azim <bijoy123_8 at yahoo.com> wrote:


From: akramul azim <bijoy123_8 at yahoo.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "Bill Wendling" <wendling at apple.com>
Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 2:59 PM






I tried adding --enable-pics but getting the same error. I opened the make file but don't see any flag of enable_pics :-(. Is there any way to get around the problem?


Akramul

--- On Sun, 2/1/11, Bill Wendling <wendling at apple.com> wrote:


From: Bill Wendling <wendling at apple.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "akramul azim" <bijoy123_8 at yahoo.com>
Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 6:07 AM


On Jan 1, 2011, at 8:29 PM, akramul azim wrote:

> Hi,
>? ???I am planning to follow the steps to install LLVM for the ARM-target (Processor: Xscale, Architecture: armv5te):
>? 
> 1. Install binutils-2.21 (downloaded from gnu.org)
>? 
> Steps:
>? 
> $ ./configure --target=arm-unknown-linux-gnueabi --program-prefix=arm- --prefix
> =/llvm/arm --with-sysroot=/llvm/arms/sys-root
>? 
> $ make
>? 
> $ make install
>? 
> 
> 2. Install LLVM
>? 
> Steps
>? 
> $ ../llvm-src/configure --target=arm-linux --prefix=/llvm/arm --disable-optimiz
> ed --enable-bindings=none --disable-multilib --disable-bootstrap --with-sysroot
> =/llvm/arms/sys-root --with-binutils-include=/llvm/binutils-2.21/include --with
> -llvmgccdir=/llvm/llvm-gcc-4.2
>? 
> $ make
>? 
> $ make install
>? 
> 3. Install LLVM-GCC
>? 
> Steps:
>? 
> $ ../llvm-gcc/configure --target=arm-linux --program-prefix=arm- --prefix=$PWD/
> ../install --disable-optimized --enable-bindings=none --enable-llvm=$PWD/../llv
> m-2.8 --enable-languages=c,c++ --disable-multilib --disable-bootstrap
> $ make
>? 
> $ make install
>? 
>? 
> However, when I try to build LLVM source (second step) by make, I get the following error:
>? 
> llvm[2]: Linking Debug Loadable Module LLVMgold.dll
> /llvm/llvm-src/tools/gold/Debug/gold-plugin.o: In function `all_symbols_read_hoo
> k':
> /llvm/llvm-src/tools/gold/gold-plugin.cpp:364: undefined reference to `_lto_code
> gen_create'

It looks like llvm/tools/lto wasn't built in step 1 (you can check to see if this is so). From the Makefile, it will built tools/lto when ENABLE_PIC is 1. Check to see what ENABLE_PIC is set to in the Makefile.config file. If it's not set, try using the --enable-pic flag during LLVM's configure.

-bw





-----Inline Attachment Follows-----


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


-----Inline Attachment Follows-----


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110102/08c719c2/attachment.html 

From jenny.sun.jenny.sun at gmail.com  Sun Jan  2 21:26:07 2011
From: jenny.sun.jenny.sun at gmail.com (jenny sun)
Date: Sun, 2 Jan 2011 20:26:07 -0700
Subject: [LLVMdev] BNF-like grammar to describe LLVM IR?
Message-ID: <AANLkTinKKatj6Y_X-3Tt7jQk5vC8DnGCSH-4j5yTUX8E@mail.gmail.com>

Hi, all,
very interested to ask if any one knows that there is a BNF like grammar to
describe LLVM IR?
Thanks,
-jenny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110102/b1eddac5/attachment.html 

From echristo at apple.com  Mon Jan  3 04:01:18 2011
From: echristo at apple.com (Eric Christopher)
Date: Mon, 3 Jan 2011 10:01:18 +0000
Subject: [LLVMdev] Question of executing AutoRegen.sh to regen configure
	file
In-Reply-To: <AANLkTim-NEPDp9H2wH6PnsD-z1un+pvt7JxNVXi=r4Oe@mail.gmail.com>
References: <AANLkTim-NEPDp9H2wH6PnsD-z1un+pvt7JxNVXi=r4Oe@mail.gmail.com>
Message-ID: <18AD50C3-8DAF-4FBF-8504-B83F1B2F85B6@apple.com>


On Dec 26, 2010, at 8:38 AM, Lu Mitnick wrote:

> Hello all,
> 
> I download the src of llvm 2.8 and run ./autoconf/AutoRegen.sh
> 
> However there is a little difference between origin configure file and the generated one
> 
> $diff configure configure.bak
> 
> 1394c1394
> <   --enable-optimized      Compile with optimizations enabled (default is YES)
> ---
> >   --enable-optimized      Compile with optimizations enabled (default is NO)
> 
> I am wondering to know whether I miss some parameter with executing AutoRegen.sh??

Probably not. The configure file for the release branch was probably edited instead of configure.ac and so a regen will overwrite the last edit to that file. This isn't going to be fixed on the release branch so if you do regen configure it will probably have some differences (we'll make sure it doesn't happen for 2.9). That said, if this is the only difference it looks like just a comment difference and so shouldn't affect anything.

To be safe you'll probably want to explicitly set --enable-optimized or --disable-optimized depending on what you want.

-eric

From echristo at apple.com  Mon Jan  3 04:04:04 2011
From: echristo at apple.com (Eric Christopher)
Date: Mon, 3 Jan 2011 10:04:04 +0000
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <393563.38581.qm@web121706.mail.ne1.yahoo.com>
References: <393563.38581.qm@web121706.mail.ne1.yahoo.com>
Message-ID: <B3500E78-2FFD-48E4-AF7D-70178DF32403@apple.com>


On Jan 2, 2011, at 11:49 PM, akramul azim wrote:

> In the last step after building and installing binutils 2.21 for ARM and LLVM-src, I am trying to build LLVM-GCC. However, I get the repeated system config checking promt. I used the following configuration:
>  
> make: Warning: File `../llvm-gcc-4.2/Makefile.in' has modification time 2.1e+07
> s in the future

Something is wrong with your filesystem or something else and is touching Makefile.in thus causing a constant reconfigure.

You should figure out what's touching Makefile.in and changing its timestamp.

-eric

From fvbommel at gmail.com  Mon Jan  3 04:41:18 2011
From: fvbommel at gmail.com (Frits van Bommel)
Date: Mon, 3 Jan 2011 11:41:18 +0100
Subject: [LLVMdev] Question of executing AutoRegen.sh to regen configure
	file
In-Reply-To: <18AD50C3-8DAF-4FBF-8504-B83F1B2F85B6@apple.com>
References: <AANLkTim-NEPDp9H2wH6PnsD-z1un+pvt7JxNVXi=r4Oe@mail.gmail.com>
	<18AD50C3-8DAF-4FBF-8504-B83F1B2F85B6@apple.com>
Message-ID: <AANLkTikMmTqzD=HOUL1Xz-6_Zge-GY3U_0TrNTpMFaq2@mail.gmail.com>

On Mon, Jan 3, 2011 at 11:01 AM, Eric Christopher <echristo at apple.com> wrote:
> On Dec 26, 2010, at 8:38 AM, Lu Mitnick wrote:
>> $diff configure configure.bak
>>
>> 1394c1394
>> < ? --enable-optimized ? ? ?Compile with optimizations enabled (default is YES)
>> ---
>> > ? --enable-optimized ? ? ?Compile with optimizations enabled (default is NO)
>>
>> I am wondering to know whether I miss some parameter with executing AutoRegen.sh??
>
> Probably not. The configure file for the release branch was probably edited instead of configure.ac and so a regen will overwrite the last edit to that file. This isn't going to be fixed on the release branch so if you do regen configure it will probably have some differences (we'll make sure it doesn't happen for 2.9). That said, if this is the only difference it looks like just a comment difference and so shouldn't affect anything.

It looks more like the "configure --help" output than a comment.


From gordon.haak at googlemail.com  Mon Jan  3 06:04:41 2011
From: gordon.haak at googlemail.com (Gordon Haak)
Date: Mon, 3 Jan 2011 13:04:41 +0100
Subject: [LLVMdev] Erasing dead blocks
Message-ID: <AANLkTi=+JbNqtqTmLKizK+UeAKhZ=_OucaK+5m2+zFYy@mail.gmail.com>

Dear LLVM developers,

I have a question regarding the IPSCCP class and the handling of dead blocks:

The file lib/Transforms/Scalar/SCCP.cpp of llvm 2.8 from contains some
code to deal with a dead block which could not be folded (line
1909ff). This happens when a user of this dead block is a branch or
switch with an undef condition. The action taken than is to replace
this terminator with an unconditional branch to the first successor of
this undef branch/switch.
I do not see how this ensures that the dead block is disconnected from
the control flow graph. If the dead block is the first successor of
the switch resp. branch the dead block will be still reachable after
this code. Am I wrong here? Is there somewhere else code ensuring that
the dead block is not the first successor of an undef branch/switch
instruction?
Thanks for your support.

Kind regards,
Gordon Haak

From king19880326 at gmail.com  Mon Jan  3 07:04:16 2011
From: king19880326 at gmail.com (Lu Mitnick)
Date: Mon, 3 Jan 2011 21:04:16 +0800
Subject: [LLVMdev] Question of executing AutoRegen.sh to regen configure
	file
In-Reply-To: <AANLkTikMmTqzD=HOUL1Xz-6_Zge-GY3U_0TrNTpMFaq2@mail.gmail.com>
References: <AANLkTim-NEPDp9H2wH6PnsD-z1un+pvt7JxNVXi=r4Oe@mail.gmail.com>
	<18AD50C3-8DAF-4FBF-8504-B83F1B2F85B6@apple.com>
	<AANLkTikMmTqzD=HOUL1Xz-6_Zge-GY3U_0TrNTpMFaq2@mail.gmail.com>
Message-ID: <AANLkTinzZ_C3OV5k8soEsV9aTtauyDJCp=adKA3AaMjb@mail.gmail.com>

That's right. I got the message of executing "configure --help".

thanks

yi-hong


2011/1/3 Frits van Bommel <fvbommel at gmail.com>

> On Mon, Jan 3, 2011 at 11:01 AM, Eric Christopher <echristo at apple.com>
> wrote:
> > On Dec 26, 2010, at 8:38 AM, Lu Mitnick wrote:
> >> $diff configure configure.bak
> >>
> >> 1394c1394
> >> <   --enable-optimized      Compile with optimizations enabled (default
> is YES)
> >> ---
> >> >   --enable-optimized      Compile with optimizations enabled (default
> is NO)
> >>
> >> I am wondering to know whether I miss some parameter with executing
> AutoRegen.sh??
> >
> > Probably not. The configure file for the release branch was probably
> edited instead of configure.ac and so a regen will overwrite the last edit
> to that file. This isn't going to be fixed on the release branch so if you
> do regen configure it will probably have some differences (we'll make sure
> it doesn't happen for 2.9). That said, if this is the only difference it
> looks like just a comment difference and so shouldn't affect anything.
>
> It looks more like the "configure --help" output than a comment.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110103/607707c6/attachment.html 

From jnspaulsson at hotmail.com  Mon Jan  3 09:08:27 2011
From: jnspaulsson at hotmail.com (Jonas Paulsson)
Date: Mon, 3 Jan 2011 16:08:27 +0100
Subject: [LLVMdev] make
Message-ID: <SNT106-W378EEB3BE082ACE0E72875B1070@phx.gbl>


Hi,

I want to build a debug build with an added target. I have

configure -disable-optimized

and then followed >> HowTo: Create and register a new back end (a new hardware target), on the wiki

Yet, I get the CXXFLAGS set with -DNDEBUGS, which is not what I want.

What should I do?

/Jonas


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110103/57df712e/attachment.html 

From carolina.sgomes at gmail.com  Mon Jan  3 09:22:32 2011
From: carolina.sgomes at gmail.com (=?ISO-8859-1?Q?Carolina_Sim=F5es_Gomes?=)
Date: Mon, 3 Jan 2011 08:22:32 -0700
Subject: [LLVMdev] Reviewer for our Path Profiling Implementation
In-Reply-To: <AANLkTinyGHy_7kZEpfOq=airmnTZGLN4Ct6h+hLW4QR5@mail.gmail.com>
References: <20AFE3EB-A248-4FA3-B859-4B88F5E0B177@ualberta.ca>
	<F75D363A-E6FF-4809-9D9A-EF6C98FD4EF0@apple.com>
	<20101221152728.GB3520@mips.complang.tuwien.ac.at>
	<970386AE-D256-454A-81D4-FB8E1C6EBD5C@apple.com>
	<0B406BBF-8A2C-40DB-B03D-A677908F5077@apple.com>
	<AANLkTinyGHy_7kZEpfOq=airmnTZGLN4Ct6h+hLW4QR5@mail.gmail.com>
Message-ID: <AANLkTi=-pBOZMgOZq4D6YSspzJ+FCup2evtxprxwP2qF@mail.gmail.com>

I am interested in contributing to an LLVM-with-profiling effort, and agree
with the unified API idea. Even if most passes right now do not make use of
any kind of profiling, I believe this is mostly due to the fact that
integrating transformation passes and profilers is not as smooth a process
as it should be.

Right now I am working on implementing speculative PRE using Adam's path
profile, and hopefully by the end of the implementation I will have good
suggestions on how to improve this integration.

On Fri, Dec 24, 2010 at 6:07 PM, J Nelson Amaral <amaral at cs.ualberta.ca>wrote:

>
>
> On Fri, Dec 24, 2010 at 5:06 PM, Andrew Trick <atrick at apple.com> wrote:
>
>> On Dec 21, 2010, at 7:57 AM, Bob Wilson wrote:
>>
>> >> To get some idea about the number of people who could be involved in a
>> >> project like this, I would like to ask for a quick show of hands: Who
>> would
>> >> be interested in contributing code to LLVM-with-profiling? (Either
>> actual
>> >> profiling code, or passes that use profiling information.)
>> >> Who would want to use the branch, even without contributing?
>> >
>> > I'd really prefer to work on trunk.
>>
>> In the near term Adam's patch profiling should be checked into llvm/trunk.
>> I think it's important that it live on the same tree as the current llvm
>> profilers with which it's tightly integrated. As we work toward implementing
>> Bob's profiling proposal, it will either need to be integrated with the new
>> framework or it will be removed along with the other stale profilers. Even
>> if it's removed from trunk, the original implementation will still be
>> available in working condition from subversion. We should be able to
>> maintain a reference to it in the latest source or docs.
>>
>> -Andy
>>
>
>
> Andy:
>
> This is a reasonable proposal to give developers interested a chance to try
> Adam's implementation of path profiling in the short term. We ourselves will
> be experimenting with the use of this implementation in some code
> transformations to see if we observe any impact on performance.
>
> --
>         Cheers,
>
>                 Nelson
>
>            /
>     \     /  /   Jose Nelson Amaral - amaral at cs.ualberta.ca
>      )   /  (    Professor
>     /   /    \   Dept. of Computing Science - University of Alberta
>    (   /      )  Edmonton, Alberta, Canada, T6G 2E8
>     \ O      /   Phone: (780)492-5411      Fax: (780)492-1071
>      \      /    http://www.cs.ualberta.ca/~amaral
>       `----'
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
[Carolina Sim?es Gomes]
Computer Engineer - Unicamp, Brasil
M.Sc. Student in Computing Science
University of Alberta, Canada
+1 (780) 863-0155
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110103/16c7bfcd/attachment.html 

From edwintorok at gmail.com  Mon Jan  3 09:23:36 2011
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Mon, 03 Jan 2011 17:23:36 +0200
Subject: [LLVMdev] make
In-Reply-To: <SNT106-W378EEB3BE082ACE0E72875B1070@phx.gbl>
References: <SNT106-W378EEB3BE082ACE0E72875B1070@phx.gbl>
Message-ID: <4D21E9F8.9020505@gmail.com>

On 2011-01-03 17:08, Jonas Paulsson wrote:
> 
> Hi,
> 
> I want to build a debug build with an added target. I have
> 
> configure -disable-optimized
> 
> and then followed >> HowTo: Create and register a new back end (a new hardware target), on the wiki
> 
> Yet, I get the CXXFLAGS set with -DNDEBUGS, which is not what I want.
> 
> What should I do?

--enable-assertions, should be the default if you checked out from SVN
or git.
Release tarballs default it off for some reason.

Best regards,
--Edwin

From Micah.Villmow at amd.com  Mon Jan  3 12:52:02 2011
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Mon, 3 Jan 2011 12:52:02 -0600
Subject: [LLVMdev] Function-level metadata for OpenCL (was
	Re:	OpenCL	support)
In-Reply-To: <20101224234954.GB4631@pcc.me.uk>
References: <20101216223345.GB1885@pcc.me.uk>
	<AANLkTikAYtbfG6GX07TYHLmzU-u+S7ivWbqs_AnZwFmz@mail.gmail.com>
	<20101220201112.GA26083@pcc.me.uk>
	<000101cba143$bcb4d700$361e8500$@Lokhmotov@arm.com>
	<20101224234954.GB4631@pcc.me.uk>
Message-ID: <D556DCBBC0EA924A9AC80003B621211205F099E5D6@sausexmbp02.amd.com>

Sorry for the late reply, as I have been on vacation for awhile.

One method which I haven't seen mentioned is to separate out the kernel semantics from the function definition.

All the kernel attribute does is specify that this function is an entry point to the device from the host. So, why not just create a separate entry point that is only callable by the host and everything from the device goes to the original entry point.

For example, you have two functions and one calls the other:

kernel foo() {
}
kernel bar() {
  foo();
}

If you separate kernel function from the function body, then handling this becomes easy.

You end up with four functions:

kernel foo_kernel() {
 foo();
}

foo() {
}

kernel bar_kernel() {
 bar();
}

bar(){
 foo();
}

Then the issue is no longer a compilation problem, but just an entry point runtime issue. Instead of calling foo(), the runtime just calls foo_kernel() which handles all of the kernel setup issues and then calls the function body itself.

This removes the need to have any metadata nodes in the IR and allows the kernel function to handle any setup issues for the specific device such as __local's, id/group calculations, memory offsets, etc... without having to impact the performance of a kernel calling another kernel. 

Micah

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Peter Collingbourne
> Sent: Friday, December 24, 2010 3:50 PM
> To: Anton Lokhmotov
> Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Function-level metadata for OpenCL (was Re:
> OpenCL support)
> 
> On Tue, Dec 21, 2010 at 07:17:40PM -0000, Anton Lokhmotov wrote:
> > > From: Peter Collingbourne [mailto:peter at pcc.me.uk]
> > > Sent: 20 December 2010 20:11
> > > As with __local variables, it may be that "kernelness" cannot be
> > > represented in a standard form in LLVM.  For example on a CPU a
> > > kernel function may have an additional parameter which is a pointer
> to
> > > __local memory space, which would not be necessary on GPUs.  Then
> in
> > > fact you would use a standard calling convention on a CPU.
> > >
> > > But for GPUs, I think using the calling convention is appropriate.
> > > If we standardise the calling convention number, this can be the
> > > default behaviour.
> > I don't think we want LLVM-IR coming from an OpenCL C frontend to be
> > different for GPU and CPU targets. In my view, the frontend should be
> > parameterised by only two (more or less) parameters: bitness (32/64)
> and
> > endianness (little/big).
> 
> Not only sizes but alignment requirements will change between
> platforms.  Also, what about __local on CPU?
> 
> > How one can even guarantee e.g. that a calling
> > convention for NVIDIA GPUs is appropriate for ATI GPUs?
> 
> We have full control over the target code generators.  There's nothing
> stopping us defining a specific constant representing the 'kernel'
> calling convention and harmonising the GPU targets to use that
> calling convention.
> 
> Thanks,
> --
> Peter
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




From zwarich at apple.com  Mon Jan  3 15:25:46 2011
From: zwarich at apple.com (Cameron Zwarich)
Date: Mon, 3 Jan 2011 13:25:46 -0800
Subject: [LLVMdev] CodeExtractor.cpp potential bug?
In-Reply-To: <AANLkTimr4kspHOmzAhO=tHyxAZbmDyEmfBa3Um7kupJ-@mail.gmail.com>
References: <AANLkTimr4kspHOmzAhO=tHyxAZbmDyEmfBa3Um7kupJ-@mail.gmail.com>
Message-ID: <194BC6F9-70CA-4120-8DA8-5041C302BFE9@apple.com>

On Dec 31, 2010, at 11:20 AM, Vu Le wrote:

> There might be a misuse of DominatorTree::splitBasicBlock in CodeExtractor.cpp, line 145.
> Header is splited into two (OldPred->NewBB).
> 
> Line 145 updates the dominator tree by calling DT->splitBasicBlock(NewBB).
> I think it should be DT->splitBasicBlock(OldPred).
> 
> When I tried to extract a code region whose header has 2 successors, my pass crashed.
> It was because header (or OldPred) is the block that was splited, not NewBB.
> DominatorTree::splitBasicBlock(BB) requires BB to have one successor.


The code in Dominator::splitBasicBlock() looks correct, but I think the comment and assert may not be. I was writing a patch where I hit the same issue. 

Cameron

From no-reply at dropboxmail.com  Mon Jan  3 16:05:04 2011
From: no-reply at dropboxmail.com (Dropbox)
Date: Mon, 03 Jan 2011 22:05:04 +0000
Subject: [LLVMdev] Wing Sit invited you to Dropbox
Message-ID: <20110103220504.3EBEE3F56BC@mailman-2.dropboxmail.com>

Wing Sit wants you to use Dropbox to sync and share files online and across computers.

Get started here: http://www.dropbox.com/link/20.L79SLE8HBH/NjU2NTA1NjYwNw?src=referrals_bulk2

- The Dropbox Team

____________________________________________________ 
To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/c44975695a77/llvmdev%40cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110103/bfc0664a/attachment.html 

From richard at metafoo.co.uk  Mon Jan  3 07:24:11 2011
From: richard at metafoo.co.uk (Richard Smith)
Date: Mon, 3 Jan 2011 13:24:11 -0000 (UTC)
Subject: [LLVMdev] x86 disassembler rejecting valid code
Message-ID: <40230.10.0.16.53.1294061051.squirrel@webmail.cantab.net>

Hi,

The x86 (32-bit) disassembler can't disassemble any of the following:

  0x2b 0xc9
  0x8a 0xc8
  0xdd 0x04 0x24

These are:

  subl %ecx, %ecx
  movb %al, %cl
  fldl (%esp)

I've attached patches to bug#8873 which fix all these issues, but I'm not
confident that I've fixed them the right way.


The first two problems are caused by the instructions setting
'isCodeGenOnly = 1', which causes tblgen to miss them from the
disassembler's tables. The code says:

  // The disassembler should know about this, but not the asmparser.
  let isCodeGenOnly = 1;

However, that's not the effect which isCodeGenOnly has. Is the comment
wrong, or is tblgen wrong? The patch I attached to bug#8873 "fixes" this
by removing the 'isCodeGenOnly = 1' from these instructions. All tests
still pass.


The fldl can't be disassembled because tblgen contains a hack which marks
all instructions whose name contains the string "64" as being
X86_64-specific. fldl's instruction is named LD_F64, so can't be
disassembled in 32-bit mode, even though it's a valid 32-bit instruction.

I think the right fix for this is to make the instructions specify whether
they're available on x86, or just on x86_64, and use that knowledge in
tblgen rather than guessing from the instruction's name. The patch I
attached to bug#8873 works around this by adding a superclass check to
tblgen to see if the instruction is one of the exceptions to this
"64"-in-name rule, but that's a horrible hack...


If someone can point me in the right direction, I'm happy to put together
patches to fix these issues in a more correct manner!

Thanks,
Richard



From echristo at apple.com  Mon Jan  3 20:08:20 2011
From: echristo at apple.com (Eric Christopher)
Date: Mon, 3 Jan 2011 18:08:20 -0800
Subject: [LLVMdev] Question of executing AutoRegen.sh to regen configure
	file
In-Reply-To: <AANLkTikMmTqzD=HOUL1Xz-6_Zge-GY3U_0TrNTpMFaq2@mail.gmail.com>
References: <AANLkTim-NEPDp9H2wH6PnsD-z1un+pvt7JxNVXi=r4Oe@mail.gmail.com>
	<18AD50C3-8DAF-4FBF-8504-B83F1B2F85B6@apple.com>
	<AANLkTikMmTqzD=HOUL1Xz-6_Zge-GY3U_0TrNTpMFaq2@mail.gmail.com>
Message-ID: <8CD68996-2C3F-4F0C-9185-FBBA17D6EE4D@apple.com>


On Jan 3, 2011, at 2:41 AM, Frits van Bommel wrote:

> On Mon, Jan 3, 2011 at 11:01 AM, Eric Christopher <echristo at apple.com> wrote:
>> On Dec 26, 2010, at 8:38 AM, Lu Mitnick wrote:
>>> $diff configure configure.bak
>>> 
>>> 1394c1394
>>> <   --enable-optimized      Compile with optimizations enabled (default is YES)
>>> ---
>>>>   --enable-optimized      Compile with optimizations enabled (default is NO)
>>> 
>>> I am wondering to know whether I miss some parameter with executing AutoRegen.sh??
>> 
>> Probably not. The configure file for the release branch was probably edited instead of configure.ac and so a regen will overwrite the last edit to that file. This isn't going to be fixed on the release branch so if you do regen configure it will probably have some differences (we'll make sure it doesn't happen for 2.9). That said, if this is the only difference it looks like just a comment difference and so shouldn't affect anything.
> 
> It looks more like the "configure --help" output than a comment.

Yes, still largely qualifies as comment rather than functional difference.

-eric

From stoklund at 2pi.dk  Tue Jan  4 01:30:54 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Mon, 3 Jan 2011 23:30:54 -0800
Subject: [LLVMdev] Is PIC code defeating the branch predictor?
Message-ID: <F9129993-2375-41ED-9659-BD9FB86F8E17@2pi.dk>

I noticed that we generate code like this for i386 PIC:

	calll	L0$pb
L0$pb:
	popl	%eax
	movl	%eax, -24(%ebp)         ## 4-byte Spill

I worry that this defeats the return address prediction for returns in the function because calls and returns no longer are matched.

From Intel's Optimization Reference Manual:

"The return address stack mechanism augments the static and dynamic predictors to optimize specifically for calls and returns. It holds 16 entries, which is large enough to cover the call depth of most programs. If there is a chain of more than 16 nested calls and more than 16 returns in rapid succession, performance may degrade.

[...] To enable the use of the return stack mechanism, calls and returns must be matched in pairs. If this is done, the likelihood of exceeding the stack depth in a manner that will impact performance is very low.

[...] Assembly/Compiler Coding Rule 4. (MH impact, MH generality) Near calls must be matched with near returns, and far calls must be matched with far returns. Pushing the return address on the stack and jumping to the routine to be called is not recommended since it creates a mismatch in calls and returns."

Is this a known issue or a non-issue?

An alternative approach would be:

	calll get_eip
	movl	%eax, -24(%ebp)         ## 4-byte Spill
...
get_eip:
	movl (%esp), %eax
	ret

More here: http://software.intel.com/en-us/blogs/2010/10/25/zero-length-calls-can-tank-atom-processor-performance/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110103/3f091e60/attachment.bin 

From resistor at mac.com  Tue Jan  4 02:37:56 2011
From: resistor at mac.com (Owen Anderson)
Date: Tue, 04 Jan 2011 00:37:56 -0800
Subject: [LLVMdev] Is PIC code defeating the branch predictor?
In-Reply-To: <F9129993-2375-41ED-9659-BD9FB86F8E17@2pi.dk>
References: <F9129993-2375-41ED-9659-BD9FB86F8E17@2pi.dk>
Message-ID: <4C4F3164-F3D4-4B7C-A2AE-14920418EEFC@mac.com>


On Jan 3, 2011, at 11:30 PM, Jakob Stoklund Olesen wrote:

> I noticed that we generate code like this for i386 PIC:
> 
> 	calll	L0$pb
> L0$pb:
> 	popl	%eax
> 	movl	%eax, -24(%ebp)         ## 4-byte Spill
> 
> I worry that this defeats the return address prediction for returns in the function because calls and returns no longer are matched.

Yes, this will defeat the processor's return address stack predictor.  That said, I suspect it's not much of an issue on "desktop" processors: the reissue of the pop is an Atom-specific issue, so you only need to worry about the branch misprediction caused on the next return.  Assuming these sequences aren't too frequent, the more elaborate tournament predictors in more powerful processors may be able to compensate for it.

That said, the alternative sequence you propose seems like it would be an improvement on any processor with a multiple issue pipeline (unless ret does a lot more work than I think it does), though it doesn't fix the reissued pop problem on Atom.

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/f15faf28/attachment.html 

From jonas.maebe at elis.ugent.be  Tue Jan  4 06:57:45 2011
From: jonas.maebe at elis.ugent.be (Jonas Maebe)
Date: Tue, 4 Jan 2011 13:57:45 +0100
Subject: [LLVMdev] Is PIC code defeating the branch predictor?
In-Reply-To: <F9129993-2375-41ED-9659-BD9FB86F8E17@2pi.dk>
References: <F9129993-2375-41ED-9659-BD9FB86F8E17@2pi.dk>
Message-ID: <3EA0B7C7-72E1-41E7-A549-932BFAABD058@elis.ugent.be>


On 04 Jan 2011, at 08:30, Jakob Stoklund Olesen wrote:

> I noticed that we generate code like this for i386 PIC:
>
> 	calll	L0$pb
> L0$pb:
> 	popl	%eax
> 	movl	%eax, -24(%ebp)         ## 4-byte Spill
>
> I worry that this defeats the return address prediction for returns  
> in the function because calls and returns no longer are matched.

According to benchmarks by Apple, it's nevertheless faster on modern  
x86 processors than the trampoline-based alternative (except maybe on  
Atom, as mentioned in another reply): http://lists.apple.com/archives/perfoptimization-dev/2007/Nov/msg00005.html

At the time of that post, Apple's version of GCC still generated  
trampolines (hence the remark). They switched that to the above  
pattern afterwards.


Jonas

From 6yearold at gmail.com  Tue Jan  4 09:45:01 2011
From: 6yearold at gmail.com (arrowdodger)
Date: Tue, 4 Jan 2011 18:45:01 +0300
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake and
	autofoo builds
Message-ID: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>

Hello. I see many discrepancies in config.h file generated by CMake and
autoheader.

Most of them are following:
In autofoo-generated config:

> /* Define to 1 if you have the `<name>' function. */
> #define HAVE_<name> 1
>
but in CMake-generated:

> #undef HAVE_<name>
>
This happens because in config.h.cmake (config.h.in analog) these functions
just are not checked for.

Another difference:
autofoo sets this by default:

> #define ENABLE_PIC 1
>
while CMake not.

There are many other differencies, which bother me, so here is the question:
is it harmless and if not - should i try to fix it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/25cc3051/attachment.html 

From clattner at apple.com  Tue Jan  4 11:22:18 2011
From: clattner at apple.com (Chris Lattner)
Date: Tue, 4 Jan 2011 09:22:18 -0800
Subject: [LLVMdev] Is PIC code defeating the branch predictor?
In-Reply-To: <3EA0B7C7-72E1-41E7-A549-932BFAABD058@elis.ugent.be>
References: <F9129993-2375-41ED-9659-BD9FB86F8E17@2pi.dk>
	<3EA0B7C7-72E1-41E7-A549-932BFAABD058@elis.ugent.be>
Message-ID: <3161B55A-E4C6-4551-889C-EF8C33ECDEB3@apple.com>


On Jan 4, 2011, at 4:57 AM, Jonas Maebe wrote:

> 
> On 04 Jan 2011, at 08:30, Jakob Stoklund Olesen wrote:
> 
>> I noticed that we generate code like this for i386 PIC:
>> 
>> 	calll	L0$pb
>> L0$pb:
>> 	popl	%eax
>> 	movl	%eax, -24(%ebp)         ## 4-byte Spill
>> 
>> I worry that this defeats the return address prediction for returns  
>> in the function because calls and returns no longer are matched.
> 
> According to benchmarks by Apple, it's nevertheless faster on modern  
> x86 processors than the trampoline-based alternative (except maybe on  
> Atom, as mentioned in another reply): http://lists.apple.com/archives/perfoptimization-dev/2007/Nov/msg00005.html
> 
> At the time of that post, Apple's version of GCC still generated  
> trampolines (hence the remark). They switched that to the above  
> pattern afterwards.

Right.  All modern X86 processors other than Atom that I'm aware of special case this sequence so it doesn't push an entry onto the return stack predictor.

-Chris

From stoklund at 2pi.dk  Tue Jan  4 11:47:50 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Tue, 4 Jan 2011 09:47:50 -0800
Subject: [LLVMdev] Is PIC code defeating the branch predictor?
In-Reply-To: <4C4F3164-F3D4-4B7C-A2AE-14920418EEFC@mac.com>
References: <F9129993-2375-41ED-9659-BD9FB86F8E17@2pi.dk>
	<4C4F3164-F3D4-4B7C-A2AE-14920418EEFC@mac.com>
Message-ID: <EBA34115-50D8-4854-B0FB-39083EBA2857@2pi.dk>


On Jan 4, 2011, at 12:37 AM, Owen Anderson wrote:

> 
> On Jan 3, 2011, at 11:30 PM, Jakob Stoklund Olesen wrote:
> 
>> I noticed that we generate code like this for i386 PIC:
>> 
>> 	calll	L0$pb
>> L0$pb:
>> 	popl	%eax
>> 	movl	%eax, -24(%ebp)         ## 4-byte Spill
>> 
>> I worry that this defeats the return address prediction for returns in the function because calls and returns no longer are matched.
> 
> Yes, this will defeat the processor's return address stack predictor.  That said, I suspect it's not much of an issue on "desktop" processors: the reissue of the pop is an Atom-specific issue, so you only need to worry about the branch misprediction caused on the next return.  Assuming these sequences aren't too frequent, the more elaborate tournament predictors in more powerful processors may be able to compensate for it.
> 
> That said, the alternative sequence you propose seems like it would be an improvement on any processor with a multiple issue pipeline (unless ret does a lot more work than I think it does), though it doesn't fix the reissued pop problem on Atom.

Since PIC was around when the current Intel micro architecture was designed, one could speculate that it can recognize a zero-length call and knows to ignore it for branch prediction? I think the call+pop sequence is quite normal.

Strangely, the optimization reference lists both code snippets in the Atom section, but doesn't recommend one over the other.

I think the matched call+ret is best if we could stick some more instructions in there. Transform this:

BB1:
	foo
	bar
	%eax = pic_base
	baz

Into this:

BB1:
	call BBx
	baz
...
BBX:
	foo
	bar
	movl (%esp), %eax
	ret

I don't know if it is worth it. The code appears in 32-bit PIC functions that access globals.

/jakob



From Micah.Villmow at amd.com  Tue Jan  4 13:08:25 2011
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Tue, 4 Jan 2011 13:08:25 -0600
Subject: [LLVMdev] Bug in MachineInstr::isIdenticalTo
Message-ID: <D556DCBBC0EA924A9AC80003B621211205F099E6CC@sausexmbp02.amd.com>

I have ran across a case where the function isIdenticalTo is return true for instructions that are not equivalent. The instructions in question are load/store instructions, and is causing a problem with MachineBranchFolding. The problem is this, I have two branches of a switch statement that are identical, except for the size of the store. Here is some cut-down LLVM-IR to showcase the issue:
switch.case:                                      ; preds = %if.end
  %tmp53 = extractelement <4 x i32> %format, i32 1 ; <i32> [#uses=1]
  switch i32 %tmp53, label %if.then [
    i32 1, label %switch.case55
    i32 2, label %switch.case61
  ]
switch.case55:                                    ; preds = %switch.case
  %arrayidx = getelementptr i8 addrspace(1)* %conv3, i32 %tmp22 ; <i8 addrspace(1)*> [#uses=1]
  %tmp59 = extractelement <4 x i32> %9, i32 0     ; <i32> [#uses=1]
  %conv60 = trunc i32 %tmp59 to i8                ; <i8> [#uses=1]
  store i8 %conv60, i8 addrspace(1)* %arrayidx
  ret void
switch.case61:                                    ; preds = %switch.case
  %arrayidx64 = getelementptr i16 addrspace(1)* %conv, i32 %tmp22 ; <i16 addrspace(1)*> [#uses=1]
  %tmp66 = extractelement <4 x i32> %9, i32 0     ; <i32> [#uses=1]
  %conv67 = trunc i32 %tmp66 to i16               ; <i16> [#uses=1]
  store i16 %conv67, i16 addrspace(1)* %arrayidx64
  ret void

Notice how except for the sizes of the pointer, the sequence is the same. This translates into the following for my backend at the MI level.
BB#9: derived from LLVM BB %switch.case55
    Live Ins: %R258 %R260 %R259
    Predecessors according to CFG: BB#8
                        %R257<def> = CUSTOM_ADD_i32 %R260<kill>, %R258<kill>
                        %R258<def> = VEXTRACT_v4i32 %R259<kill>, 1
                        GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST1[%arrayidx]
                        RETURN

BB#10: derived from LLVM BB %switch.case61
    Live Ins: %R258 %R260 %R259
    Predecessors according to CFG: BB#7
                        %R257<def> = LOADCONST_i32 1
                        %R257<def> = SHL_i32 %R258<kill>, %R257<kill>
                        %R257<def> = CUSTOM_ADD_i32 %R260<kill>, %R257<kill>
                        %R258<def> = VEXTRACT_v4i32 %R259<kill>, 1
                        GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST2[%arrayidx64]
                        RETURN

Notice how except for the memory operand size on the truncating store, the last three instructions in BB#7 is the same as BB#8.

Now looking at isIdenticalTo, I don't see any checks on the memory size. Since I don't encode this information in the instruction, because it is encoded in the memory object, two different instructions can be considered identical for different memory sizes. I believe this is incorrect.

Here is my proposed patch for the issue:
Index: MachineInstr.cpp
===================================================================
--- MachineInstr.cpp      (revision 122820)
+++ MachineInstr.cpp   (working copy)
@@ -761,9 +761,23 @@
   // If opcodes or number of operands are not the same then the two
   // instructions are obviously not identical.
   if (Other->getOpcode() != getOpcode() ||
-      Other->getNumOperands() != getNumOperands())
+      Other->getNumOperands() != getNumOperands() ||
+      Other->memoperands_empty() != memoperands_empty())
     return false;
+  if (!memoperands_empty()) {
+    // If we have mem operands, make sure that the sizes of the memoperands for each
+    // MI are the same. The values can be different, so lets only check the sizes.
+    // If the sizes between one of the memoperands differ, then the instructions are
+    // not identical.
+    for (MachineInstr::mmo_iterator mb1 = memoperands_begin(), mb2 = Other->memoperands_begin()
+        me = memoperands_end(); mb1 != me; ++mb1, ++mb2) {
+      if (mb1->getSize() != mb2->getSize() ||
+           mb1->getFlags() != mb2->getFlags() ||
+           mb1->getOffset() != mb2->getOffset()) {
+        return false;
+      }
+    }
+  }
+
   // Check operands to make sure they match.
   for (unsigned i = 0, e = getNumOperands(); i != e; ++i) {
     const MachineOperand &MO = getOperand(i);

So, my question is,  should isIdenticalTo take the memoperands into account? Is my patch correct? I almost feel like isIdenticalTo needs to be added to MachineMemOperand class.

Thoughts?
Micah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/cf0f8d22/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MI_isIdenticalTo.patch
Type: application/octet-stream
Size: 1253 bytes
Desc: MI_isIdenticalTo.patch
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/cf0f8d22/attachment.obj 

From bijoy123_8 at yahoo.com  Tue Jan  4 13:09:18 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Tue, 4 Jan 2011 11:09:18 -0800 (PST)
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <34AE5D31-1133-41AF-AE5E-F09C4B9DB774@apple.com>
Message-ID: <987883.83150.qm@web121709.mail.ne1.yahoo.com>

At the last step of building llvm for arm target, I am unable to build llvm-gcc. I am trying the follwing options:
?
$ ../llvm-gcc/configure --target=arm-linux --enable-pic --program-prefix=llvm-
--prefix=/llvm/install --disable-multilib --disable-optimized --enable-bindings
=none --enable-llvm=$PWD/../llvm-2.8 --enable-languages=c,c++ --disable-bootstr
ap
?
Then I get the following error when I run make:
?
$ make
?
../../llvm-gcc/gcc/config/arm/lib1funcs.asm:93:2: error: #error Unable to determ
ine architecture.
make[3]: *** [libgcc/./_udivsi3_s.o] Error 1
make[3]: Leaving directory `/llvm/arm_objects/gcc'
make[2]: *** [libgcc.a] Error 2
make[2]: Leaving directory `/llvm/arm_objects/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/llvm/arm_objects'
make: *** [all] Error 2
?
I also tried the following configuration:
?
$ ../llvm-gcc/configure --target=arm-linux --enable-pic --program-prefix=llvm-
--prefix=/llvm/install --disable-multilib --disable-optimized --enable-bindings
=none --enable-llvm=$PWD/../llvm-2.8 --enable-languages=c,c++ --disable-bootstr
ap --with-arch=armv5te 
?
Then I get the following error when I run make:
?
$ make
?
/llvm/install/arm-linux/bin/ranlib ./libgcov.a
/llvm/arm_objects/./gcc/xgcc -B/llvm/arm_objects/./gcc/ -B/llvm/install/arm-linu
x/bin/ -B/llvm/install/arm-linux/lib/ -isystem /llvm/install/arm-linux/include -
isystem /llvm/install/arm-linux/sys-include --sysroot=yes -O2 -O2 -g -O2 --sys
root=yes -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstric
t-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -f
omit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_
NEEDED -Dinhibit_libc -I. -I. -I../../llvm-gcc/gcc -I../../llvm-gcc/gcc/. -I../.
./llvm-gcc/gcc/../include -I../../llvm-gcc/gcc/../libcpp/include -I../../llvm-g
cc/gcc/../libdecnumber -I../libdecnumber -I/llvm/arm_objects/../llvm-2.8/include
-I/llvm/llvm-2.8/include -fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c ../
../llvm-gcc/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
'arm1026ej-s' is not a recognized processor for this target (ignoring processor)
'arm1026ej-s' is not a recognized processor for this target (ignoring processor)
In file included from ./gthr-default.h:1,
from ../../llvm-gcc/gcc/gthr.h:114,
from ../../llvm-gcc/gcc/unwind-dw2.c:42:
../../llvm-gcc/gcc/gthr-posix.h:43:21: error: pthread.h: No such file or directo
ry
../../llvm-gcc/gcc/gthr-posix.h:44:20: error: unistd.h: No such file or director
y
In file included from ./gthr-default.h:1,
from ../../llvm-gcc/gcc/gthr.h:114,
from ../../llvm-gcc/gcc/unwind-dw2.c:42:
../../llvm-gcc/gcc/gthr-posix.h:46: error: expected `=', `,', `;', `asm' or `__a
ttribute__' before `__gthread_key_t'
../../llvm-gcc/gcc/gthr-posix.h:47: error: expected `=', `,', `;', `asm' or `__a
ttribute__' before `__gthread_once_t'
../../llvm-gcc/gcc/gthr-posix.h:48: error: expected `=', `,', `;', `asm' or `__a
ttribute__' before `__gthread_mutex_t'
../../llvm-gcc/gcc/gthr-posix.h:49: error: expected `=', `,', `;', `asm' or `__a
ttribute__' before `__gthread_recursive_mutex_t'
../../llvm-gcc/gcc/gthr-posix.h:92: error: `pthread_once' undeclared here (not i
n a function)
../../llvm-gcc/gcc/gthr-posix.h:92: warning: type defaults to `int' in declarati
on of `__gthrw_pthread_once'
../../llvm-gcc/gcc/gthr-posix.h:93: error: `pthread_getspecific' undeclared here
(not in a function)
../../llvm-gcc/gcc/gthr-posix.h:93: warning: type defaults to `int' in declarati
on of `__gthrw_pthread_getspecific'
../../llvm-gcc/gcc/gthr-posix.h:94: error: `pthread_setspecific' undeclared here
(not in a function)
../../llvm-gcc/gcc/gthr-posix.h:94: warning: type defaults to `int' in declarati
on of `__gthrw_pthread_setspecific'
../../llvm-gcc/gcc/gthr-posix.h:95: error: `pthread_create' undeclared here (not
in a function)
../../llvm-gcc/gcc/gthr-posix.h:95: warning: type defaults to `int' in declarati
on of `__gthrw_pthread_create'
../../llvm-gcc/gcc/gthr-posix.h:96: error: `pthread_cancel' undeclared here (not
in a function)
../../llvm-gcc/gcc/gthr-posix.h:96: warning: type defaults to `int' in declarati
on of `__gthrw_pthread_cancel'
../../llvm-gcc/gcc/gthr-posix.h:97: error: `pthread_mutex_lock' undeclared here
(not in a function)
../../llvm-gcc/gcc/gthr-posix.h:97: warning: type defaults to `int' in declarati
on of `__gthrw_pthread_mutex_lock'
../../llvm-gcc/gcc/gthr-posix.h:98: error: `pthread_mutex_trylock' undeclared he
re (not in a function)
../../llvm-gcc/gcc/gthr-posix.h:98: warning: type defaults to `int' in declarati
on of `__gthrw_pthread_mutex_trylock'
../../llvm-gcc/gcc/gthr-posix.h:99: error: `pthread_mutex_unlock' undeclared her
e (not in a function)
../../llvm-gcc/gcc/gthr-posix.h:99: warning: type defaults to `int' in declarati
on of `__gthrw_pthread_mutex_unlock'
../../llvm-gcc/gcc/gthr-posix.h:100: error: `pthread_mutex_init' undeclared here
(not in a function)
../../llvm-gcc/gcc/gthr-posix.h:100: warning: type defaults to `int' in declarat
ion of `__gthrw_pthread_mutex_init'
../../llvm-gcc/gcc/gthr-posix.h:103: error: `pthread_key_create' undeclared here
(not in a function)
../../llvm-gcc/gcc/gthr-posix.h:103: warning: type defaults to `int' in declarat
ion of `__gthrw_pthread_key_create'
../../llvm-gcc/gcc/gthr-posix.h:104: error: `pthread_key_delete' undeclared here
(not in a function)
../../llvm-gcc/gcc/gthr-posix.h:104: warning: type defaults to `int' in declarat
ion of `__gthrw_pthread_key_delete'
../../llvm-gcc/gcc/gthr-posix.h:105: error: `pthread_mutexattr_init' undeclared
here (not in a function)
../../llvm-gcc/gcc/gthr-posix.h:105: warning: type defaults to `int' in declarat
ion of `__gthrw_pthread_mutexattr_init'
../../llvm-gcc/gcc/gthr-posix.h:106: error: `pthread_mutexattr_settype' undeclar
ed here (not in a function)
../../llvm-gcc/gcc/gthr-posix.h:106: warning: type defaults to `int' in declarat
ion of `__gthrw_pthread_mutexattr_settype'
../../llvm-gcc/gcc/gthr-posix.h:107: error: `pthread_mutexattr_destroy' undeclar
ed here (not in a function)
../../llvm-gcc/gcc/gthr-posix.h:107: warning: type defaults to `int' in declarat
ion of `__gthrw_pthread_mutexattr_destroy'
../../llvm-gcc/gcc/gthr-posix.h:572: error: expected `)' before `*' token
../../llvm-gcc/gcc/gthr-posix.h:581: error: expected `)' before `*' token
../../llvm-gcc/gcc/gthr-posix.h:587: error: expected `)' before `key'
../../llvm-gcc/gcc/gthr-posix.h:593: error: expected `)' before `key'
../../llvm-gcc/gcc/gthr-posix.h:599: error: expected `)' before `key'
../../llvm-gcc/gcc/gthr-posix.h:605: error: expected `)' before `*' token
../../llvm-gcc/gcc/gthr-posix.h:614: error: expected `)' before `*' token
../../llvm-gcc/gcc/gthr-posix.h:623: error: expected `)' before `*' token
../../llvm-gcc/gcc/gthr-posix.h:633: error: expected `)' before `*' token
../../llvm-gcc/gcc/gthr-posix.h:654: error: expected `)' before `*' token
../../llvm-gcc/gcc/gthr-posix.h:660: error: expected `)' before `*' token
../../llvm-gcc/gcc/gthr-posix.h:666: error: expected `)' before `*' token
make[3]: *** [libgcc/./unwind-dw2.o] Error 1
make[3]: Leaving directory `/llvm/arm_objects/gcc'
make[2]: *** [libgcc.a] Error 2
make[2]: Leaving directory `/llvm/arm_objects/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/llvm/arm_objects'
make: *** [all] Error 2

?
Can anyone please tell me the problem? 
?
Thanks,
Akramul

--- On Sun, 2/1/11, Bill Wendling <wendling at apple.com> wrote:


From: Bill Wendling <wendling at apple.com>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "akramul azim" <bijoy123_8 at yahoo.com>
Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, llvmdev at cs.uiuc.edu
Date: Sunday, 2 January, 2011, 6:07 AM


On Jan 1, 2011, at 8:29 PM, akramul azim wrote:

> Hi,
>? ???I am planning to follow the steps to install LLVM for the ARM-target (Processor: Xscale, Architecture: armv5te):
>? 
> 1. Install binutils-2.21 (downloaded from gnu.org)
>? 
> Steps:
>? 
> $ ./configure --target=arm-unknown-linux-gnueabi --program-prefix=arm- --prefix
> =/llvm/arm --with-sysroot=/llvm/arms/sys-root
>? 
> $ make
>? 
> $ make install
>? 
> 
> 2. Install LLVM
>? 
> Steps
>? 
> $ ../llvm-src/configure --target=arm-linux --prefix=/llvm/arm --disable-optimiz
> ed --enable-bindings=none --disable-multilib --disable-bootstrap --with-sysroot
> =/llvm/arms/sys-root --with-binutils-include=/llvm/binutils-2.21/include --with
> -llvmgccdir=/llvm/llvm-gcc-4.2
>? 
> $ make
>? 
> $ make install
>? 
> 3. Install LLVM-GCC
>? 
> Steps:
>? 
> $ ../llvm-gcc/configure --target=arm-linux --program-prefix=arm- --prefix=$PWD/
> ../install --disable-optimized --enable-bindings=none --enable-llvm=$PWD/../llv
> m-2.8 --enable-languages=c,c++ --disable-multilib --disable-bootstrap
> $ make
>? 
> $ make install
>? 
>? 
> However, when I try to build LLVM source (second step) by make, I get the following error:
>? 
> llvm[2]: Linking Debug Loadable Module LLVMgold.dll
> /llvm/llvm-src/tools/gold/Debug/gold-plugin.o: In function `all_symbols_read_hoo
> k':
> /llvm/llvm-src/tools/gold/gold-plugin.cpp:364: undefined reference to `_lto_code
> gen_create'

It looks like llvm/tools/lto wasn't built in step 1 (you can check to see if this is so). From the Makefile, it will built tools/lto when ENABLE_PIC is 1. Check to see what ENABLE_PIC is set to in the Makefile.config file. If it's not set, try using the --enable-pic flag during LLVM's configure.

-bw




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/73025ed0/attachment.html 

From evan.cheng at apple.com  Tue Jan  4 13:46:02 2011
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 4 Jan 2011 11:46:02 -0800
Subject: [LLVMdev] X86 -tailcallopt and C calling conversion
In-Reply-To: <AANLkTinf4NsysfiXSOOSh2hv9WfaUUM+rfzzL-wEi7b0@mail.gmail.com>
References: <AANLkTinf4NsysfiXSOOSh2hv9WfaUUM+rfzzL-wEi7b0@mail.gmail.com>
Message-ID: <DB0FD711-8DCC-49DD-A6BF-65E43F70587C@apple.com>


On Jan 1, 2011, at 4:20 PM, NAKAMURA Takumi wrote:

> Happy 2011, everybody!
> 
> It seems -tailcallopt prevents tailcall optimization when both caller
> and callee have ccc,
> even when it is optimized without an option -tailcallopt.

Sorry, I don't understand your question. What do you mean by both caller and callee have ccc?

Evan

> Is it intended or misoptimized?
> 
> In X86ISelLowering.cpp:X86TargetLowering::IsEligibleForTailCallOptimization():
> 
>  if (GuaranteedTailCallOpt) {
>    if (IsTailCallConvention(CalleeCC) && CCMatch)
>      return true;
>    return false;
>  }
> 
> I know -tailcallopt changes calling conversion of fastcc to callee-pop.
> 
> ps. I am tweaking tailcallopt on Win64.
> 
> ...Takumi
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From evan.cheng at apple.com  Tue Jan  4 13:47:47 2011
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 4 Jan 2011 11:47:47 -0800
Subject: [LLVMdev] Bug in MachineInstr::isIdenticalTo
In-Reply-To: <D556DCBBC0EA924A9AC80003B621211205F099E6CC@sausexmbp02.amd.com>
References: <D556DCBBC0EA924A9AC80003B621211205F099E6CC@sausexmbp02.amd.com>
Message-ID: <948BD210-6071-4DC4-A7AA-53475EF87242@apple.com>


On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote:

> I have ran across a case where the function isIdenticalTo is return true for instructions that are not equivalent. The instructions in question are load/store instructions, and is causing a problem with MachineBranchFolding. The problem is this, I have two branches of a switch statement that are identical, except for the size of the store. Here is some cut-down LLVM-IR to showcase the issue:
> switch.case:                                      ; preds = %if.end
>   %tmp53 = extractelement <4 x i32> %format, i32 1 ; <i32> [#uses=1]
>   switch i32 %tmp53, label %if.then [
>     i32 1, label %switch.case55
>     i32 2, label %switch.case61
>   ]
> switch.case55:                                    ; preds = %switch.case
>   %arrayidx = getelementptr i8 addrspace(1)* %conv3, i32 %tmp22 ; <i8 addrspace(1)*> [#uses=1]
>   %tmp59 = extractelement <4 x i32> %9, i32 0     ; <i32> [#uses=1]
>   %conv60 = trunc i32 %tmp59 to i8                ; <i8> [#uses=1]
>   store i8 %conv60, i8 addrspace(1)* %arrayidx
>   ret void
> switch.case61:                                    ; preds = %switch.case
>   %arrayidx64 = getelementptr i16 addrspace(1)* %conv, i32 %tmp22 ; <i16 addrspace(1)*> [#uses=1]
>   %tmp66 = extractelement <4 x i32> %9, i32 0     ; <i32> [#uses=1]
>   %conv67 = trunc i32 %tmp66 to i16               ; <i16> [#uses=1]
>   store i16 %conv67, i16 addrspace(1)* %arrayidx64
>   ret void
>  
> Notice how except for the sizes of the pointer, the sequence is the same. This translates into the following for my backend at the MI level.
> BB#9: derived from LLVM BB %switch.case55
>     Live Ins: %R258 %R260 %R259
>     Predecessors according to CFG: BB#8
>                         %R257<def> = CUSTOM_ADD_i32 %R260<kill>, %R258<kill>
>                         %R258<def> = VEXTRACT_v4i32 %R259<kill>, 1
>                         GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST1[%arrayidx]
>                         RETURN
>  
> BB#10: derived from LLVM BB %switch.case61
>     Live Ins: %R258 %R260 %R259
>     Predecessors according to CFG: BB#7
>                         %R257<def> = LOADCONST_i32 1
>                         %R257<def> = SHL_i32 %R258<kill>, %R257<kill>
>                         %R257<def> = CUSTOM_ADD_i32 %R260<kill>, %R257<kill>
>                         %R258<def> = VEXTRACT_v4i32 %R259<kill>, 1
>                         GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST2[%arrayidx64]
>                         RETURN
>  
> Notice how except for the memory operand size on the truncating store, the last three instructions in BB#7 is the same as BB#8.
>  
> Now looking at isIdenticalTo, I don't see any checks on the memory size. Since I don't encode this information in the instruction, because it is encoded in the memory object, two different instructions can be considered identical for different memory sizes. I believe this is incorrect.
>  
> Here is my proposed patch for the issue:
> Index: MachineInstr.cpp
> ===================================================================
> --- MachineInstr.cpp      (revision 122820)
> +++ MachineInstr.cpp   (working copy)
> @@ -761,9 +761,23 @@
>    // If opcodes or number of operands are not the same then the two
>    // instructions are obviously not identical.
>    if (Other->getOpcode() != getOpcode() ||
> -      Other->getNumOperands() != getNumOperands())
> +      Other->getNumOperands() != getNumOperands() ||
> +      Other->memoperands_empty() != memoperands_empty())
>      return false;
> +  if (!memoperands_empty()) {
> +    // If we have mem operands, make sure that the sizes of the memoperands for each
> +    // MI are the same. The values can be different, so lets only check the sizes.
> +    // If the sizes between one of the memoperands differ, then the instructions are
> +    // not identical.
> +    for (MachineInstr::mmo_iterator mb1 = memoperands_begin(), mb2 = Other->memoperands_begin()
> +        me = memoperands_end(); mb1 != me; ++mb1, ++mb2) {
> +      if (mb1->getSize() != mb2->getSize() ||
> +           mb1->getFlags() != mb2->getFlags() ||
> +           mb1->getOffset() != mb2->getOffset()) {
> +        return false;
> +      }
> +    }
> +  }
> +
>    // Check operands to make sure they match.
>    for (unsigned i = 0, e = getNumOperands(); i != e; ++i) {
>      const MachineOperand &MO = getOperand(i);
>  
> So, my question is,  should isIdenticalTo take the memoperands into account? Is my patch correct? I almost feel like isIdenticalTo needs to be added to MachineMemOperand class.

You are right. It's not safe to return true if any pair of memoperands differ. Your patch looks fine to me.

Evan

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/019fb41c/attachment.html 

From peter at pcc.me.uk  Tue Jan  4 13:51:24 2011
From: peter at pcc.me.uk (Peter Collingbourne)
Date: Tue, 4 Jan 2011 19:51:24 +0000
Subject: [LLVMdev] Function-level metadata for OpenCL (was Re:
	OpenCL	support)
In-Reply-To: <D556DCBBC0EA924A9AC80003B621211205F099E5D6@sausexmbp02.amd.com>
References: <20101216223345.GB1885@pcc.me.uk>
	<AANLkTikAYtbfG6GX07TYHLmzU-u+S7ivWbqs_AnZwFmz@mail.gmail.com>
	<20101220201112.GA26083@pcc.me.uk>
	<20101224234954.GB4631@pcc.me.uk>
	<D556DCBBC0EA924A9AC80003B621211205F099E5D6@sausexmbp02.amd.com>
Message-ID: <20110104195124.GA11575@pcc.me.uk>

On Mon, Jan 03, 2011 at 12:52:02PM -0600, Villmow, Micah wrote:
> Sorry for the late reply, as I have been on vacation for awhile.
> 
> One method which I haven't seen mentioned is to separate out the kernel semantics from the function definition.
> 
> All the kernel attribute does is specify that this function is an entry point to the device from the host. So, why not just create a separate entry point that is only callable by the host and everything from the device goes to the original entry point.
> 
> For example, you have two functions and one calls the other:
> 
> kernel foo() {
> }
> kernel bar() {
>   foo();
> }
> 
> If you separate kernel function from the function body, then handling this becomes easy.
> 
> You end up with four functions:
> 
> kernel foo_kernel() {
>  foo();
> }
> 
> foo() {
> }
> 
> kernel bar_kernel() {
>  bar();
> }
> 
> bar(){
>  foo();
> }
> 
> Then the issue is no longer a compilation problem, but just an entry point runtime issue. Instead of calling foo(), the runtime just calls foo_kernel() which handles all of the kernel setup issues and then calls the function body itself.
> 
> This removes the need to have any metadata nodes in the IR and allows the kernel function to handle any setup issues for the specific device such as __local's, id/group calculations, memory offsets, etc... without having to impact the performance of a kernel calling another kernel. 

I like this idea.  I think that the entry point should keep its
original name though, while we rename the body, because the fact that
we factor out the function body seems like an implementation detail.

To a certain extent it also removes the need to attach metadata for
reqd_work_group_size etc at the function level (if required by the
target), since this information can be attached to intrinsic calls
within the entry point.  Example:

define void @foo() nounwind {
entry:
  call void @llvm.opencl.reqd.work.group.size(i32 4, i32 1, i32 1)
  ; .. other setup ..
  call void @foo_kernel()
  ret void
}

define internal void @foo_kernel() nounwind {
  ; ... body ...
}

These intrinsics wouldn't necessarily expand to target code directly,
but would be used to generate something appropriate for the target in
a similar fashion to the debug metadata intrinsics.  Also, by keeping
the metadata in the entry point we guarantee that no more than one
intrinsic call may appear within a function even if the inliner
is used, allowing code generators to simply search for uses of the
@llvm.opencl.reqd.work.group.size (or whatever) intrinsic to create
a mapping from functions to attributes.

Thanks,
-- 
Peter

From Micah.Villmow at amd.com  Tue Jan  4 13:52:22 2011
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Tue, 4 Jan 2011 13:52:22 -0600
Subject: [LLVMdev] Bug in MachineInstr::isIdenticalTo
In-Reply-To: <948BD210-6071-4DC4-A7AA-53475EF87242@apple.com>
References: <D556DCBBC0EA924A9AC80003B621211205F099E6CC@sausexmbp02.amd.com>
	<948BD210-6071-4DC4-A7AA-53475EF87242@apple.com>
Message-ID: <D556DCBBC0EA924A9AC80003B621211205F099E6D6@sausexmbp02.amd.com>

Well, there are issues with the patch. I didn't compile it when I wrote it up. Also, what about adding isIdenticalTo into the MachineMemOperand class instead of doing the check in MachineInstr. That would simplify this patch and allow the code to be used elsewhere.

My only other concern is the case where there is more than one machine mem operand and the ordering, if sorted, would be equivalent, but is unsorted. Could this case happen?

For example, using my instructions below, the following occurs.
GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST1[%arrayidx] mem:ST2[%arrayidx64]
GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST2[%arrayidx64] mem:ST1[%arrayidx]

Though I've never seen an instruction with two memory operands, the structure allows for it to occur. And the two instructions are technically equivalent, but the ordering is wrong. Is this a valid concern?

Micah

From: Evan Cheng [mailto:evan.cheng at apple.com]
Sent: Tuesday, January 04, 2011 11:48 AM
To: Villmow, Micah
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Bug in MachineInstr::isIdenticalTo


On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote:


I have ran across a case where the function isIdenticalTo is return true for instructions that are not equivalent. The instructions in question are load/store instructions, and is causing a problem with MachineBranchFolding. The problem is this, I have two branches of a switch statement that are identical, except for the size of the store. Here is some cut-down LLVM-IR to showcase the issue:
switch.case:                                      ; preds = %if.end
  %tmp53 = extractelement <4 x i32> %format, i32 1 ; <i32> [#uses=1]
  switch i32 %tmp53, label %if.then [
    i32 1, label %switch.case55
    i32 2, label %switch.case61
  ]
switch.case55:                                    ; preds = %switch.case
  %arrayidx = getelementptr i8 addrspace(1)* %conv3, i32 %tmp22 ; <i8 addrspace(1)*> [#uses=1]
  %tmp59 = extractelement <4 x i32> %9, i32 0     ; <i32> [#uses=1]
  %conv60 = trunc i32 %tmp59 to i8                ; <i8> [#uses=1]
  store i8 %conv60, i8 addrspace(1)* %arrayidx
  ret void
switch.case61:                                    ; preds = %switch.case
  %arrayidx64 = getelementptr i16 addrspace(1)* %conv, i32 %tmp22 ; <i16 addrspace(1)*> [#uses=1]
  %tmp66 = extractelement <4 x i32> %9, i32 0     ; <i32> [#uses=1]
  %conv67 = trunc i32 %tmp66 to i16               ; <i16> [#uses=1]
  store i16 %conv67, i16 addrspace(1)* %arrayidx64
  ret void

Notice how except for the sizes of the pointer, the sequence is the same. This translates into the following for my backend at the MI level.
BB#9: derived from LLVM BB %switch.case55
    Live Ins: %R258 %R260 %R259
    Predecessors according to CFG: BB#8
                        %R257<def> = CUSTOM_ADD_i32 %R260<kill>, %R258<kill>
                        %R258<def> = VEXTRACT_v4i32 %R259<kill>, 1
                        GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST1[%arrayidx]
                        RETURN

BB#10: derived from LLVM BB %switch.case61
    Live Ins: %R258 %R260 %R259
    Predecessors according to CFG: BB#7
                        %R257<def> = LOADCONST_i32 1
                        %R257<def> = SHL_i32 %R258<kill>, %R257<kill>
                        %R257<def> = CUSTOM_ADD_i32 %R260<kill>, %R257<kill>
                        %R258<def> = VEXTRACT_v4i32 %R259<kill>, 1
                        GLOBALTRUNCSTORE_i32 %R258<kill>, %R257<kill>, 8; mem:ST2[%arrayidx64]
                        RETURN

Notice how except for the memory operand size on the truncating store, the last three instructions in BB#7 is the same as BB#8.

Now looking at isIdenticalTo, I don't see any checks on the memory size. Since I don't encode this information in the instruction, because it is encoded in the memory object, two different instructions can be considered identical for different memory sizes. I believe this is incorrect.

Here is my proposed patch for the issue:
Index: MachineInstr.cpp
===================================================================
--- MachineInstr.cpp      (revision 122820)
+++ MachineInstr.cpp   (working copy)
@@ -761,9 +761,23 @@
   // If opcodes or number of operands are not the same then the two
   // instructions are obviously not identical.
   if (Other->getOpcode() != getOpcode() ||
-      Other->getNumOperands() != getNumOperands())
+      Other->getNumOperands() != getNumOperands() ||
+      Other->memoperands_empty() != memoperands_empty())
     return false;
+  if (!memoperands_empty()) {
+    // If we have mem operands, make sure that the sizes of the memoperands for each
+    // MI are the same. The values can be different, so lets only check the sizes.
+    // If the sizes between one of the memoperands differ, then the instructions are
+    // not identical.
+    for (MachineInstr::mmo_iterator mb1 = memoperands_begin(), mb2 = Other->memoperands_begin()
+        me = memoperands_end(); mb1 != me; ++mb1, ++mb2) {
+      if (mb1->getSize() != mb2->getSize() ||
+           mb1->getFlags() != mb2->getFlags() ||
+           mb1->getOffset() != mb2->getOffset()) {
+        return false;
+      }
+    }
+  }
+
   // Check operands to make sure they match.
   for (unsigned i = 0, e = getNumOperands(); i != e; ++i) {
     const MachineOperand &MO = getOperand(i);

So, my question is,  should isIdenticalTo take the memoperands into account? Is my patch correct? I almost feel like isIdenticalTo needs to be added to MachineMemOperand class.

You are right. It's not safe to return true if any pair of memoperands differ. Your patch looks fine to me.

Evan



Thoughts?
Micah
<MI_isIdenticalTo.patch>_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/6cbd8695/attachment-0001.html 

From stoklund at 2pi.dk  Tue Jan  4 13:55:28 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Tue, 4 Jan 2011 11:55:28 -0800
Subject: [LLVMdev] Bug in MachineInstr::isIdenticalTo
In-Reply-To: <D556DCBBC0EA924A9AC80003B621211205F099E6CC@sausexmbp02.amd.com>
References: <D556DCBBC0EA924A9AC80003B621211205F099E6CC@sausexmbp02.amd.com>
Message-ID: <0A9BAB24-9C24-4D38-9414-5E3409ED4994@2pi.dk>


On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote:

> So, my question is,  should isIdenticalTo take the memoperands into account? Is my patch correct? I almost feel like isIdenticalTo needs to be added to MachineMemOperand class.

The MachineMemOperands are supposed to be used for optimizations only, your code should still be correct when stripping all memory operands.

I think you would be better off encoding the store size in the opcode.

/jakob



From Micah.Villmow at amd.com  Tue Jan  4 13:59:19 2011
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Tue, 4 Jan 2011 13:59:19 -0600
Subject: [LLVMdev] Function-level metadata for OpenCL (was Re:
	OpenCL	support)
In-Reply-To: <20110104195124.GA11575@pcc.me.uk>
References: <20101216223345.GB1885@pcc.me.uk>
	<AANLkTikAYtbfG6GX07TYHLmzU-u+S7ivWbqs_AnZwFmz@mail.gmail.com>
	<20101220201112.GA26083@pcc.me.uk> <20101224234954.GB4631@pcc.me.uk>
	<D556DCBBC0EA924A9AC80003B621211205F099E5D6@sausexmbp02.amd.com>
	<20110104195124.GA11575@pcc.me.uk>
Message-ID: <D556DCBBC0EA924A9AC80003B621211205F099E6DB@sausexmbp02.amd.com>



> -----Original Message-----
> From: Peter Collingbourne [mailto:peter at pcc.me.uk]
> Sent: Tuesday, January 04, 2011 11:51 AM
> To: Villmow, Micah
> Cc: Anton Lokhmotov; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Function-level metadata for OpenCL (was Re:
> OpenCL support)
> 
> On Mon, Jan 03, 2011 at 12:52:02PM -0600, Villmow, Micah wrote:
> > Sorry for the late reply, as I have been on vacation for awhile.
> >
> > One method which I haven't seen mentioned is to separate out the
> kernel semantics from the function definition.
> >
> > All the kernel attribute does is specify that this function is an
> entry point to the device from the host. So, why not just create a
> separate entry point that is only callable by the host and everything
> from the device goes to the original entry point.
> >
> > For example, you have two functions and one calls the other:
> >
> > kernel foo() {
> > }
> > kernel bar() {
> >   foo();
> > }
> >
> > If you separate kernel function from the function body, then handling
> this becomes easy.
> >
> > You end up with four functions:
> >
> > kernel foo_kernel() {
> >  foo();
> > }
> >
> > foo() {
> > }
> >
> > kernel bar_kernel() {
> >  bar();
> > }
> >
> > bar(){
> >  foo();
> > }
> >
> > Then the issue is no longer a compilation problem, but just an entry
> point runtime issue. Instead of calling foo(), the runtime just calls
> foo_kernel() which handles all of the kernel setup issues and then
> calls the function body itself.
> >
> > This removes the need to have any metadata nodes in the IR and allows
> the kernel function to handle any setup issues for the specific device
> such as __local's, id/group calculations, memory offsets, etc...
> without having to impact the performance of a kernel calling another
> kernel.
> 
> I like this idea.  I think that the entry point should keep its
> original name though, while we rename the body, because the fact that
> we factor out the function body seems like an implementation detail.
> 
[Villmow, Micah] Well, if the entry point keeps its same name, and the body is renamed, then all of the call sites must also be modified to point to the body and not the entry point. Either way is fine, as long as it is something that I think everyone can agree with.
> To a certain extent it also removes the need to attach metadata for
> reqd_work_group_size etc at the function level (if required by the
> target), since this information can be attached to intrinsic calls
> within the entry point.  Example:
> 
> define void @foo() nounwind {
> entry:
>   call void @llvm.opencl.reqd.work.group.size(i32 4, i32 1, i32 1)
>   ; .. other setup ..
>   call void @foo_kernel()
>   ret void
> }
> 
> define internal void @foo_kernel() nounwind {
>   ; ... body ...
> }
> 
> These intrinsics wouldn't necessarily expand to target code directly,
> but would be used to generate something appropriate for the target in
> a similar fashion to the debug metadata intrinsics.  Also, by keeping
> the metadata in the entry point we guarantee that no more than one
> intrinsic call may appear within a function even if the inliner
> is used, allowing code generators to simply search for uses of the
> @llvm.opencl.reqd.work.group.size (or whatever) intrinsic to create
> a mapping from functions to attributes.
> 
[Villmow, Micah] Have you had any thoughts about bringing this up with Khronos about standardizing some of these ideas/conventions between the multiple vendors that are using LLVM for their OpenCL implementations?
> Thanks,
> --
> Peter




From Micah.Villmow at amd.com  Tue Jan  4 14:13:25 2011
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Tue, 4 Jan 2011 14:13:25 -0600
Subject: [LLVMdev] Bug in MachineInstr::isIdenticalTo
In-Reply-To: <0A9BAB24-9C24-4D38-9414-5E3409ED4994@2pi.dk>
References: <D556DCBBC0EA924A9AC80003B621211205F099E6CC@sausexmbp02.amd.com>
	<0A9BAB24-9C24-4D38-9414-5E3409ED4994@2pi.dk>
Message-ID: <D556DCBBC0EA924A9AC80003B621211205F099E6DF@sausexmbp02.amd.com>



> -----Original Message-----
> From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk]
> Sent: Tuesday, January 04, 2011 11:55 AM
> To: Villmow, Micah
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Bug in MachineInstr::isIdenticalTo
> 
> 
> On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote:
> 
> > So, my question is,  should isIdenticalTo take the memoperands into
> account? Is my patch correct? I almost feel like isIdenticalTo needs to
> be added to MachineMemOperand class.
> 
> The MachineMemOperands are supposed to be used for optimizations only,
> your code should still be correct when stripping all memory operands.
> 
[Villmow, Micah] I disagree with this as nothing in the documentation for the class states that it should be used for optimizations only. From the header file, " A description of a memory reference used in the backend ... This allows it to describe lowered loads and stores. " That is exactly what I am using it for. 
> I think you would be better off encoding the store size in the opcode.
> 
[Villmow, Micah] While it might be nice, this would cause massive instruction opcode bloat. I already have over 500 load/store opcodes and storing the size in the instruction would probably triple or quadruple this amount. So not encoding it in the opcode is a decision to lower the amount of opcodes required.
> /jakob
> 




From ofv at wanadoo.es  Tue Jan  4 14:16:03 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Tue, 04 Jan 2011 21:16:03 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	(arrowdodger's message of "Tue, 4 Jan 2011 18:45:01 +0300")
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
Message-ID: <87hbdo1l30.fsf@telefonica.net>

arrowdodger <6yearold at gmail.com> writes:

> Hello. I see many discrepancies in config.h file generated by CMake and
> autoheader.
>
> Most of them are following:
> In autofoo-generated config:
>
>> /* Define to 1 if you have the `<name>' function. */
>> #define HAVE_<name> 1
>>
> but in CMake-generated:
>
>> #undef HAVE_<name>
>>
> This happens because in config.h.cmake (config.h.in analog) these functions
> just are not checked for.

Right.

> Another difference:
> autofoo sets this by default:
>
>> #define ENABLE_PIC 1
>>
> while CMake not.
>
> There are many other differencies, which bother me, so here is the question:
> is it harmless and if not - should i try to fix it?

AFAIK a typical autoconf setup does not start from scratch. It reuses
scripts or templates taken from some other project or from autoconf
itself. This means that lots of stuff listed on config.h is not
actually used by the LLVM C++ sources. The macro ENABLE_PIC is one
example.

config.h.cmake was derived from config.h.in and not all tests were
implemented. It would be nice to test them all, just for the sake of
coherence. Or to say it with other words: patches welcome.

From anton at korobeynikov.info  Tue Jan  4 14:41:46 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 4 Jan 2011 23:41:46 +0300
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <987883.83150.qm@web121709.mail.ne1.yahoo.com>
References: <34AE5D31-1133-41AF-AE5E-F09C4B9DB774@apple.com>
	<987883.83150.qm@web121709.mail.ne1.yahoo.com>
Message-ID: <AANLkTim5OYEc=TRvH6yBT0xK0qrjX4JuUEvXeK8S_q2u@mail.gmail.com>

> Can anyone please tell me the problem?
It seems you don't have the standard C library for ARM around.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From echristo at apple.com  Tue Jan  4 15:21:22 2011
From: echristo at apple.com (Eric Christopher)
Date: Tue, 4 Jan 2011 13:21:22 -0800
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
Message-ID: <EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>


On Jan 4, 2011, at 7:45 AM, arrowdodger wrote:

> Hello. I see many discrepancies in config.h file generated by CMake and autoheader.
> 
> Most of them are following:
> In autofoo-generated config:
> /* Define to 1 if you have the `<name>' function. */
> #define HAVE_<name> 1
> but in CMake-generated:
> #undef HAVE_<name>
> This happens because in config.h.cmake (config.h.in analog) these functions just are not checked for.
> 

We may just not use those functions anymore - do you have a list of these?

> Another difference:
> autofoo sets this by default:
> #define ENABLE_PIC 1
> while CMake not.
> 

This is more concerning - maybe it's a windows specific problem that came along?

-eric

From clattner at apple.com  Tue Jan  4 15:32:07 2011
From: clattner at apple.com (Chris Lattner)
Date: Tue, 4 Jan 2011 13:32:07 -0800
Subject: [LLVMdev] Bug in MachineInstr::isIdenticalTo
In-Reply-To: <D556DCBBC0EA924A9AC80003B621211205F099E6DF@sausexmbp02.amd.com>
References: <D556DCBBC0EA924A9AC80003B621211205F099E6CC@sausexmbp02.amd.com>
	<0A9BAB24-9C24-4D38-9414-5E3409ED4994@2pi.dk>
	<D556DCBBC0EA924A9AC80003B621211205F099E6DF@sausexmbp02.amd.com>
Message-ID: <3CD63932-8BEA-4145-B0CB-EF5C742215D9@apple.com>


On Jan 4, 2011, at 12:13 PM, Villmow, Micah wrote:

>> I think you would be better off encoding the store size in the opcode.
>> 
> [Villmow, Micah] While it might be nice, this would cause massive instruction opcode bloat. I already have over 500 load/store opcodes and storing the size in the instruction would probably triple or quadruple this amount. So not encoding it in the opcode is a decision to lower the amount of opcodes required.

Jakob is right in this instance.  If you don't want to encode this in the *opcode* you can always add it as an imm operand to the instruction, avoiding bloat.

-Chris

From harip at vt.edu  Tue Jan  4 16:19:51 2011
From: harip at vt.edu (Hari Pyla)
Date: Tue, 04 Jan 2011 17:19:51 -0500
Subject: [LLVMdev] force inlineing a function using opt
Message-ID: <4D239D07.6040609@vt.edu>

Hi,
  I am instrumenting the stores in a program by inserting a function 
call (store_prologue) before every store instruction in the IR file. I 
set the prologue function's attribute to "AlwaysInline" using 
addFnAttr(). In the program the prologue function is defined as static 
inline. I am using opt to generate an optimized (inline the calls to the 
store prologue) using the following options "-always-inline". I also 
tried "-inline". However, the calls to the prologue function are not 
inlined. I was wondering if I am doing something wrong?. Is there any 
way to force inline a function. I really appreciate your help.

  Best,
  --Hari




From yuri at rawbw.com  Tue Jan  4 16:50:39 2011
From: yuri at rawbw.com (Yuri)
Date: Tue, 04 Jan 2011 14:50:39 -0800
Subject: [LLVMdev] libLLVM-2.9svn.dylib on MaxOS is built with double lib in
	it: lib/lib/libLLVM-2.9svn.dylib
Message-ID: <4D23A43F.3020201@rawbw.com>

This started somewhere before rev.122456, resulting libLLVM-2.9svn.dylib 
is unusabkle since it has double 'lib' embedded in its path.

otool -l /opt/local/llvm/svn-r122842/lib/libLLVM-2.9svn.dylib
produces this line (among others):
name /opt/local/llvm/svn-r122842/lib/lib/libLLVM-2.9svn.dylib (offset 24)

The way how things are on Apple, all apps read this path during link 
phase, look for it during dynamic linking and fail.

Yuri

From vmle at ucdavis.edu  Tue Jan  4 17:37:14 2011
From: vmle at ucdavis.edu (Vu Le)
Date: Tue, 4 Jan 2011 17:37:14 -0600
Subject: [LLVMdev] CodeExtractor.cpp potential bug?
In-Reply-To: <194BC6F9-70CA-4120-8DA8-5041C302BFE9@apple.com>
References: <AANLkTimr4kspHOmzAhO=tHyxAZbmDyEmfBa3Um7kupJ-@mail.gmail.com>
	<194BC6F9-70CA-4120-8DA8-5041C302BFE9@apple.com>
Message-ID: <AANLkTinRj6gvKA4_fsV8Gni9QgE07yo-CBptZfJeqVGZ@mail.gmail.com>

Thank you, Cameron.
I also think Dominator::splitBasicBlock() is kind of OK, except the
assertion at line 232 (Dominator.h)
That assertion fails when we split the entry basic block (obviously, it does
not have any dominator).

What I asked for was the use of splitBasicBlock in CodeExtractor.cpp, line
145.
Vu

On Mon, Jan 3, 2011 at 3:25 PM, Cameron Zwarich <zwarich at apple.com> wrote:

> On Dec 31, 2010, at 11:20 AM, Vu Le wrote:
>
> > There might be a misuse of DominatorTree::splitBasicBlock in
> CodeExtractor.cpp, line 145.
> > Header is splited into two (OldPred->NewBB).
> >
> > Line 145 updates the dominator tree by calling
> DT->splitBasicBlock(NewBB).
> > I think it should be DT->splitBasicBlock(OldPred).
> >
> > When I tried to extract a code region whose header has 2 successors, my
> pass crashed.
> > It was because header (or OldPred) is the block that was splited, not
> NewBB.
> > DominatorTree::splitBasicBlock(BB) requires BB to have one successor.
>
>
> The code in Dominator::splitBasicBlock() looks correct, but I think the
> comment and assert may not be. I was writing a patch where I hit the same
> issue.
>
> Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/13e6e6e6/attachment.html 

From criswell at ad.uiuc.edu  Tue Jan  4 20:04:25 2011
From: criswell at ad.uiuc.edu (Criswell, John T)
Date: Tue, 4 Jan 2011 20:04:25 -0600
Subject: [LLVMdev] force inlineing a function using opt
In-Reply-To: <4D239D07.6040609@vt.edu>
References: <4D239D07.6040609@vt.edu>
Message-ID: <32AC7D48FD55284CB56FE956E7F9FCD22469797DEB@DSMAILBOX.ad.uiuc.edu>

If I understand correctly, you're saying that the C source definition of the prologue function is declared as static.  If you compile that function to LLVM IR, it will get interal linkage and will not be visible to functions in other compilation units; instead, it will get renamed if there is a function defined with the same name.  As such, it will never get inlined as the instrumented code will be calling a "different" function.

Try making the C source definition externally visible (i.e., remove the static keyword) and see if it fixes the problem.

-- John T.

________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hari Pyla [harip at vt.edu]
Sent: Tuesday, January 04, 2011 4:19 PM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] force inlineing a function using opt

Hi,
  I am instrumenting the stores in a program by inserting a function
call (store_prologue) before every store instruction in the IR file. I
set the prologue function's attribute to "AlwaysInline" using
addFnAttr(). In the program the prologue function is defined as static
inline. I am using opt to generate an optimized (inline the calls to the
store prologue) using the following options "-always-inline". I also
tried "-inline". However, the calls to the prologue function are not
inlined. I was wondering if I am doing something wrong?. Is there any
way to force inline a function. I really appreciate your help.

  Best,
  --Hari



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


From geek4civic at gmail.com  Tue Jan  4 21:07:26 2011
From: geek4civic at gmail.com (NAKAMURA Takumi)
Date: Wed, 5 Jan 2011 12:07:26 +0900
Subject: [LLVMdev] X86 -tailcallopt and C calling conversion
In-Reply-To: <DB0FD711-8DCC-49DD-A6BF-65E43F70587C@apple.com>
References: <AANLkTinf4NsysfiXSOOSh2hv9WfaUUM+rfzzL-wEi7b0@mail.gmail.com>
	<DB0FD711-8DCC-49DD-A6BF-65E43F70587C@apple.com>
Message-ID: <AANLkTimALfiKSCos0rCmbcWLQQLNN++GMaEuSbh7Ef7f@mail.gmail.com>

Hello Evan,

I am sorry for my poor question.
s/ccc/default calling conversion/g ;)
("ccc" should be accepted as calling conversion specifier)

When "-tailcallopt" is specified (GuaranteedTailCallOpt),
tailcall optimizer would not touch functions of default calling conversion.


; for example
define void @caller_c() nounwind {
entry:
  tail call void @callee_c()
  ret void
}
declare void @callee_c() nounwind

define fastcc void @caller_f() nounwind {
entry:
  tail call fastcc void @callee_f()
  ret void
}
declare fastcc void @callee_f() nounwind


On {i686|x86_64}-linux without -tailcallopt,
caller_c:
        jmp     callee_c                # TAILCALL
caller_f:
        jmp     callee_f                # TAILCALL


With -tailcallopt, (on x86-64. simila on i686 too)
caller_c:
        pushq   %rax
        callq   callee_c
        popq    %rax
        ret
caller_f:
        pushq   %rax
        popq    %rax
        jmp     callee_f                # TAILCALL


...Takumi

From jacob.zimmermann at oracle.com  Tue Jan  4 21:32:40 2011
From: jacob.zimmermann at oracle.com (Jacob Zimmermann)
Date: Wed, 05 Jan 2011 13:32:40 +1000
Subject: [LLVMdev] Questions about debug info in LLVM 2.8
Message-ID: <4D23E658.6010203@oracle.com>

 Hi,

I'm currently porting some code from LLVM 2.6 to 2.8 and need to be able
to extract the debug info produced by LLVM-GCC and stored in the
compiled .bc file. However I admit I'm slightly confused about how
exactly to do that, the documentation doesn't seem to be very clear
about this, it mainly describes how to *generate* debug info.
Specifically I'm wondering about the following points:

1) It seems that the various DIDescriptors contain the information I'd
need, but they can only be constructed from a MDNode How do I retrieve
the MDNode at the first place? Does MDNode::get() actually retrieve all
the debug metadata from Module, or does it merely initialise a fresh MDNode?

2) DebugLoc has a getAsMDNode() method, but apparently it's only
available for Instructions?

3) How can I retrieve a DIType instance? I can't find a way to obtain a
MDNode for a Type... ?

Many thanks if somebody can shed some light on this.

Best regards,
Jacob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 896 bytes
Desc: OpenPGP digital signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110105/cb4200be/attachment.bin 

From harip at vt.edu  Tue Jan  4 21:38:28 2011
From: harip at vt.edu (Hari Pyla)
Date: Tue, 4 Jan 2011 22:38:28 -0500
Subject: [LLVMdev] force inlineing a function using opt
In-Reply-To: <32AC7D48FD55284CB56FE956E7F9FCD22469797DEB@DSMAILBOX.ad.uiuc.edu>
References: <4D239D07.6040609@vt.edu>
	<32AC7D48FD55284CB56FE956E7F9FCD22469797DEB@DSMAILBOX.ad.uiuc.edu>
Message-ID: <D1E44095-01A6-4408-A408-0410CB605371@vt.edu>

Hi John,
 Thank you for the email. I tried both static inline and also inline but neither of them worked. I am listing a code snippet to
illustrate precisely the approach I tried. My overall objective is to instrument stores in a program. I am instrumenting stores in the program by inserting the store_inst_prologue function in the IR.

My source program:

#include<stdio.h>
#include<stdlib.h>
#include<stdint.h>

inline void store_inst_prologue(unsigned long ptr, int len);
void foo(unsigned long ptr, int len);

__thread uint8_t instrument=0;

void foo(unsigned long ptr, int len)
{
  printf("store address: %p, len: %d\n", ptr, len);
}

inline void store_inst_prologue(unsigned long ptr, int len)
{
  if (instrument!=0)
        foo(ptr, len);
}

int a=10;
int main()
{
 int b=20;

 //explicit call to prologue fn to avoid dead code elimination
 store_inst_prologue (100, 42);

 a =42;
 b =a*2;

 return 0;
}

I am generating an IR using the following command
$llvm-gcc -emit-llvm -S test.c -o test.ll

Then I am running my parser built using the LLVM API to instrument stores in the test.ll to form test_instrumented.ll
My parser takes the test.ll file and iterates over all the instructions and inserts a call instruction before every store instruction in IR.

In my parser code, while creating the signature for the store prologue fn, I set its attribute to "AlwaysInline" using the addFnattr() method.
I can send you the parser code if you think it helps. 

//input to parser (test.ll)  
?.
?.
define i32 @main() nounwind {
entry:
  %retval = alloca i32                            ; <i32*> [#uses=2]
  %0 = alloca i32                                 ; <i32*> [#uses=2]
  %b = alloca i32                                 ; <i32*> [#uses=2]
  %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
  store i32 20, i32* %b, align 4
  call void @store_inst_prologue(i64 100, i32 42) nounwind inlinehint
  store i32 42, i32* @a, align 4
  %1 = load i32* @a, align 4                      ; <i32> [#uses=1]
  %2 = mul nsw i32 %1, 2                          ; <i32> [#uses=1]
  store i32 %2, i32* %b, align 4
  store i32 0, i32* %0, align 4
  %3 = load i32* %0, align 4                      ; <i32> [#uses=1]
  store i32 %3, i32* %retval, align 4
  br label %return

return:                                           ; preds = %entry
  %retval1 = load i32* %retval                    ; <i32> [#uses=1]
  ret i32 %retval1
}

//output from parser (test_instrumented.ll)
?.
?.
define i32 @main() nounwind {
entry:
  %retval = alloca i32                            ; <i32*> [#uses=3]
  %0 = alloca i32                                 ; <i32*> [#uses=3]
  %b = alloca i32                                 ; <i32*> [#uses=4]
  %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
  %1 = ptrtoint i32* %b to i64                    ; <i64> [#uses=1]
=> call void @store_inst_prologue(i64 %1, i32 4) nounwind
  store i32 20, i32* %b, align 4
  call void @store_inst_prologue(i64 100, i32 42) nounwind inlinehint
=> call void @store_inst_prologue(i64 ptrtoint (i32* @a to i64), i32 4) nounwind
  store i32 42, i32* @a, align 4
  %2 = load i32* @a, align 4                      ; <i32> [#uses=1]
  %3 = mul nsw i32 %2, 2                          ; <i32> [#uses=1]
  %4 = ptrtoint i32* %b to i64                    ; <i64> [#uses=1]
=> call void @store_inst_prologue(i64 %4, i32 4) nounwind
  store i32 %3, i32* %b, align 4
  %5 = ptrtoint i32* %0 to i64                    ; <i64> [#uses=1]
=> call void @store_inst_prologue(i64 %5, i32 4) nounwind
  store i32 0, i32* %0, align 4
  %6 = load i32* %0, align 4                      ; <i32> [#uses=1]
  %7 = ptrtoint i32* %retval to i64               ; <i64> [#uses=1]
=> call void @store_inst_prologue(i64 %7, i32 4) nounwind
  store i32 %6, i32* %retval, align 4
  br label %return

return:                                           ; preds = %entry
  %retval1 = load i32* %retval                    ; <i32> [#uses=1]
  ret i32 %retval1
}

I am correctly able to instrument the stores. I am now using opt to make the store_inst_prologue function calls inlined.
I used the following command
$opt -always-inline -inline test_instrumented.ll -S  -o test_instrumented.s

However, in the test_instrumented.s file the calls still remain as opposed to being inlined. I was wondering if I am doing something wrong or what would would be the best way to make the store_inst_prologue inline. I really appreciate your help.

Thanks,
--Hari

 

On Jan 4, 2011, at 9:04 PM, Criswell, John T wrote:

> If I understand correctly, you're saying that the C source definition of the prologue function is declared as static.  If you compile that function to LLVM IR, it will get interal linkage and will not be visible to functions in other compilation units; instead, it will get renamed if there is a function defined with the same name.  As such, it will never get inlined as the instrumented code will be calling a "different" function.
> 
> Try making the C source definition externally visible (i.e., remove the static keyword) and see if it fixes the problem.
> 
> -- John T.
> 
> ________________________________________
> From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hari Pyla [harip at vt.edu]
> Sent: Tuesday, January 04, 2011 4:19 PM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] force inlineing a function using opt
> 
> Hi,
>  I am instrumenting the stores in a program by inserting a function
> call (store_prologue) before every store instruction in the IR file. I
> set the prologue function's attribute to "AlwaysInline" using
> addFnAttr(). In the program the prologue function is defined as static
> inline. I am using opt to generate an optimized (inline the calls to the
> store prologue) using the following options "-always-inline". I also
> tried "-inline". However, the calls to the prologue function are not
> inlined. I was wondering if I am doing something wrong?. Is there any
> way to force inline a function. I really appreciate your help.
> 
>  Best,
>  --Hari
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From harip at vt.edu  Tue Jan  4 22:01:00 2011
From: harip at vt.edu (Hari Pyla)
Date: Tue, 4 Jan 2011 23:01:00 -0500
Subject: [LLVMdev] force inlineing a function using opt
In-Reply-To: <32AC7D48FD55284CB56FE956E7F9FCD22469797DEB@DSMAILBOX.ad.uiuc.edu>
References: <4D239D07.6040609@vt.edu>
	<32AC7D48FD55284CB56FE956E7F9FCD22469797DEB@DSMAILBOX.ad.uiuc.edu>
Message-ID: <9D63FD03-6E67-427D-A6A9-3FB3DA80D93C@vt.edu>

Kindly ignore my previous message. Using inline instead of static inline worked. 

Thanks,
--Hari

On Jan 4, 2011, at 9:04 PM, Criswell, John T wrote:

> If I understand correctly, you're saying that the C source definition of the prologue function is declared as static.  If you compile that function to LLVM IR, it will get interal linkage and will not be visible to functions in other compilation units; instead, it will get renamed if there is a function defined with the same name.  As such, it will never get inlined as the instrumented code will be calling a "different" function.
> 
> Try making the C source definition externally visible (i.e., remove the static keyword) and see if it fixes the problem.
> 
> -- John T.
> 
> ________________________________________
> From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hari Pyla [harip at vt.edu]
> Sent: Tuesday, January 04, 2011 4:19 PM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] force inlineing a function using opt
> 
> Hi,
>  I am instrumenting the stores in a program by inserting a function
> call (store_prologue) before every store instruction in the IR file. I
> set the prologue function's attribute to "AlwaysInline" using
> addFnAttr(). In the program the prologue function is defined as static
> inline. I am using opt to generate an optimized (inline the calls to the
> store prologue) using the following options "-always-inline". I also
> tried "-inline". However, the calls to the prologue function are not
> inlined. I was wondering if I am doing something wrong?. Is there any
> way to force inline a function. I really appreciate your help.
> 
>  Best,
>  --Hari
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From yuri at rawbw.com  Tue Jan  4 23:47:33 2011
From: yuri at rawbw.com (Yuri)
Date: Tue, 04 Jan 2011 21:47:33 -0800
Subject: [LLVMdev] Why gdb on MacOS doesn't show function names in stack
 when llvm::JITEmitDebugInfo is set?
Message-ID: <4D2405F5.7050108@rawbw.com>

With the same source code, gdb on Linux shows function names and on 
MacOS it doesn't.

Why would MacOS be different in respect of this issue?

Yuri

From reid.kleckner at gmail.com  Tue Jan  4 23:58:41 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Tue, 4 Jan 2011 22:58:41 -0700
Subject: [LLVMdev] Why gdb on MacOS doesn't show function names in stack
 when llvm::JITEmitDebugInfo is set?
In-Reply-To: <AANLkTinK0t91kML+PkP6mVrM=SL=VmVOEqHiKJGVU2Ly@mail.gmail.com>
References: <4D2405F5.7050108@rawbw.com>
	<AANLkTinK0t91kML+PkP6mVrM=SL=VmVOEqHiKJGVU2Ly@mail.gmail.com>
Message-ID: <AANLkTimmspS9LePekWXx+C-eDZYL8WgpxcVH9wXirpeP@mail.gmail.com>

Because OS X is not an ELF target, and support was only implemented in LLVM
for making ELFs with debug info.

I think the docs I wrote on this may suggest that the FSF gdb 7.0+ will
work, but that's not the case.

Sent from phne
Reid

On Jan 4, 2011 10:50 PM, "Yuri" <yuri at rawbw.com> wrote:

With the same source code, gdb on Linux shows function names and on
MacOS it doesn't.

Why would MacOS be different in respect of this issue?

Yuri
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/040941b4/attachment.html 

From neal.wang at gmail.com  Wed Jan  5 00:16:52 2011
From: neal.wang at gmail.com (Neal  N. Wang)
Date: Tue, 4 Jan 2011 22:16:52 -0800
Subject: [LLVMdev] Passing options to opt
Message-ID: <AANLkTikWWPE0fgJYN6MdfVmQsv9NR55AVbLKbje2Jy3q@mail.gmail.com>

Hi Folk,

This question might be better suitable for clang mailing list.  Please
forgive me for asking it here first.  In the llvm-gcc front-end, there is an
option -mllvm that passes its following string as the option to opt, I'm
wondering if clang also has a similar option. If yes, what is it?

Thanks,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110104/46a9f98b/attachment.html 

From chenwj at iis.sinica.edu.tw  Wed Jan  5 01:23:51 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Wed, 5 Jan 2011 15:23:51 +0800
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20101230015403.GA4747@cs.nctu.edu.tw>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
Message-ID: <20110105072351.GA76853@cs.nctu.edu.tw>

Hi, folks

  I am "stll" trying to build LLVM-GCC 4.2 on a Linux/PS3 machine, which
has a 64-bit OS.

  Here is my system information and configuration options:

-----------------------------------------------------------------
$ uname -a
Linux ps3 2.6.32-rc2-00995-g96ebbe6-dirty #2 SMP Fri Oct 2 15:12:28 CST
2009 ppc64 Cell Broadband Engine, altivec supported GNU/Linux
$ gcc --version
gcc (Gentoo 4.4.4-r2 p1.3, pie-0.4.5) 4.4.4
$ ../llvm-gcc-4.2-2.8.source/configure --prefix=/tmp/chenwj/install
--disable-multilib --program-prefix=llvm-
--enable-llvm=/tmp/chenwj/install --enable-languages=c,c++
-----------------------------------------------------------------
 
  And here is the compiling error,

------------------------------------------------------------------
/tmp/chenwj/build/./prev-gcc/xgcc -B/tmp/chenwj/build/./prev-gcc/
-B/tmp/chenwj/install/powerpc64-unknown-linux-gnu/bin/   -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wmissing-format-attribute    -DHAVE_CONFIG_H
-DGENERATOR_FILE  -o build/genmodes \
            build/genmodes.o build/errors.o .././libiberty/libiberty.a
build/genmodes -h > tmp-modes.h
/bin/sh: line 1:  9623 Segmentation fault      build/genmodes -h >
tmp-modes.h
make[3]: *** [s-modes-h] Error 139
make[3]: Leaving directory `/tmp/chenwj/build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/tmp/chenwj/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/tmp/chenwj/build'
make: *** [all] Error 2
------------------------------------------------------------------

  Any suggestion appreciated.

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From shigoto.shin at gmail.com  Wed Jan  5 02:11:42 2011
From: shigoto.shin at gmail.com (Shin)
Date: Wed, 5 Jan 2011 00:11:42 -0800
Subject: [LLVMdev] VMKit - Getting Started
Message-ID: <AANLkTikGGAm4ahC3sqHLgXkAGBhjVEyc-bC+wDbBunw_@mail.gmail.com>

Hi all,

I tried the step of the Getting Started page
(http://vmkit.llvm.org/get_started.html) on Linux/x64 but I had no
luck.
I could build them. But when I tried to execute J3, it shows like follows,

>> j3: JavaRuntimeJIT.cpp:367: void* j3StartJNI(uint32*, uint32**, mvm::KnownFrame*): Assertion `th->getLastSP() == th->lastKnownFrame->currentFP' failed.

Does anybody know if the latest LLVM works with the latest VMkit?
Which version of LLVM should I use?
I also tried VMkit with MMtk and I could not let it work...

What is the advantage of using MMtk in VMkit?
I understand that is an accurate garbage collector and it sounds
better than conservative one.
Does anybody have actual comparison about the throughput and the response time?
Which one is more stable?

Thank you.

Shin

From mle+cl at mega-nerd.com  Wed Jan  5 02:36:21 2011
From: mle+cl at mega-nerd.com (Erik de Castro Lopo)
Date: Wed, 5 Jan 2011 19:36:21 +1100
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20110105072351.GA76853@cs.nctu.edu.tw>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
Message-ID: <20110105193621.b1e69874.mle+cl@mega-nerd.com>

??? wrote:

> Linux ps3 2.6.32-rc2-00995-g96ebbe6-dirty #2 SMP Fri Oct 2 15:12:28 CST
> 2009 ppc64 Cell Broadband Engine, altivec supported GNU/Linux

Yes, the kenel is 64 bit, but you may still have a pure 32
bit userspace (thats what my dual G5 PowerMac running Linux
has).

Does your maching have directories like /lib64 and /usr/lib64?

If you compile a program like:

    #include <stdio.h>
    int main (void) {
        printf ("sizeof (void*) : %zd\n", sizeof (void*)) ;
        return 0 ;
    }

what is the size of a void pointer?

Does this change if you add -m64 to the gcc command line?

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From chenwj at iis.sinica.edu.tw  Wed Jan  5 02:55:58 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Wed, 5 Jan 2011 16:55:58 +0800
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20110105193621.b1e69874.mle+cl@mega-nerd.com>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<20110105193621.b1e69874.mle+cl@mega-nerd.com>
Message-ID: <20110105085558.GA84982@cs.nctu.edu.tw>

Hi, Erik

  Thanks for your reply.

> Does your maching have directories like /lib64 and /usr/lib64?
Yes, it has /lib64 and /usr/lib64.

> what is the size of a void pointer?
$ ./a.out
sizeof (void*) : 8

> Does this change if you add -m64 to the gcc command line?
No.

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From mle+cl at mega-nerd.com  Wed Jan  5 03:46:43 2011
From: mle+cl at mega-nerd.com (Erik de Castro Lopo)
Date: Wed, 5 Jan 2011 20:46:43 +1100
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20110105085558.GA84982@cs.nctu.edu.tw>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<20110105193621.b1e69874.mle+cl@mega-nerd.com>
	<20110105085558.GA84982@cs.nctu.edu.tw>
Message-ID: <20110105204643.f7fc5245.mle+cl@mega-nerd.com>

??? wrote:

> > Does your maching have directories like /lib64 and /usr/lib64?
> Yes, it has /lib64 and /usr/lib64.
> 
> > what is the size of a void pointer?
> $ ./a.out
> sizeof (void*) : 8
> 
> > Does this change if you add -m64 to the gcc command line?
> No.

Ok, as far as I cam tell, everything on your system is
correct.

I don't have any further ideas for you to test.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From nicolas.geoffray at gmail.com  Wed Jan  5 04:03:46 2011
From: nicolas.geoffray at gmail.com (nicolas geoffray)
Date: Wed, 5 Jan 2011 11:03:46 +0100
Subject: [LLVMdev] VMKit - Getting Started
In-Reply-To: <AANLkTikGGAm4ahC3sqHLgXkAGBhjVEyc-bC+wDbBunw_@mail.gmail.com>
References: <AANLkTikGGAm4ahC3sqHLgXkAGBhjVEyc-bC+wDbBunw_@mail.gmail.com>
Message-ID: <AANLkTimfwuwwoh7v_1a0YU4Xq7J6auX6KeyApquK-5oR@mail.gmail.com>

Hi Shin,

The latest LLVM works with VMKit on a 32bit machine. I don't have easy
access to a 64bit machine to debug your error, so building for 32bit will
help you. Besides, the MMTk GC does not work on 64bit.

MMTk has way better performance and scalability than the GC that was
originally in VMKit. See the academic papers related to MMTk as references
(ICSE'04). The original GC in VMKit did not scale well and was consuming too
much memory per object. It also does not work on 64bit.

Nicolas

On Wed, Jan 5, 2011 at 9:11 AM, Shin <shigoto.shin at gmail.com> wrote:

> Hi all,
>
> I tried the step of the Getting Started page
> (http://vmkit.llvm.org/get_started.html) on Linux/x64 but I had no
> luck.
> I could build them. But when I tried to execute J3, it shows like follows,
>
> >> j3: JavaRuntimeJIT.cpp:367: void* j3StartJNI(uint32*, uint32**,
> mvm::KnownFrame*): Assertion `th->getLastSP() ==
> th->lastKnownFrame->currentFP' failed.
>
> Does anybody know if the latest LLVM works with the latest VMkit?
> Which version of LLVM should I use?
> I also tried VMkit with MMtk and I could not let it work...
>
> What is the advantage of using MMtk in VMkit?
> I understand that is an accurate garbage collector and it sounds
> better than conservative one.
> Does anybody have actual comparison about the throughput and the response
> time?
> Which one is more stable?
>
> Thank you.
>
> Shin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110105/37fb5ca0/attachment-0001.html 

From 6yearold at gmail.com  Wed Jan  5 04:13:26 2011
From: 6yearold at gmail.com (arrowdodger)
Date: Wed, 5 Jan 2011 13:13:26 +0300
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
 and autofoo builds
In-Reply-To: <EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
Message-ID: <AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>

>
> We may just not use those functions anymore - do you have a list of these?
>
Yes, i've started to make up a list of those functions, but it haven't
finished yet.


> This is more concerning - maybe it's a windows specific problem that came
> along?
>
Not sure, i haven't look yet for CMake checking code itself. By the way, i'm
using FreeBSD.

Or to say it with other words: patches welcome.
>
So, how should i proceed? Make CMake-generated config to be identical to
autotools one? Or cleanup both headers from unused stuff by Eric's
suggestion?
The latter seems more complex to me, since i see no other way except
grep'ing all code for #define's and remove those, which aren't used
anywhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110105/c460a906/attachment.html 

From anton at korobeynikov.info  Wed Jan  5 05:14:59 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 5 Jan 2011 14:14:59 +0300
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20110105072351.GA76853@cs.nctu.edu.tw>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
Message-ID: <AANLkTik7B486GR5fSQj5shyBN_-2Hds6aBho943u2FF=@mail.gmail.com>

Hello

> ? ? ? ? ? ?build/genmodes.o build/errors.o .././libiberty/libiberty.a
> build/genmodes -h > tmp-modes.h
> /bin/sh: line 1: ?9623 Segmentation fault ? ? ?build/genmodes -h >
Here genmodes is already built via llvm. Given that there is no proper
ppc-linux/ppc64-linux codegen support, it's not unexpected that you're
seeing a segfault here.

Try to configure with --disable-bootstrap

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From kalle.raiskila at nokia.com  Wed Jan  5 07:48:48 2011
From: kalle.raiskila at nokia.com (Kalle Raiskila)
Date: Wed, 05 Jan 2011 15:48:48 +0200
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20110105072351.GA76853@cs.nctu.edu.tw>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
Message-ID: <1294235328.1880.16.camel@LLVMbuilder.research.nokia.com>

On ons, 2011-01-05 at 15:23 +0800, ext ??? wrote:
> Hi, folks
> 
>   I am "stll" trying to build LLVM-GCC 4.2 on a Linux/PS3 machine, which
> has a 64-bit OS.

Don't know if it helps, but clang at least builds nicely. Unfortunately
I have a 32bit runtime installed and this seems to cause problems
somewhere - clang defaults to 64bit assembly (if I understood the output
correctly), and the assembly made from running 
'clang --ccc-host-triple=powerpc-linux-gnu' is not accepted by the
default system assembler. It might work better on a 64bit system. 

And I probably should file a bug. Is ppc32 still maintained?


kalle

-- 
"Modern computing machines are very complex objects"
                      -von Neumann introducing the NORC, 1954


From bijoy123_8 at yahoo.com  Wed Jan  5 08:13:23 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Wed, 5 Jan 2011 06:13:23 -0800 (PST)
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <AANLkTim5OYEc=TRvH6yBT0xK0qrjX4JuUEvXeK8S_q2u@mail.gmail.com>
Message-ID: <871739.6013.qm@web121705.mail.ne1.yahoo.com>

Can you please tell me what should I do at this point? How to get the standard C library for ARM around?

I also tried to build? http://llvm.org/svn/llvm-project/llvm/trunk/utils/crosstool/ in CYGWIN. However, my LLVM building was failed when I run the script. I am in dilemma what steps i should follow. Please help me.

Thanks a lot
Akramul

--- On Tue, 4/1/11, Anton Korobeynikov <anton at korobeynikov.info> wrote:

From: Anton Korobeynikov <anton at korobeynikov.info>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "akramul azim" <bijoy123_8 at yahoo.com>
Cc: "Bill Wendling" <wendling at apple.com>, llvmdev at cs.uiuc.edu
Date: Tuesday, 4 January, 2011, 8:41 PM

> Can anyone please tell me the problem?
It seems you don't have the standard C library for ARM around.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110105/3752b799/attachment.html 

From ofv at wanadoo.es  Wed Jan  5 08:34:28 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Wed, 05 Jan 2011 15:34:28 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	(arrowdodger's message of "Wed, 5 Jan 2011 13:13:26 +0300")
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
Message-ID: <87zkrfzaff.fsf@telefonica.net>

arrowdodger <6yearold at gmail.com> writes:

>> Or to say it with other words: patches welcome.
>
> So, how should i proceed? Make CMake-generated config to be identical to
> autotools one?

That would be a good thing.

Please note that some checks are a bit tricky. A function that on
platform A is on header foo.h on another platform may be on
bar.h. Furthermore, cmake's platform testing support is not so mature as
autoconf's (at least on Unix).

> Or cleanup both headers from unused stuff by Eric's
> suggestion?

I'm not sure this is a good idea (not that it is bad either). Murphy's
Law says that a function that you remove today will be used tomorrow.

[snip]

From yueguoguo1024 at gmail.com  Wed Jan  5 10:05:56 2011
From: yueguoguo1024 at gmail.com (=?GB2312?B?1cXA1g==?=)
Date: Thu, 6 Jan 2011 00:05:56 +0800
Subject: [LLVMdev] UESTIONS about interpretation of LLVM IR
Message-ID: <AANLkTikbnwLQwYzVFmWudahgAs6UFnMNhW_mQBoRH=EQ@mail.gmail.com>

Hello, everybody!
I am new to LLVM and currently I am doing some research on how to execute
LLVM IR on M5 modular platform.
I have read the Language reference and bitcode format manual of LLVM, but I
don't quite know how it is encoded and executed.
Unlike normal assembly code, LLVM IR is more type-fixed and high-level
programed. Therefore, I don't quite understand:
1, How the instruction fields mapped into the virtual registers.
2, How does it complete the calling of functions and how they pass the
parameters.
3, And, whether it call libraries' functions is also not clear to me.
Problems are not limited to these and I beg for your help sincerely.
If someone knows, please contact with me.

Thanks very much!

-- 
*with best regards*
*Zhang  Le*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110106/727b48ee/attachment.html 

From anton at korobeynikov.info  Wed Jan  5 10:30:28 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 5 Jan 2011 19:30:28 +0300
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <871739.6013.qm@web121705.mail.ne1.yahoo.com>
References: <AANLkTim5OYEc=TRvH6yBT0xK0qrjX4JuUEvXeK8S_q2u@mail.gmail.com>
	<871739.6013.qm@web121705.mail.ne1.yahoo.com>
Message-ID: <AANLkTikaKdpZT2xT_f_O1hn3aSn2wOYqA=FLw_+bLbaH@mail.gmail.com>

> Can you please tell me what should I do at this point? How to get the standard C library for ARM around?
The best thing is to grab some description how to build "normal" gcc
for your target and make sure all the steps described there will be
ok.
After this you can substitute normal gcc with llvm-gcc and start the
same scenario from scratch.

I believe this is the best way how the newcomer can proceed with such
a complex procedure.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From echristo at apple.com  Wed Jan  5 11:22:05 2011
From: echristo at apple.com (Eric Christopher)
Date: Wed, 5 Jan 2011 09:22:05 -0800
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <87zkrfzaff.fsf@telefonica.net>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
Message-ID: <38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>


On Jan 5, 2011, at 6:34 AM, ?scar Fuentes wrote:

> arrowdodger <6yearold at gmail.com> writes:
> 
>>> Or to say it with other words: patches welcome.
>> 
>> So, how should i proceed? Make CMake-generated config to be identical to
>> autotools one?
> 
> That would be a good thing.
> 
> Please note that some checks are a bit tricky. A function that on
> platform A is on header foo.h on another platform may be on
> bar.h. Furthermore, cmake's platform testing support is not so mature as
> autoconf's (at least on Unix).
> 
>> Or cleanup both headers from unused stuff by Eric's
>> suggestion?
> 
> I'm not sure this is a good idea (not that it is bad either). Murphy's
> Law says that a function that you remove today will be used tomorrow.

I meant literally functions that aren't used in the codebase. No need to
look for them if we're not using them.

-eric

From oscarfv at telefonica.net  Wed Jan  5 11:58:59 2011
From: oscarfv at telefonica.net (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Wed, 05 Jan 2011 18:58:59 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com> (Eric
	Christopher's message of "Wed, 5 Jan 2011 09:22:05 -0800")
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
Message-ID: <87oc7vz0yk.fsf@telefonica.net>

Eric Christopher <echristo at apple.com> writes:

>>> Or cleanup both headers from unused stuff by Eric's
>>> suggestion?
>> 
>> I'm not sure this is a good idea (not that it is bad either). Murphy's
>> Law says that a function that you remove today will be used tomorrow.
>
> I meant literally functions that aren't used in the codebase. No need to
> look for them if we're not using them.

Sorry, bad wording. What I'm trying to say is that if you remove a
function check just because it is not used by the codebase today maybe
some programmer will need that function tomorrow. And adding an autoconf
check is far from trivial, at least for those not familiarized with the
autotools.

IMHO removing configure checks because they are not used by the codebase
right now is not an improvement similar to removing dead code from the
C++ sources.

From echristo at apple.com  Wed Jan  5 12:02:34 2011
From: echristo at apple.com (Eric Christopher)
Date: Wed, 5 Jan 2011 10:02:34 -0800
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <87oc7vz0yk.fsf@telefonica.net>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
Message-ID: <B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>


On Jan 5, 2011, at 9:58 AM, ?scar Fuentes wrote:

> Eric Christopher <echristo at apple.com> writes:
> 
>>>> Or cleanup both headers from unused stuff by Eric's
>>>> suggestion?
>>> 
>>> I'm not sure this is a good idea (not that it is bad either). Murphy's
>>> Law says that a function that you remove today will be used tomorrow.
>> 
>> I meant literally functions that aren't used in the codebase. No need to
>> look for them if we're not using them.
> 
> Sorry, bad wording. What I'm trying to say is that if you remove a
> function check just because it is not used by the codebase today maybe
> some programmer will need that function tomorrow. And adding an autoconf
> check is far from trivial, at least for those not familiarized with the
> autotools.
> 

Adding a check for most standard functions is amazingly trivial:

AC_CHECK_FUNCS([backtrace ceilf floorf roundf rintf nearbyintf getcwd ])
AC_CHECK_FUNCS([powf fmodf strtof round ])
AC_CHECK_FUNCS([getpagesize getrusage getrlimit setrlimit gettimeofday ])
AC_CHECK_FUNCS([isatty mkdtemp mkstemp ])
AC_CHECK_FUNCS([mktemp posix_spawn realpath sbrk setrlimit strdup ])
AC_CHECK_FUNCS([strerror strerror_r strerror_s setenv ])
AC_CHECK_FUNCS([strtoll strtoq sysconf malloc_zone_statistics ])
AC_CHECK_FUNCS([setjmp longjmp sigsetjmp siglongjmp])

contains most of them. If they're non-trivial (like the ones I needed to
add for OSX functionality) that's a different story.

> IMHO removing configure checks because they are not used by the codebase
> right now is not an improvement similar to removing dead code from the
> C++ sources.

I disagree.

-eric

From anton at korobeynikov.info  Wed Jan  5 12:31:38 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 5 Jan 2011 21:31:38 +0300
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
 and autofoo builds
In-Reply-To: <B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
Message-ID: <AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>

> contains most of them. If they're non-trivial (like the ones I needed to
> add for OSX functionality) that's a different story.
FWIW the difference is even more significant on, e.g. mingw32 because
process spawning is pretty much expensive and sometimes configure time
dominates the compile time :)


-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From echristo at apple.com  Wed Jan  5 12:43:57 2011
From: echristo at apple.com (Eric Christopher)
Date: Wed, 5 Jan 2011 10:43:57 -0800
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
Message-ID: <6FF98989-1269-4E8B-902C-037755C6A446@apple.com>


On Jan 5, 2011, at 10:31 AM, Anton Korobeynikov wrote:

>> contains most of them. If they're non-trivial (like the ones I needed to
>> add for OSX functionality) that's a different story.
> FWIW the difference is even more significant on, e.g. mingw32 because
> process spawning is pretty much expensive and sometimes configure time
> dominates the compile time :)

Totally. It was remembering cygwin compiles that came to mind :)

-eric

From ofv at wanadoo.es  Wed Jan  5 12:50:39 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Wed, 05 Jan 2011 19:50:39 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	(Anton Korobeynikov's message of "Wed, 5 Jan 2011 21:31:38 +0300")
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
Message-ID: <87zkrfxk00.fsf@wanadoo.es>

Anton Korobeynikov <anton at korobeynikov.info> writes:

>> contains most of them. If they're non-trivial (like the ones I needed to
>> add for OSX functionality) that's a different story.
> FWIW the difference is even more significant on, e.g. mingw32 because
> process spawning is pretty much expensive and sometimes configure time
> dominates the compile time :)

Yes, the time taken by configure tests (both by the `configure' script
and cmake) is annoyingly long.

Although I don't think it is the most pressing issue, if there is an
interest on it I'm not opposed to patches that remove unused platform
tests from the cmake build *and* from the autoconf build (as I don't
know about the autoconf build, someone familiar with it would need to
approve that part of the patches.)

From vanboxem.ruben at gmail.com  Wed Jan  5 12:53:07 2011
From: vanboxem.ruben at gmail.com (Ruben Van Boxem)
Date: Wed, 5 Jan 2011 19:53:07 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
 and autofoo builds
In-Reply-To: <AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
Message-ID: <AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>

Op 5 jan. 2011 19:33 schreef "Anton Korobeynikov" <anton at korobeynikov.info>
het volgende:
>
> > contains most of them. If they're non-trivial (like the ones I needed to
> > add for OSX functionality) that's a different story.
> FWIW the difference is even more significant on, e.g. mingw32 because
> process spawning is pretty much expensive and sometimes configure time
> dominates the compile time :)

And this is why I don't understand configure checks for windows... There's
only one/two header/library sets... The Windows SDK and MinGW. This info
should be built in IMHO...

Ruben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110105/a34f14ae/attachment.html 

From ofv at wanadoo.es  Wed Jan  5 13:04:41 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Wed, 05 Jan 2011 20:04:41 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	(Ruben Van Boxem's message of "Wed, 5 Jan 2011 19:53:07 +0100")
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
Message-ID: <87oc7vxjcm.fsf@wanadoo.es>

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes:

> And this is why I don't understand configure checks for windows... There's
> only one/two header/library sets... The Windows SDK and MinGW. This info
> should be built in IMHO...

Although the panorama is not so diverse as the Unix world, there is
quite a bit of variation on Windows too. Apart from the
cygwin/mingw/vc++ distinction, there are multiple versions of their
respective C libraries, intrinsics and language features supported by
the compilers, etc. Plus some people may want to use third party
libraries for certain things.

Note: the platform tests makes no difference among the official Windows
SDK libraries and MinGW's Winapi. Maybe you are thinking on the MS C
runtime (that evolves with every VC++ compiler release) and the MinGW C
runtime (which wraps some version of the MS C runtime and adds stuff of
its own.)

From vanboxem.ruben at gmail.com  Wed Jan  5 13:56:05 2011
From: vanboxem.ruben at gmail.com (Ruben Van Boxem)
Date: Wed, 5 Jan 2011 20:56:05 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
 and autofoo builds
In-Reply-To: <87oc7vxjcm.fsf@wanadoo.es>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	<87oc7vxjcm.fsf@wanadoo.es>
Message-ID: <AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>

2011/1/5 ?scar Fuentes <ofv at wanadoo.es>:
> Ruben Van Boxem <vanboxem.ruben at gmail.com> writes:
>
>> And this is why I don't understand configure checks for windows... There's
>> only one/two header/library sets... The Windows SDK and MinGW. This info
>> should be built in IMHO...
>
> Although the panorama is not so diverse as the Unix world, there is
> quite a bit of variation on Windows too. Apart from the
> cygwin/mingw/vc++ distinction, there are multiple versions of their
> respective C libraries, intrinsics and language features supported by
> the compilers, etc. Plus some people may want to use third party
> libraries for certain things.
>
> Note: the platform tests makes no difference among the official Windows
> SDK libraries and MinGW's Winapi. Maybe you are thinking on the MS C
> runtime (that evolves with every VC++ compiler release) and the MinGW C
> runtime (which wraps some version of the MS C runtime and adds stuff of
> its own.)
>

Yeah that's the two different ones I mean. Everything MS (intrinsics,
language features etc...) is purely version-bound, so I don't even get
why CMake insists on checking every known function prototype of for
example "recv" and for the presence of headers it (or the project
dev!) should know are not there.

As for 3rdparty libraries: provide an option like autotools (about the
only thing (sometimes) done right) "--with-3rdpartylibname=somePath".
Leave it to the user/builder to get their setup right and provide the
correct library (location)

Sorry for the somewhat off-topic ramble :s.

Ruben


From ofv at wanadoo.es  Wed Jan  5 15:02:25 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Wed, 05 Jan 2011 22:02:25 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>
	(Ruben Van Boxem's message of "Wed, 5 Jan 2011 20:56:05 +0100")
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	<87oc7vxjcm.fsf@wanadoo.es>
	<AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>
Message-ID: <87fwt7xdwe.fsf@wanadoo.es>

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes:

> Yeah that's the two different ones I mean. Everything MS (intrinsics,
> language features etc...) is purely version-bound, so I don't even get
> why CMake insists on checking every known function prototype of for
> example "recv" and for the presence of headers it (or the project
> dev!) should know are not there.

The fact that a given function is present on one version of VC++/MinGW
does not mean that it is present on another future or past version. The
same could be said for the Unix case. Hard-coding that information
defeats the purpose of platform checks.

We could hard-code some check results with 

if( NOT WIN32 )
  checks
elseif( MINGW )
  hard_coded_results_mingw
else
  hard_coded_results_vc
endif()

but that adds noise and increases fragility and maintenance effort. For
just saving two or three minutes while configuring, something that most
people don't do often (except if you are one of the build maintainers,
of course ;-)

> As for 3rdparty libraries: provide an option like autotools (about the
> only thing (sometimes) done right) "--with-3rdpartylibname=somePath".
> Leave it to the user/builder to get their setup right and provide the
> correct library (location)

This is not so easy. The user can replace anything you can imagine
of. From the compiler itself to core OS functionality. IIRC there are
cases of people using a third-party C standard library implementation.

[snip]

From vanboxem.ruben at gmail.com  Wed Jan  5 15:10:29 2011
From: vanboxem.ruben at gmail.com (Ruben Van Boxem)
Date: Wed, 5 Jan 2011 22:10:29 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
 and autofoo builds
In-Reply-To: <87fwt7xdwe.fsf@wanadoo.es>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	<87oc7vxjcm.fsf@wanadoo.es>
	<AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>
	<87fwt7xdwe.fsf@wanadoo.es>
Message-ID: <AANLkTinWcwivnSELm9aNEOsnRG-L+ARFBn=BBLWhGOuy@mail.gmail.com>

2011/1/5 ?scar Fuentes <ofv at wanadoo.es>:
> Ruben Van Boxem <vanboxem.ruben at gmail.com> writes:
>
>> Yeah that's the two different ones I mean. Everything MS (intrinsics,
>> language features etc...) is purely version-bound, so I don't even get
>> why CMake insists on checking every known function prototype of for
>> example "recv" and for the presence of headers it (or the project
>> dev!) should know are not there.
>
> The fact that a given function is present on one version of VC++/MinGW
> does not mean that it is present on another future or past version. The
> same could be said for the Unix case. Hard-coding that information
> defeats the purpose of platform checks.

Well, that's the strong point in the Windows API, backwards
compatibility is almost infinite! Unix, well, that seems to be a
completely different story :s...

>
> We could hard-code some check results with
>
> if( NOT WIN32 )
> ?checks
> elseif( MINGW )
> ?hard_coded_results_mingw
> else
> ?hard_coded_results_vc
> endif()
>
> but that adds noise and increases fragility and maintenance effort. For
> just saving two or three minutes while configuring, something that most
> people don't do often (except if you are one of the build maintainers,
> of course ;-)
>
>> As for 3rdparty libraries: provide an option like autotools (about the
>> only thing (sometimes) done right) "--with-3rdpartylibname=somePath".
>> Leave it to the user/builder to get their setup right and provide the
>> correct library (location)
>
> This is not so easy. The user can replace anything you can imagine
> of. From the compiler itself to core OS functionality. IIRC there are
> cases of people using a third-party C standard library implementation.
>
> [snip]
>

I may be naive, but shouldn't a *standard* C library implementation
use *standard* headers/function prototypes? I understand OSes like BSD
and Solaris really suck on this point (standards compliance), but I
would think linux, Mac OS and Windows at least adhere to a large
denominator which would make these checks kind of superfluous. Heck,
all of Qt builds without any of these, and it uses only a platform
specific header with the necessary defines. I would think a library
like Qt touches most dark corners of all the platforms it supports?
(not trying to be a brute here, I'm just frustrated with
Windows+autotools... and all the projects using that).

Ruben


From ofv at wanadoo.es  Wed Jan  5 15:17:59 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Wed, 05 Jan 2011 22:17:59 +0100
Subject: [LLVMdev] include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <AANLkTinWcwivnSELm9aNEOsnRG-L+ARFBn=BBLWhGOuy@mail.gmail.com>
	(Ruben Van Boxem's message of "Wed, 5 Jan 2011 22:10:29 +0100")
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	<87oc7vxjcm.fsf@wanadoo.es>
	<AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>
	<87fwt7xdwe.fsf@wanadoo.es>
	<AANLkTinWcwivnSELm9aNEOsnRG-L+ARFBn=BBLWhGOuy@mail.gmail.com>
Message-ID: <87bp3vxd6g.fsf@wanadoo.es>

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes:

> Well, that's the strong point in the Windows API, backwards
> compatibility is almost infinite! Unix, well, that seems to be a
> completely different story :s...

Don't confuse the Windows API with the C standard library. As mentioned
before, there are no tests for Windows API stuff on the LLVM cmake
build.

> I may be naive, but shouldn't a *standard* C library implementation
> use *standard* headers/function prototypes?

Yes, they should :-)

> I understand OSes like BSD
> and Solaris really suck on this point (standards compliance), but I
> would think linux, Mac OS and Windows at least adhere to a large
> denominator which would make these checks kind of superfluous.

Precisely, VC++ "standard" C library is full of surprises. They add some
with every release.

[snip]

From samuraileumas at yahoo.com  Wed Jan  5 15:40:11 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Wed, 5 Jan 2011 13:40:11 -0800 (PST)
Subject: [LLVMdev] Fw: include/Config/config.h discrepancies between CMake
	and autofoo builds
In-Reply-To: <AANLkTinWcwivnSELm9aNEOsnRG-L+ARFBn=BBLWhGOuy@mail.gmail.com>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	<87oc7vxjcm.fsf@wanadoo.es>
	<AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>
	<87fwt7xdwe.fsf@wanadoo.es>
	<AANLkTinWcwivnSELm9aNEOsnRG-L+ARFBn=BBLWhGOuy@mail.gmail.com>
Message-ID: <599090.13147.qm@web62008.mail.re1.yahoo.com>

Whoops, phone rang and I forgot to cc to the list before I typed the message.


----- Forwarded Message ----
> From: Samuel Crow <samuraileumas at yahoo.com>
> To: Ruben Van Boxem <vanboxem.ruben at gmail.com>
> Sent: Wed, January 5, 2011 3:38:21 PM
> Subject: Re: [LLVMdev] include/Config/config.h discrepancies between CMake and 
>autofoo builds
> 
> 
> 
> 
> 
> ----- Original Message ----
> > From: Ruben Van Boxem <vanboxem.ruben at gmail.com>
> >  To: ?scar Fuentes <ofv at wanadoo.es>
> > Cc: llvmdev at cs.uiuc.edu
> > Sent: Wed,  January 5, 2011 3:10:29 PM
> > Subject: Re: [LLVMdev]  include/Config/config.h discrepancies between CMake 
>and 
>
> >autofoo  builds
> > 
> > 2011/1/5 ?scar Fuentes <ofv at wanadoo.es>:
> > > Ruben Van  Boxem  <vanboxem.ruben at gmail.com>   writes:
> > >
> > 
> > I may be naive, but  shouldn't a  *standard* C library implementation
> > use *standard*   headers/function prototypes? I understand OSes like BSD
> > and Solaris  really  suck on this point (standards compliance), but I
> > would  think linux, Mac OS  and Windows at least adhere to a large
> >  denominator which would make these  checks kind of superfluous.  Heck,
> > all of Qt builds without any of these, and  it uses only a  platform
> > specific header with the necessary defines. I would  think  a library
> > like Qt touches most dark corners of all the platforms  it  supports?
> > (not trying to be a brute here, I'm just  frustrated  with
> > Windows+autotools... and all the projects  using  that).
> > 
> 
> 
> Hi Ruben,
> 
> CMake is inspired by  QMake which is what Qt builds all of its cross-platform 
> tools with. You  might try to find a better example.
> 
> --Sam Crow
> 
> 
> 
> 


      


From mle+cl at mega-nerd.com  Wed Jan  5 15:47:50 2011
From: mle+cl at mega-nerd.com (Erik de Castro Lopo)
Date: Thu, 6 Jan 2011 08:47:50 +1100
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <1294235328.1880.16.camel@LLVMbuilder.research.nokia.com>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<1294235328.1880.16.camel@LLVMbuilder.research.nokia.com>
Message-ID: <20110106084750.acf6ca54.mle+cl@mega-nerd.com>

Kalle Raiskila wrote:

> And I probably should file a bug. Is ppc32 still maintained?

I have no concrete knowledge of this, but llvm compiles
and passes all tests on ppc32, so it seems to be maintained.
About once a week I grab the latest SVN head and check this.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From wendling at apple.com  Wed Jan  5 16:04:37 2011
From: wendling at apple.com (Bill Wendling)
Date: Wed, 5 Jan 2011 14:04:37 -0800
Subject: [LLVMdev] Passing options to opt
In-Reply-To: <AANLkTikWWPE0fgJYN6MdfVmQsv9NR55AVbLKbje2Jy3q@mail.gmail.com>
References: <AANLkTikWWPE0fgJYN6MdfVmQsv9NR55AVbLKbje2Jy3q@mail.gmail.com>
Message-ID: <EC303618-D1C3-4A84-9086-BE271600801C@apple.com>

On Jan 4, 2011, at 10:16 PM, Neal N. Wang wrote:

> Hi Folk, 
> 
> This question might be better suitable for clang mailing list.  Please forgive me for asking it here first.  In the llvm-gcc front-end, there is an option -mllvm that passes its following string as the option to opt, I'm wondering if clang also has a similar option. If yes, what is it?
> 
The -mllvm will pass the option with clang as well.

-bw




From dalej at apple.com  Wed Jan  5 16:22:06 2011
From: dalej at apple.com (dalej)
Date: Wed, 5 Jan 2011 14:22:06 -0800
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20110106084750.acf6ca54.mle+cl@mega-nerd.com>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<1294235328.1880.16.camel@LLVMbuilder.research.nokia.com>
	<20110106084750.acf6ca54.mle+cl@mega-nerd.com>
Message-ID: <95189AD2-6430-4450-B1EB-E90B1F640386@apple.com>


On Jan 5, 2011, at 1:47 PM, Erik de Castro Lopo wrote:

> Kalle Raiskila wrote:
> 
>> And I probably should file a bug. Is ppc32 still maintained?
> 
> I have no concrete knowledge of this, but llvm compiles
> and passes all tests on ppc32, so it seems to be maintained.
> About once a week I grab the latest SVN head and check this.

It is run by one of the automatic testers, and introduced bugs that break the tester get fixed.    Nobody is doing new work on it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110105/d0cfe222/attachment.html 

From rvanka at ncsu.edu  Wed Jan  5 16:28:03 2011
From: rvanka at ncsu.edu (Rajeshwar Vanka)
Date: Wed, 05 Jan 2011 17:28:03 -0500
Subject: [LLVMdev] Printing error with Value objects
Message-ID: <4D24F073.7050009@ncsu.edu>

Hi.
   The platform is an x86 32-bit machine running LLVM 2.4.
  
   I am trying to analyze Alias Analysis queries, and towards this end, 
I am trying to print out the "Value"s that form the queries. While 
trying to print these queries, llvm hits a segmentation fault. The fault 
is due to a Value which does not have its module set properly. I am 
using the operator<< to call the print function, and since the module is 
not defined for this Value, there is no Symbol Table. I checked and 
verified that V1 is an instruction. I am collecting the queries from 
GVN. I perform this dump after GVN has completed its transformations. Is 
it possible that the Value has been deleted from the program by GVN? Is 
this expected behaviour?

   This is the output when I type "print *V1" in gdb:
   {_vptr.Value = 0x91fa950, SubclassID = 92 '\\', HasValueHandle = 1 
'\001', HasMetadata = 0 '\000', SubclassOptionalData = 31 '\037',
  SubclassData = 43368, VTy = {Ty = 0x921f6fc}, UseList = 0x8d5a550, 
Name = 0x8e06088}

  This is the output when I type "print *V1->getType()" in gdb:
  {<llvm::AbstractTypeUser> = {_vptr.AbstractTypeUser = 0x92184c0}, ID = 
72, Abstract = true, SubclassData = 299242, RefCount = 153191633,
  Context = @0x89f3aac, ForwardType = 0x0, AbstractTypeUsers = 
{<std::_Vector_base<llvm::AbstractTypeUser*, 
std::allocator<llvm::AbstractTypeUser*> >> = {
      _M_impl = {<std::allocator<llvm::AbstractTypeUser*>> = 
{<__gnu_cxx::new_allocator<llvm::AbstractTypeUser*>> = {<No data 
fields>}, <No data fields>},
        _M_start = 0x921f726, _M_finish = 0x921a090, _M_end_of_storage = 
0x921e898}}, <No data fields>}, NumContainedTys = 153198753,
  ContainedTys = 0x89f3aac}

   Thanks for the help.

Regards
Rajesh

From samuraileumas at yahoo.com  Wed Jan  5 16:43:48 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Wed, 5 Jan 2011 14:43:48 -0800 (PST)
Subject: [LLVMdev] Build problems and workarounds with CMake and XCode
Message-ID: <941908.30472.qm@web62002.mail.re1.yahoo.com>

Hello everyone,

I finally gave up on trying to build under Eclipse on my Mac because I had a 
non-functioning installation on there that kept intercepting the command line 
entries on the path.  Uninstalling the old MacPorts install of LLVM 2.6 helped 
but not completely.

I tried making a separate build of LLVM SVN in XCode using build files created 
with CMake.  Surprisingly, it worked better than Eclipse!  The Build_All target 
completed its build.  The install target was another story though.  First of 
all, the commands to install with the terminal command-line needed to be 
prefaced with sudo to work.  Secondly, those commands, when executed from XCode, 
have no open console to prompt for a password.

My workaround for that was to write a small utility in Qt to prompt for a 
password and return it in stdout.  I then set the path of that utility to the 
SUDO_ASKPASS environment variable so I could set the scripts to run sudo -A 
command instead of sudo command.  This unearthed a second problem.  In my debug 
build, the script looked in the release directory for LLVMSupport.a and failed 
as a result of it.

At this point I'm building a release build so I can install the debug build. 
 If ?scar or somebody more familiar than I at CMake would look into the issue of 
the release install in the debug build, I'd appreciate it.  Secondly, if anyone 
would be interested in my password prompter software, I'd be interested in 
releasing it as open-source.

Thanks for your time and efforts,

--Samuel Crow


      


From ofv at wanadoo.es  Wed Jan  5 17:00:00 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Thu, 06 Jan 2011 00:00:00 +0100
Subject: [LLVMdev] Build problems and workarounds with CMake and XCode
In-Reply-To: <941908.30472.qm@web62002.mail.re1.yahoo.com> (Samuel Crow's
	message of "Wed, 5 Jan 2011 14:43:48 -0800 (PST)")
References: <941908.30472.qm@web62002.mail.re1.yahoo.com>
Message-ID: <87wrmjvtvz.fsf@wanadoo.es>

Samuel Crow <samuraileumas at yahoo.com> writes:

[snip]

> I tried making a separate build of LLVM SVN in XCode using build files created 
> with CMake.  Surprisingly, it worked better than Eclipse!  The Build_All target 
> completed its build.  The install target was another story though.  First of 
> all, the commands to install with the terminal command-line needed to be 
> prefaced with sudo to work.

Have you permissions for those directories?

>  Secondly, those commands, when executed from XCode, 
> have no open console to prompt for a password.

That lies outside cmake and/or XCode capabilities, I guess.

> My workaround for that was to write a small utility in Qt to prompt for a 
> password and return it in stdout.  I then set the path of that utility to the 
> SUDO_ASKPASS environment variable so I could set the scripts to run sudo -A 
> command instead of sudo command.  This unearthed a second problem.  In my debug 
> build, the script looked in the release directory for LLVMSupport.a and failed 
> as a result of it.
>
> At this point I'm building a release build so I can install the debug build. 
>  If ?scar or somebody more familiar than I at CMake would look into the issue of 
> the release install in the debug build, I'd appreciate it.

I'm not sure what the problem is. Never used XCode nor I have access to
it. What are those scripts? The install scripts generated by CMake for
XCode?


From anton at korobeynikov.info  Wed Jan  5 17:10:43 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Thu, 6 Jan 2011 02:10:43 +0300
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <95189AD2-6430-4450-B1EB-E90B1F640386@apple.com>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<1294235328.1880.16.camel@LLVMbuilder.research.nokia.com>
	<20110106084750.acf6ca54.mle+cl@mega-nerd.com>
	<95189AD2-6430-4450-B1EB-E90B1F640386@apple.com>
Message-ID: <AANLkTingKEFD8hQq6AmHecsYdGgmEed+6hmN6Pe=9K2F@mail.gmail.com>

> I have no concrete knowledge of this, but llvm compiles
> and passes all tests on ppc32, so it seems to be maintained.
> About once a week I grab the latest SVN head and check this.
>
> It is run by one of the automatic testers, and introduced bugs that break
> the tester get fixed. ? ?Nobody is doing new work on it.
Just to clarify: ppc32-darwin, not ppc32-linux.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From czhao at eecg.toronto.edu  Wed Jan  5 20:03:45 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Wed, 05 Jan 2011 21:03:45 -0500
Subject: [LLVMdev] What are all the LLVM IRs that will write into memory?
Message-ID: <4D252301.9050702@eecg.toronto.edu>

LLVMers,

I need to intercept all LLVM IR instructions that will write into memory 
and start to do analysis on these instructions.

In addition to StoreInst, what are all other IRs that will write into 
memory?

E.g.
char * ptr = malloc(...);
///...
//with use(s) of ptr later

The LLVM IR for the above code would be:

   %0 = tail call noalias i8* @malloc(i32 137) nounwind

     ///...
     // use(s) of %0

LLVM's Language Reference has the instruction format for CallInst:

  <result>  = [tail] call [cconv  <http://llvm.org/docs/LangRef.html#callingconv>] [ret attrs  <http://llvm.org/docs/LangRef.html#paramattrs>]<ty>  [<fnty>*]<fnptrval>(<function args>) [fn attrs  <http://llvm.org/docs/LangRef.html#fnattrs>]


Does that mean any LLVM IR that has a valid result field will be able to 
store the result into memory?

How about those temps allocated into registers via register allocation?
Is there a way to tell such temps at compile time before RA?


Thank you very much

Chuck



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110105/b08d1d27/attachment.html 

From reid.kleckner at gmail.com  Wed Jan  5 20:16:04 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Wed, 5 Jan 2011 19:16:04 -0700
Subject: [LLVMdev] What are all the LLVM IRs that will write into memory?
In-Reply-To: <4D252301.9050702@eecg.toronto.edu>
References: <4D252301.9050702@eecg.toronto.edu>
Message-ID: <AANLkTint_Z6R5pvVhB1YcyT8jaLebnLO6SNakCifCxJN@mail.gmail.com>

On Wed, Jan 5, 2011 at 7:03 PM, Chuck Zhao <czhao at eecg.toronto.edu> wrote:
> LLVMers,
>
> I need to intercept all LLVM IR instructions that will write into memory and
> start to do analysis on these instructions.
...
> Does that mean any LLVM IR that has a valid result field will be able to
> store the result into memory?

Yes, if the value ends up getting spilled to the stack.

> How about those temps allocated into registers via register allocation?
> Is there a way to tell such temps at compile time before RA?

No, I think you need to perform register allocation in order to know
about writes to the stack.

Are you doing a static analysis on the instructions or are you trying
to instrument all memory stores?  If so, Pin and DynamoRIO seem like
better choices, unless you want to do a static instrumentation, in
which case I don't know what the right tool would be.

Reid

From samuraileumas at yahoo.com  Wed Jan  5 21:10:51 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Wed, 5 Jan 2011 19:10:51 -0800 (PST)
Subject: [LLVMdev] Build problems and workarounds with CMake and XCode
In-Reply-To: <87wrmjvtvz.fsf@wanadoo.es>
References: <941908.30472.qm@web62002.mail.re1.yahoo.com>
	<87wrmjvtvz.fsf@wanadoo.es>
Message-ID: <861989.96109.qm@web62008.mail.re1.yahoo.com>





----- Original Message ----
> From: ?scar Fuentes <ofv at wanadoo.es>
> To: Samuel Crow <samuraileumas at yahoo.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Wed, January 5, 2011 5:00:00 PM
> Subject: Re: Build problems and workarounds with CMake and XCode
> 
> Samuel Crow <samuraileumas at yahoo.com>  writes:
> 
> [snip]
> 
> > I tried making a separate build of LLVM SVN in  XCode using build files 
>created 
>
> > with CMake.  Surprisingly, it  worked better than Eclipse!  The Build_All 
>target 
>
> > completed its  build.  The install target was another story though.  First of 
>
> > all, the commands to install with the terminal command-line needed to  be 
> > prefaced with sudo to work.
> 
> Have you permissions for those  directories?
> 

I'm running in user mode with root equivalence added temporarily to my account. 
 Macs always require you to sudo to access the system directories even when 
you're logged in as an administrator.

It's possible that this may be a CMake bug/oversight.

> >  Secondly, those commands, when executed from  XCode, 
> > have no open console to prompt for a password.
> 
> That lies  outside cmake and/or XCode capabilities, I guess.
> 

It's an Macintosh-ism.  Most files run from icons do not open a text console. 
 My past experience with some Linux GUI toolkits are similar.

> > My workaround for  that was to write a small utility in Qt to prompt for a 
> > password and  return it in stdout.  I then set the path of that utility to 
>the 
>
> >  SUDO_ASKPASS environment variable so I could set the scripts to run sudo -A 

> > command instead of sudo command.  This unearthed a second  problem.  In my 
>debug 
>
> > build, the script looked in the release  directory for LLVMSupport.a and 
>failed 
>
> > as a result of  it.
> >
> > At this point I'm building a release build so I can install  the debug build. 
>
> >  If ?scar or somebody more familiar than I at  CMake would look into the 
>issue of 
>
> > the release install in the debug  build, I'd appreciate it.
> 
> I'm not sure what the problem is. Never used  XCode nor I have access to
> it. What are those scripts? The install scripts  generated by CMake for
> XCode?
> 

The CMake script generated the XCode project file so I'm assuming it's a problem 
either with CMake or the CMake scripts.  XCode targets are similar to make 
targets except that parallel processing is generally implied without any added 
flags (like make -j).  If this turns out to be a deficiency in CMake itself then 
most of this discussion can probably be moved to the CMake mailing list.

My main concern with the CMake scripts is that they required a release-build 
file while making a debug-build install.  This ought not to be.

The rest of my workarounds can be easily fixed by CMake or XCode including a 
graphical password requester for the sudo -A flag to use.  If it's CMake that 
needs it, I can provide source to mine since I used the same GUI toolkit as 
CMake uses.  Really it's just a class wrapper for a ready-made requester that 
comes built in to Qt anyway.

I hope this clears up what I was trying to say,

--Sam


      


From bijoy123_8 at yahoo.com  Wed Jan  5 22:09:12 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Wed, 5 Jan 2011 20:09:12 -0800 (PST)
Subject: [LLVMdev] LLVM for ARM target
In-Reply-To: <AANLkTikaKdpZT2xT_f_O1hn3aSn2wOYqA=FLw_+bLbaH@mail.gmail.com>
Message-ID: <476157.41728.qm@web121703.mail.ne1.yahoo.com>

Thanks for your suggestions. I am trying to install cross gcc in my another PC?then. Btw, I tried the automated scripts (create-snapshots.sh and build-install-linux.sh) that?are in the LLVM repository for building crosstoll for ARM (http://llvm.org/svn/llvm-project/llvm/trunk/utils/crosstool/) but get the following error for building llvm-gcc (llvm built successfully):
?
'arm1026ej-s' is not a recognized processor for this target (ignoring processor)
'arm1026ej-s' is not a recognized processor for this target (ignoring processor)
/tmp/llvm-project.YZQXqN/src/llvm-gcc-4.2/gcc/crtstuff.c:1: internal compiler er
ror: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs/> for instructions.
make[2]: *** [crtbegin.o] Error 1
make[2]: Leaving directory `/tmp/llvm-project.YZQXqN/obj/llvm-gcc-4.2/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/tmp/llvm-project.YZQXqN/obj/llvm-gcc-4.2'
make: *** [all] Error 2
~

I am using the latest version of LLVM and LLVM-GCC from SVN (version number: 122872). And I am using arm-2009q1-176-arm-none-linux-gnueabi-i686-mingw32.tar.bz2. I am using CygWin. Can anyone please tell me what is the reason of the problem? 
?
Akramul
--- On Wed, 5/1/11, Anton Korobeynikov <anton at korobeynikov.info> wrote:


From: Anton Korobeynikov <anton at korobeynikov.info>
Subject: Re: [LLVMdev] LLVM for ARM target
To: "akramul azim" <bijoy123_8 at yahoo.com>
Cc: "Bill Wendling" <wendling at apple.com>, llvmdev at cs.uiuc.edu
Date: Wednesday, 5 January, 2011, 4:30 PM


> Can you please tell me what should I do at this point? How to get the standard C library for ARM around?
The best thing is to grab some description how to build "normal" gcc
for your target and make sure all the steps described there will be
ok.
After this you can substitute normal gcc with llvm-gcc and start the
same scenario from scratch.

I believe this is the best way how the newcomer can proceed with such
a complex procedure.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110105/81d834c8/attachment.html 

From chenwj at iis.sinica.edu.tw  Wed Jan  5 22:42:48 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Thu, 6 Jan 2011 12:42:48 +0800
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20110105204643.f7fc5245.mle+cl@mega-nerd.com>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<20110105193621.b1e69874.mle+cl@mega-nerd.com>
	<20110105085558.GA84982@cs.nctu.edu.tw>
	<20110105204643.f7fc5245.mle+cl@mega-nerd.com>
Message-ID: <20110106044248.GB18549@cs.nctu.edu.tw>

Hi, Erik

  If I do NOT add "--disable-multilib" option, then I will get the
following error,

----------------------------------------------------------------------
make[4]: Entering directory `/tmp/chenwj/build/gcc'
/tmp/chenwj/build/./gcc/xgcc -B/tmp/chenwj/build/./gcc/
-B/tmp/chenwj/install/powerpc64-unknown-linux-gnu/bin/
-B/tmp/chenwj/install/powerpc64-unknown-linux-gnu/lib/ -isystem
/tmp/chenwj/install/powerpc64-unknown-linux-gnu/include -isystem
/tmp/chenwj/install/powerpc64-unknown-linux-gnu/sys-include  -O2 -O2 -g
-O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I.
-I32 -I../../llvm-gcc-4.2-2.8.source/gcc
-I../../llvm-gcc-4.2-2.8.source/gcc/32
-I../../llvm-gcc-4.2-2.8.source/gcc/../include
-I../../llvm-gcc-4.2-2.8.source/gcc/../libcpp/include
-I../../llvm-gcc-4.2-2.8.source/gcc/../libdecnumber -I../libdecnumber
-I/tmp/chenwj/install/include -m32 -fPIC -mstrict-align -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder  -msdata=none \
          -c ../../llvm-gcc-4.2-2.8.source/gcc/crtstuff.c -DCRT_BEGIN \
          -o 32/crtbegin.o
../../llvm-gcc-4.2-2.8.source/gcc/crtstuff.c:1: error: -m64 requires a
PowerPC64 cpu
make[4]: *** [32/crtbegin.o] Error 1
make[4]: Leaving directory `/tmp/chenwj/build/gcc'
make[3]: *** [extra32] Error 2
make[3]: Leaving directory `/tmp/chenwj/build/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory `/tmp/chenwj/build/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/tmp/chenwj/build'
make: *** [all] Error 2
----------------------------------------------------------------------

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From chenwj at iis.sinica.edu.tw  Thu Jan  6 00:05:06 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Thu, 6 Jan 2011 14:05:06 +0800
Subject: [LLVMdev]  Building dragonegg.so failed
Message-ID: <20110106060506.GA19464@cs.nctu.edu.tw>

Hi, all

  I am trying to build gcc 4.5 with dragonegg plugin. After building
patched gcc 4.5, I try to build dragonegg.so but failed.

  Here is the error messgae,

-----------------------------------------------------------------------
$ GCC=/tmp/chenwj/install/bin/gcc make
Compiling utils/target.cpp
/tmp/chenwj/dragonegg-2.8/utils/target.cpp: In function 'int main(int,
char**)':
/tmp/chenwj/dragonegg-2.8/utils/target.cpp:39: error: 'normalize' is not
a member of 'llvm::Triple'
make: *** [target.o] Error 1
-----------------------------------------------------------------------

  How can I fix it? Thanks!

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From chenwj at iis.sinica.edu.tw  Thu Jan  6 00:07:59 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Thu, 6 Jan 2011 14:07:59 +0800
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
Message-ID: <20110106060759.GA21187@cs.nctu.edu.tw>

Hi, Anton

  The "--disable-bootstrap" give me no luck. Why you think that
"--disable-bootstrap" might help?

  Here is my configuration options,
-----------------------------------------------------------------------------
../llvm-gcc-4.2-2.8.source/configure --prefix=/tmp/chenwj/install
--disable-bootstrap --disable-multilib --program-prefix=llvm-
--enable-llvm=/enwj/install --enable-languages=c,c++
-----------------------------------------------------------------------------

  And here is the error messge,
-----------------------------------------------------------------------------
/tmp/chenwj/build/./gcc/xgcc -B/tmp/chenwj/build/./gcc/
-B/tmp/chenwj/install/powerpc64-unknown-linux-gnu/bin/
-B/tmp/chenwj/install/powerpc64-unknown-linux-gnu/lib/ -isystem
/tmp/chenwj/install/powerpc64-unknown-linux-gnu/include -isystem
/tmp/chenwj/install/powerpc64-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../../../llvm-gcc-4.2-2.8.source/libmudflap -I.
-Wall -ffunction-sections -fdata-sections -O2 -g -O2 -MT mf-hooks2.lo
-MD -MP -MF .deps/mf-hooks2.Tpo -c
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c  -fPIC -DPIC -o
.libs/mf-hooks2.o
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c: In function
'__mfwrap_recvfrom':
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c:1342: error:
incompatible type for argument 5 of 'recvfrom'
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c: In function
'__mfwrap_sendto':
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c:1368: error:
incompatible type for argument 5 of 'sendto'
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c: In function
'__mfwrap_accept':
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c:1405: error:
incompatible type for argument 2 of 'accept'
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c: In function
'__mfwrap_bind':
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c:1413: error:
incompatible type for argument 2 of 'bind'
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c: In function
'__mfwrap_connect':
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c:1423: error:
incompatible type for argument 2 of 'connect'
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c: In function
'__mfwrap_wait':
../../../llvm-gcc-4.2-2.8.source/libmudflap/mf-hooks2.c:1537: error:
incompatible type for argument 1 of 'wait'
make[4]: *** [mf-hooks2.lo] Error 1
make[4]: Leaving directory
`/tmp/chenwj/build/powerpc64-unknown-linux-gnu/libmudflap'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/tmp/chenwj/build/powerpc64-unknown-linux-gnu/libmudflap'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/tmp/chenwj/build/powerpc64-unknown-linux-gnu/libmudflap'
-----------------------------------------------------------------------------

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From jacob.zimmermann at oracle.com  Thu Jan  6 01:27:31 2011
From: jacob.zimmermann at oracle.com (Jacob Zimmermann)
Date: Thu, 06 Jan 2011 17:27:31 +1000
Subject: [LLVMdev] Null address pointer in llvm.dbg.declare
Message-ID: <1294298851.2728.11.camel@easteregg>

Hi,

I'm encountering a problem with llvm.dbg.declare. My code looks
basically like this:

if(DbgDeclareInst *dbg = dyn_cast<DbgDeclareInst>(&inst)) {
	const Value* addr = dbg->getAddress();
       	const MDNode* mvar = dbg->getVariable();
	...
}

While the MDNode (mvar) contains the correct information (name of the
variable, etc...), getAddress always returns NULL. Am I missing
something, or is there some other way to access the variable being
declared?

NB: this happens when processing the following bitcode:

define i32 @fun(i32 %a, float %b) nounwind {
entry:
  %a_addr = alloca i32, align 4
  %b_addr = alloca float, align 4
  %retval = alloca i32
  %0 = alloca i32
  %"alloca point" = bitcast i32 0 to i32
  call void @llvm.dbg.declare(metadata !{i32* %a_addr}, metadata !8), !
dbg !9
  ...
!8 = metadata !{i32 524545, metadata !4, metadata !"a", metadata !1, i32
3, metadata !3} ; [ DW_TAG_arg_variable ]
  ....


Best regards,
Jacob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110106/868d8a4a/attachment.bin 

From etherzhhb at gmail.com  Thu Jan  6 02:38:39 2011
From: etherzhhb at gmail.com (ether zhhb)
Date: Thu, 6 Jan 2011 16:38:39 +0800
Subject: [LLVMdev] Proposal: Generic auto-vectorization and parallelization
 approach for LLVM and Polly
Message-ID: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>

Hi,

I just have a detail look at the code of Polly[1], it seems that Polly
start to support some basic auto-parallelization stuffs. I have some
idea to improve the current auto-vectorization and parallelization
approach in Polly.

The main idea is, we separate the transform passes and codegen passes
for auto-parallelization and vectorization (Graphite[2] for gcc seems
to taking similar approach for auto-vectorization).

That means Polly (Or other similar framework) should perform necessary
code transform, then just generates the sequential code, and provides
necessary parallelism information (These information could be encoded
as metadata just like TBAA), then the later passes can generate the
parallel code with those parallelism information.

The main benefit of separating transform passes and codegen passes are:
1. Decouple the the autopar framework from various parallel runtime
environment, so we can keep both autopar framework and code generation
pass for specific parallel runtime environment simple. And we can
support more parallel runtime environments easily.

2. Allow the some generic parallelism information live out specific
autopar framework, so these information can benefit more passes in
llvm. For example, the X86 and PTX backend could use these information
to perform target specific auto-vectorization.

Implementation consideration:

We may define some kind of generic "parallelism analysis" or the
generic version of "LoopDependenceAnalysis" interface just like
AliasAnalysis, or we can also encode those parallelism information as
metadata. And combining the both should be OK, too.

Any comments are appreciated.

best regards
ether


[1] http://wiki.llvm.org/Polly
[2] http://gcc.gnu.org/wiki/Graphite/Parallelization

From anton at korobeynikov.info  Thu Jan  6 03:59:13 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Thu, 6 Jan 2011 12:59:13 +0300
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20110106044736.GA19379@cs.nctu.edu.tw>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<AANLkTik7B486GR5fSQj5shyBN_-2Hds6aBho943u2FF=@mail.gmail.com>
	<20110106044736.GA19379@cs.nctu.edu.tw>
Message-ID: <AANLkTinhc-+bJMfAsnA0GK6vCq+wVtwSfgQ8HMCwqYYR@mail.gmail.com>

Hello

> ?The "--disable-bootstrap" give me no luck. Why you think that
> "--disable-bootstrap" might help?
Due to reasons I outlined in my prev. e-mail. Now you can notice that
the build proceed much further. Try to add --disable-libmudflap as well.


-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From christophe at taodyne.com  Thu Jan  6 04:43:44 2011
From: christophe at taodyne.com (Christophe de Dinechin)
Date: Thu, 6 Jan 2011 11:43:44 +0100
Subject: [LLVMdev] Marking a function prototype as being "persistent"
Message-ID: <C103AECF-D0ED-4026-954E-40A5A6F4D05F@taodyne.com>

Hello and happy new year,


I'm using LLVM to JIT-compile the XL programming language. I've recently added a whole-program optimization phase that gives excellent results, but I noticed that the StripDeadPrototypesPass was removing all references to my runtime support functions. 

Apparently, this depends on the oddly-named UnitAtATime parameter. Set it to false. Try again. Suggestion: what about a comment explaining what "UnitAtATime" means :-)

Even then, my runtime function prorotypes are still being stripped away by the GlobalDCE added by createStandardLTOPasses.

So my question is: what is the correct, officially recommended way to reference runtime functions so that global DCE won't get rid of them? Or am I supposed to re-create the corresponding Function instances for every translation?


Thank you in advance for enlightening me
Christophe



From Tim.Northover at arm.com  Thu Jan  6 05:55:55 2011
From: Tim.Northover at arm.com (Tim Northover)
Date: Thu, 6 Jan 2011 11:55:55 +0000
Subject: [LLVMdev] shufflevector on ARM
Message-ID: <4D25ADCB.9060102@arm.com>

Hi,

I've been taking a look at http://llvm.org/bugs/show_bug.cgi?id=8411,
which is essentially improving how shufflevector instructions are
handled for ARM.

It looks like the main complexity comes from the fact that the DAG which
emerges from SelectionDAGBuilder::visitShuffleVector is often rather
low-level. A case could probably be made for keeping more information
around in the DAG, but that would require cooperation among all the
backends.

For now, both EXTRACT_SUBVECTORs and BUILD_VECTORs seem to be handled on
ARM mainly by resorting to the stack, which often leads to rather bad
code. EXTRACT_SUBVECTOR in particular should just involve ignoring one
of the registers.

I've put together a couple of patches to improve matters:

http://www.maths.ed.ac.uk/~s0677366/build_vector.patch
http://www.maths.ed.ac.uk/~s0677366/extract_subvector.patch

(both were originally created a couple of weeks ago so the offsets have
changed slightly, they're still valid on today's trunk).

extract_subvector.patch adds "Pat"s to the relevant .td file so that
EXTRACT_SUBVECTOR works naturally. This changed the code generated in a
couple of tests and exposed slight bug in visitShuffleVector itself, so
they needed modifying.

build_vector.patch is a more complex C++ modification, which attempts to
reconstruct shuffles from the BUILD_VECTOR nodes where possible.

Its primary effect is on <8 x *> -> <4 x *> shuffles, where on average
it saves 4.6 instructions, with a degradation (of 1 instruction) in only
5/83827 shuffles. Runtime benchmarks were more difficult, however a
random sample suggests it improves about 75% of shuffles. I suspect
"natural" shuffles will fare better.

On <16 x *> -> <8 x *> shuffles, it rarely performs any optimization.
Probably only 0.03 instructions shorter on average. The problem is that
not many random shuffles actually have known good encodings, so the
existing SHUFFLE_VECTOR handling refuses to deal with them usually.
Again I'd expect natural shuffles to do better.

The code is disabled on shorter vectors because my tests suggested the
transformations weren't improving matters. (The extract_subvector code
still applies -- it will always be better).

I would welcome any comments or suggestions.

Tim

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.



From 6yearold at gmail.com  Thu Jan  6 06:24:32 2011
From: 6yearold at gmail.com (arrowdodger)
Date: Thu, 6 Jan 2011 15:24:32 +0300
Subject: [LLVMdev] Fw: include/Config/config.h discrepancies between
 CMake and autofoo builds
In-Reply-To: <599090.13147.qm@web62008.mail.re1.yahoo.com>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	<87oc7vxjcm.fsf@wanadoo.es>
	<AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>
	<87fwt7xdwe.fsf@wanadoo.es>
	<AANLkTinWcwivnSELm9aNEOsnRG-L+ARFBn=BBLWhGOuy@mail.gmail.com>
	<599090.13147.qm@web62008.mail.re1.yahoo.com>
Message-ID: <AANLkTikPQJE5S4oi9bziGxwEt34239OQXL-6C+TpemGF@mail.gmail.com>

Okay, i've started slowly working. Who can i send patches for review, when
they will be ready?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110106/88a7e893/attachment.html 

From vanboxem.ruben at gmail.com  Thu Jan  6 06:48:18 2011
From: vanboxem.ruben at gmail.com (Ruben Van Boxem)
Date: Thu, 6 Jan 2011 13:48:18 +0100
Subject: [LLVMdev] Fw: include/Config/config.h discrepancies between
 CMake and autofoo builds
In-Reply-To: <599090.13147.qm@web62008.mail.re1.yahoo.com>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	<87oc7vxjcm.fsf@wanadoo.es>
	<AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>
	<87fwt7xdwe.fsf@wanadoo.es>
	<AANLkTinWcwivnSELm9aNEOsnRG-L+ARFBn=BBLWhGOuy@mail.gmail.com>
	<599090.13147.qm@web62008.mail.re1.yahoo.com>
Message-ID: <AANLkTimhSGxh-N7Xy1JxZsatZo7o1mU+qt5yY8H=jQDK@mail.gmail.com>

2011/1/5 Samuel Crow <samuraileumas at yahoo.com>:
> Whoops, phone rang and I forgot to cc to the list before I typed the message.
>
>
> ----- Forwarded Message ----
>> From: Samuel Crow <samuraileumas at yahoo.com>
>> To: Ruben Van Boxem <vanboxem.ruben at gmail.com>
>> Sent: Wed, January 5, 2011 3:38:21 PM
>> Subject: Re: [LLVMdev] include/Config/config.h discrepancies between CMake and
>>autofoo builds
>>
>>
>>
>>
>>
>> ----- Original Message ----
>> > From: Ruben Van Boxem <vanboxem.ruben at gmail.com>
>> > ?To: ?scar Fuentes <ofv at wanadoo.es>
>> > Cc: llvmdev at cs.uiuc.edu
>> > Sent: Wed, ?January 5, 2011 3:10:29 PM
>> > Subject: Re: [LLVMdev] ?include/Config/config.h discrepancies between CMake
>>and
>>
>> >autofoo ?builds
>> >
>> > 2011/1/5 ?scar Fuentes <ofv at wanadoo.es>:
>> > > Ruben Van ?Boxem ?<vanboxem.ruben at gmail.com> ? writes:
>> > >
>> >
>> > I may be naive, but ?shouldn't a ?*standard* C library implementation
>> > use *standard* ? headers/function prototypes? I understand OSes like BSD
>> > and Solaris ?really ?suck on this point (standards compliance), but I
>> > would ?think linux, Mac OS ?and Windows at least adhere to a large
>> > ?denominator which would make these ?checks kind of superfluous. ?Heck,
>> > all of Qt builds without any of these, and ?it uses only a ?platform
>> > specific header with the necessary defines. I would ?think ?a library
>> > like Qt touches most dark corners of all the platforms ?it ?supports?
>> > (not trying to be a brute here, I'm just ?frustrated ?with
>> > Windows+autotools... and all the projects ?using ?that).
>> >
>>
>>
>> Hi Ruben,
>>
>> CMake is inspired by ?QMake which is what Qt builds all of its cross-platform
>> tools with. You ?might try to find a better example.
>>
>> --Sam Crow
>>

Well, inspiration != clone... IMHO, CMake and QMake are completely
different programs, and if there ever was resemblance, it's far gone
now. QMake uses "internal knowledge" in the form of .conf files in its
mkspecs directory, defining function aliases mostly, to make up for
platform strangeness. You'll see little difference between the msvc
"platformdefs.h" (mostly underscored function defines). Under Unix
it's still a mystery to why it's so popular and so standards ignorant
(in some variants at least).

What I propose is a QMake-like tool (with predefined
platform-toolchain combo's) with the option to pass locations of
3rd-party libraries to it. Heck, every compiler that supports it has
the option to not link to its standard (C(++)) library? (gcc:
-no-stdlib -no-startup etc...). In my ideal world ;-) the program
would not need to generate any kind of project file, but build the
whole project itself, based on a limited number of arguments passed to
it (cross-target, debug/release, 3rdparty libs). All the rest should
be self-contained in the source code itself. Your build system should
not determine whether something can be built or not, and in my eyes,
autotools lays too many constraints on the platform it's run on. Just
look at the work Mozilla needs done before it can build its software
on Windows (MSYS+patches to make it work with MSVC). CMake is only
half-way there in my eyes, and loses its fancyness when function
checks are used.

Ruben


From ofv at wanadoo.es  Thu Jan  6 07:29:41 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Thu, 06 Jan 2011 14:29:41 +0100
Subject: [LLVMdev] Build problems and workarounds with CMake and XCode
In-Reply-To: <861989.96109.qm@web62008.mail.re1.yahoo.com> (Samuel Crow's
	message of "Wed, 5 Jan 2011 19:10:51 -0800 (PST)")
References: <941908.30472.qm@web62002.mail.re1.yahoo.com>
	<87wrmjvtvz.fsf@wanadoo.es>
	<861989.96109.qm@web62008.mail.re1.yahoo.com>
Message-ID: <87sjx6w46y.fsf@wanadoo.es>

Samuel Crow <samuraileumas at yahoo.com> writes:

[snip]

>> I'm not sure what the problem is. Never used  XCode nor I have access to
>> it. What are those scripts? The install scripts  generated by CMake for
>> XCode?
>
> The CMake script generated the XCode project file so I'm assuming it's a problem 
> either with CMake or the CMake scripts.  XCode targets are similar to make 
> targets except that parallel processing is generally implied without any added 
> flags (like make -j).  If this turns out to be a deficiency in CMake itself then 
> most of this discussion can probably be moved to the CMake mailing list.
>
> My main concern with the CMake scripts is that they required a release-build 
> file while making a debug-build install.  This ought not to be.

Agreed. Maybe a bug on the cmake XCode generator. On Linux/mingw/VS you
can install a debug build right away.

So yes, IMO the discussion should move to the cmake ml.

[snip]

From ofv at wanadoo.es  Thu Jan  6 07:34:53 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Thu, 06 Jan 2011 14:34:53 +0100
Subject: [LLVMdev] Fw: include/Config/config.h discrepancies between
	CMake and autofoo builds
In-Reply-To: <AANLkTikPQJE5S4oi9bziGxwEt34239OQXL-6C+TpemGF@mail.gmail.com>
	(arrowdodger's message of "Thu, 6 Jan 2011 15:24:32 +0300")
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	<87oc7vxjcm.fsf@wanadoo.es>
	<AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>
	<87fwt7xdwe.fsf@wanadoo.es>
	<AANLkTinWcwivnSELm9aNEOsnRG-L+ARFBn=BBLWhGOuy@mail.gmail.com>
	<599090.13147.qm@web62008.mail.re1.yahoo.com>
	<AANLkTikPQJE5S4oi9bziGxwEt34239OQXL-6C+TpemGF@mail.gmail.com>
Message-ID: <87lj2yw3ya.fsf@wanadoo.es>

arrowdodger <6yearold at gmail.com> writes:

> Okay, i've started slowly working. Who can i send patches for review, when
> they will be ready?

Send patches to llvm-commits at cs.uiuc.edu for review.

Please mention cmake on the subject line of the e-mails containing the
patches.

From grosser at fim.uni-passau.de  Thu Jan  6 09:16:57 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Thu, 06 Jan 2011 10:16:57 -0500
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>
Message-ID: <4D25DCE9.6020205@fim.uni-passau.de>

On 01/06/2011 03:38 AM, ether zhhb wrote:
> Hi,
>
> I just have a detail look at the code of Polly[1], it seems that Polly
> start to support some basic auto-parallelization stuffs.

This is true. However still work in progress. I hope we can soon show 
some interesting results.

 > I have some idea to improve the current auto-vectorization
 > and parallelization approach in Polly.

> The main idea is, we separate the transform passes and codegen passes
> for auto-parallelization and vectorization (Graphite[2] for gcc seems
> to taking similar approach for auto-vectorization).

This is just historical. Sebastian is planning to couple them a lot 
closer. Graphite and auto parallelization/vectorization are not yet 
playing well together, even if Sebastian made some huge progress with 
Graphite<->Autovec interaction.

> That means Polly (Or other similar framework) should perform necessary
> code transform, then just generates the sequential code, and provides
> necessary parallelism information (These information could be encoded
> as metadata just like TBAA), then the later passes can generate the
> parallel code with those parallelism information.

I also thought about this approach.

> The main benefit of separating transform passes and codegen passes are:
> 1. Decouple the the autopar framework from various parallel runtime
> environment, so we can keep both autopar framework and code generation
> pass for specific parallel runtime environment simple. And we can
> support more parallel runtime environments easily.

Yes, as soon as we start to support more targets we should move out some 
of the logic into separate functions/file/passes. This could be either 
done inside polly or as a generic LLVM pass, depending
on which is more suitable.

> 2. Allow the some generic parallelism information live out specific
> autopar framework, so these information can benefit more passes in
> llvm. For example, the X86 and PTX backend could use these information
> to perform target specific auto-vectorization.

What other types of parallelism are you expecting? We currently support 
thread level parallelism (as in OpenMP) and vector level parallelism (as 
in LLVM-IR vectors). At least for X86 I do not see any reason for
target specific auto-vectorization as LLVM-IR vectors are lowered 
extremely well to x86 SIMD instructions. I suppose this is the same for 
all CPU targets. I still need to look into GPU targets.

> Implementation consideration:
>
> We may define some kind of generic "parallelism analysis" or the
> generic version of "LoopDependenceAnalysis" interface just like
> AliasAnalysis, or we can also encode those parallelism information as
> metadata. And combining the both should be OK, too.

Thanks ether for starting to reason about this.

My current plan is as follows:

Create stable support for OpenMP and LLVM-IR vector generation inside 
polly. This is not very difficult, as you the needed analysis can easily 
be performed in the polyhedral framework. Code generation is not 
difficult either. SIMD Vector support is almost complete and OpenMP code 
generation is also half way through. Based on that infrastructure we can 
take advantage of both thread level as well as SIMD level parallelism 
and which covers the two most common targets.
The next step will be to evaluate loop transformations that enable 
thread and vector level parallelism as it is done e.g. in pluto[1].
I am pretty confident we can show good improvements. Stay tuned. ;-)

Regarding your proposal I hope to move some of the code into more 
generic frameworks. I am thinking e.g. about introducing OpenMP 
intrinsics to support different OpenMP libraries like libgomp and 
mpc[2]. LLVM-IR vector instructions however are generic SIMD 
instructions so I do not see any reason to create target specific
auto vectorizer passes.

The remaining question is how/where to generate parallel/vector
code.

The current approach is to do this directly at Polly code generation 
time, the solution you proposed would be to generate sequential
code inside polly, annotate it with meta data, reparse it and finally 
create openmp/vector code.

The second approach would have the advantage that multiple LLVM passes
can use the information and generate code from it as well as there could 
exist several analysis that create the needed metadata.

It has however the drawback that instead of just doing code generation 
once after polly, we do sequential code generation -> reparsing/analysis 
-> parallel code generation. Furthermore, the infrastructure needs to 
pass all the information needed
for efficient parallelisation which are at least the access strides, the 
alignment and privatized variables. Recomputing this information using 
scalar evolution might be difficult as Polly may introduce
loop ivs using e.g. ceil/floor divisions.

As Polly - based on the current approach - will soon support target 
agnostic autovectorization and OpenMP code generation, I plan to now 
focus on polyhedral loop nest optimizations that enable efficient 
vectorization and thread level parallelism. As this transformations are
performed on the abstract polyhedral description, no further changes to 
the code generation are needed. In case a larger framework is shown to 
be useful, I will definitely support this. For the moment however I am 
very fine with the existing lightweight approach.

Cheers
Tobi

[1] http://pluto-compiler.sourceforge.net/
[2] http://mpc.sf.net

From czhao at eecg.toronto.edu  Thu Jan  6 09:55:57 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Thu, 06 Jan 2011 10:55:57 -0500
Subject: [LLVMdev] What are all the LLVM IRs that will write into memory?
In-Reply-To: <AANLkTint_Z6R5pvVhB1YcyT8jaLebnLO6SNakCifCxJN@mail.gmail.com>
References: <4D252301.9050702@eecg.toronto.edu>
	<AANLkTint_Z6R5pvVhB1YcyT8jaLebnLO6SNakCifCxJN@mail.gmail.com>
Message-ID: <4D25E60D.3090402@eecg.toronto.edu>

On 1/5/2011 9:16 PM, Reid Kleckner wrote:
> On Wed, Jan 5, 2011 at 7:03 PM, Chuck Zhao<czhao at eecg.toronto.edu>  wrote:
>> LLVMers,
>>
>> I need to intercept all LLVM IR instructions that will write into memory and
>> start to do analysis on these instructions.
> ...
>> Does that mean any LLVM IR that has a valid result field will be able to
>> store the result into memory?
> Yes, if the value ends up getting spilled to the stack.
>
>> How about those temps allocated into registers via register allocation?
>> Is there a way to tell such temps at compile time before RA?
> No, I think you need to perform register allocation in order to know
> about writes to the stack.
>
I am actually doing static analysis/optimizations before register 
allocation.
I feel I understand it properly, I will have to intercept each and every 
of such instructions.
Though some may end up being registered allocated, but there is no way 
to know which ones are in the optimization process before RA.
It is safe to assume them all will end of in memory.

Thank you very much, Reid,

Chuck

> Are you doing a static analysis on the instructions or are you trying
> to instrument all memory stores?  If so, Pin and DynamoRIO seem like
> better choices, unless you want to do a static instrumentation, in
> which case I don't know what the right tool would be.
>
> Reid
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From rengolin at systemcall.org  Thu Jan  6 09:59:10 2011
From: rengolin at systemcall.org (Renato Golin)
Date: Thu, 6 Jan 2011 15:59:10 +0000
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <4D25DCE9.6020205@fim.uni-passau.de>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>
	<4D25DCE9.6020205@fim.uni-passau.de>
Message-ID: <AANLkTin02fa09eUwjUUd28auUaKHQdM+dZoU_F7C7pL8@mail.gmail.com>

On 6 January 2011 15:16, Tobias Grosser <grosser at fim.uni-passau.de> wrote:
>> The main idea is, we separate the transform passes and codegen passes
>> for auto-parallelization and vectorization (Graphite[2] for gcc seems
>> to taking similar approach for auto-vectorization).

I agree with Ether.

A two-stage vectorization would allow you to use the simple
loop-unroller already in place to generate vector/mp intrinsics from
them, and if more parallelism is required, use the expensive Poly
framework to skew loops and remove dependencies, so the loop-unroller
and other cheap bits can do their job where then couldn't before.

So, in essence, this is a three-stage job. The optional heavy-duty
Poly analysis, the cheap loop-optimizer and the mp/vector
transformation pass. The best features of having them three is to be
able to choose the level of vectorization you want and to re-use the
current loop analysis into the scheme.


> What other types of parallelism are you expecting? We currently support
> thread level parallelism (as in OpenMP) and vector level parallelism (as
> in LLVM-IR vectors). At least for X86 I do not see any reason for
> target specific auto-vectorization as LLVM-IR vectors are lowered
> extremely well to x86 SIMD instructions. I suppose this is the same for
> all CPU targets. I still need to look into GPU targets.

I'd suggest to try and transform sequential instructions into vector
instructions (in the third stage) if proven to be correct.

So, when Poly skews a loop, and the loop analysis unrolls it to, say,
4 calls to the same instruction, a metadata binding them together can
hint the third stage to make that a vector operation with the same
semantics.


> LLVM-IR vector instructions however are generic SIMD
> instructions so I do not see any reason to create target specific
> auto vectorizer passes.

If you're assuming the original code is using intrinsics, that is
correct. But if you want to generate the vector code from Poly, than
you need to add that support, too.

ARM also has good vector instruction selection (on Cortex-A* with
NEON), so you also get that for free. ;)


cheers,
--renato

From ezengbin at gmail.com  Thu Jan  6 10:16:56 2011
From: ezengbin at gmail.com (Bin Zeng)
Date: Thu, 06 Jan 2011 11:16:56 -0500
Subject: [LLVMdev] Pass to compute livein info
Message-ID: <4D25EAF8.1010608@gmail.com>

Hi all,

Is there a pass that computes livein information for each 
MachineBasicBlock? I tried to find such a pass but could not find any. I 
am trying to use the livein information to get dead registers to insert 
some instructions right before code emission but the livein information 
seems to be invalidated by some pass. I might need to recompute the 
livein information before my pass. Thanks a lot.

Bin

From baldrick at free.fr  Thu Jan  6 11:06:39 2011
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 06 Jan 2011 18:06:39 +0100
Subject: [LLVMdev] Marking a function prototype as being "persistent"
In-Reply-To: <C103AECF-D0ED-4026-954E-40A5A6F4D05F@taodyne.com>
References: <C103AECF-D0ED-4026-954E-40A5A6F4D05F@taodyne.com>
Message-ID: <4D25F69F.4020101@free.fr>

Hi Christophe,

> I'm using LLVM to JIT-compile the XL programming language. I've recently added a whole-program optimization phase that gives excellent results, but I noticed that the StripDeadPrototypesPass was removing all references to my runtime support functions.

why is that a problem?

> Apparently, this depends on the oddly-named UnitAtATime parameter. Set it to false. Try again. Suggestion: what about a comment explaining what "UnitAtATime" means :-)

If UnitAtATime is false this means that you are optimizing functions as you are
generating them, rather than first generating all functions and other globals
and only then optimizing.  It's basically a historical anachronism coming from
the way GCC used to work.

> Even then, my runtime function prorotypes are still being stripped away by the GlobalDCE added by createStandardLTOPasses.

Sure, and why not?  Unused prototypes are not used for anything, they won't
turn up in the generated code for example.

> So my question is: what is the correct, officially recommended way to reference runtime functions so that global DCE won't get rid of them? Or am I supposed to re-create the corresponding Function instances for every translation?

There's some kind of disconnect here, so you need to explain more :)

Ciao, Duncan.

From echristo at apple.com  Thu Jan  6 11:14:30 2011
From: echristo at apple.com (Eric Christopher)
Date: Thu, 6 Jan 2011 09:14:30 -0800
Subject: [LLVMdev] Fw: include/Config/config.h discrepancies between
	CMake and autofoo builds
In-Reply-To: <AANLkTikPQJE5S4oi9bziGxwEt34239OQXL-6C+TpemGF@mail.gmail.com>
References: <AANLkTimSM1XkZNOaDKskqfb0rRA3Ea2ZJQU_2ZPnUE01@mail.gmail.com>
	<EAD8EE07-CE52-45FF-A084-6D5B5D4CA24E@apple.com>
	<AANLkTimin6Uvjz1E0gq2+hjnbdDCBDjHFLQJWM6SstVh@mail.gmail.com>
	<87zkrfzaff.fsf@telefonica.net>
	<38C55808-F2C5-4EFE-BB78-82B98BCA1359@apple.com>
	<87oc7vz0yk.fsf@telefonica.net>
	<B0CD7890-799C-4098-AB74-BE6611F5D171@apple.com>
	<AANLkTikjvvQ1YBhZ_i5cRK7brs=x1MkBH7uc-3eCGSxS@mail.gmail.com>
	<AANLkTinOjhk+Mq6JXMVnKDaieZ25wzifk2Rpyht1Y_K2@mail.gmail.com>
	<87oc7vxjcm.fsf@wanadoo.es>
	<AANLkTimZcxqt27kUDPfDf2wTz+OwSVU3teyH4tN--13j@mail.gmail.com>
	<87fwt7xdwe.fsf@wanadoo.es>
	<AANLkTinWcwivnSELm9aNEOsnRG-L+ARFBn=BBLWhGOuy@mail.gmail.com>
	<599090.13147.qm@web62008.mail.re1.yahoo.com>
	<AANLkTikPQJE5S4oi9bziGxwEt34239OQXL-6C+TpemGF@mail.gmail.com>
Message-ID: <D8AEBD59-FDAD-4AAC-960F-6B926773A5E3@apple.com>


On Jan 6, 2011, at 4:24 AM, arrowdodger wrote:

> Okay, i've started slowly working. Who can i send patches for review, when they will be ready?

To the llvm-commits list. I'll look at the autoconf ones.

-eric



From baldrick at free.fr  Thu Jan  6 11:18:55 2011
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 06 Jan 2011 18:18:55 +0100
Subject: [LLVMdev] Building dragonegg.so failed
In-Reply-To: <20110106060506.GA19464@cs.nctu.edu.tw>
References: <20110106060506.GA19464@cs.nctu.edu.tw>
Message-ID: <4D25F97F.1080305@free.fr>

Hi chenwj,

>    I am trying to build gcc 4.5 with dragonegg plugin. After building
> patched gcc 4.5, I try to build dragonegg.so but failed.

you need to build dragonegg-2.8 against LLVM-2.8.

Ciao, Duncan.

>
>    Here is the error messgae,
>
> -----------------------------------------------------------------------
> $ GCC=/tmp/chenwj/install/bin/gcc make
> Compiling utils/target.cpp
> /tmp/chenwj/dragonegg-2.8/utils/target.cpp: In function 'int main(int,
> char**)':
> /tmp/chenwj/dragonegg-2.8/utils/target.cpp:39: error: 'normalize' is not
> a member of 'llvm::Triple'
> make: *** [target.o] Error 1
> -----------------------------------------------------------------------
>
>    How can I fix it? Thanks!
>
> Regards,
> chenwj
>


From czhao at eecg.toronto.edu  Thu Jan  6 11:21:17 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Thu, 06 Jan 2011 12:21:17 -0500
Subject: [LLVMdev] Identify Loops from within FunctionPass,
 or possible to intermix different types of Passes?
Message-ID: <4D25FA0D.6090908@eecg.toronto.edu>

LLVMers,

I have a traversal plan which needs to visit certain types of Functions. 
For each instruction in such functions, I will need to know:
1. is it located inside a loop
2. if yes, what level of loop nest it is currently in.

So on the highest level, it should be a FunctionPass. However, in order 
to identify loops and loop-nest levels, it should also be a LoopPass.

Is there a reasonably simple way to identify loop(s) within a function 
under FunctionPass?

(Any existing LLVM code that I can take a look?)

OR

Is it possible to intermix different types of LLVM Passes?

E.g.

class MyPass: public FunctionPass, public LoopPass{
   ...
public:
   bool runOnFunction(...);
   bool runOnLoop(...);
   ...
};

Does this make any sense?
I haven't seem to find any existing LLVM pass under such uses.


Thank you very much

Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110106/b003904a/attachment.html 

From reid.kleckner at gmail.com  Thu Jan  6 11:24:26 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Thu, 6 Jan 2011 10:24:26 -0700
Subject: [LLVMdev] Marking a function prototype as being "persistent"
In-Reply-To: <4D25F69F.4020101@free.fr>
References: <C103AECF-D0ED-4026-954E-40A5A6F4D05F@taodyne.com>
	<4D25F69F.4020101@free.fr>
Message-ID: <AANLkTik3kDiabJ5Vj2UPe2rshy_QSoXYH+keSYb2rkD6@mail.gmail.com>

On Thu, Jan 6, 2011 at 10:06 AM, Duncan Sands <baldrick at free.fr> wrote:
>> So my question is: what is the correct, officially recommended way to reference runtime functions so that global DCE won't get rid of them? Or am I supposed to re-create the corresponding Function instances for every translation?
>
> There's some kind of disconnect here, so you need to explain more :)

Presumably since he's using the JIT he's generating more code later
that uses the runtime functions, which he wants to be marked as
available.

The disconnect is wanting to apply whole-program/LTO type
optimizations before you have the whole program.

I think the answer is to not use the standard LTO passes and to create
your own versions that are careful not to do things like delete types
and prototypes that you might need later.

Reid

From christophe at taodyne.com  Thu Jan  6 12:08:50 2011
From: christophe at taodyne.com (Christophe de Dinechin)
Date: Thu, 6 Jan 2011 19:08:50 +0100
Subject: [LLVMdev] Marking a function prototype as being "persistent"
In-Reply-To: <AANLkTik3kDiabJ5Vj2UPe2rshy_QSoXYH+keSYb2rkD6@mail.gmail.com>
References: <C103AECF-D0ED-4026-954E-40A5A6F4D05F@taodyne.com>
	<4D25F69F.4020101@free.fr>
	<AANLkTik3kDiabJ5Vj2UPe2rshy_QSoXYH+keSYb2rkD6@mail.gmail.com>
Message-ID: <E6F77351-6348-42C9-AD60-66E454ECE1F5@taodyne.com>

On 6 janv. 2011, at 18:24, Reid Kleckner wrote:

> On Thu, Jan 6, 2011 at 10:06 AM, Duncan Sands <baldrick at free.fr> wrote:
>>> So my question is: what is the correct, officially recommended way to reference runtime functions so that global DCE won't get rid of them? Or am I supposed to re-create the corresponding Function instances for every translation?
>> 
>> There's some kind of disconnect here, so you need to explain more :)
> 
> Presumably since he's using the JIT he's generating more code later
> that uses the runtime functions, which he wants to be marked as
> available.

That's correct. Basically, when my runtime decides to JIT some code, it generates a top-level entry point, all the required functions, and then runs LTO on the result. One reason I want LTO is inlining.


> The disconnect is wanting to apply whole-program/LTO type
> optimizations before you have the whole program.

This is a dynamic language. Part of the program source may be a result of previous evaluations, so there's now way to even know when I have the whole program. That doesn't mean I don't want to inline.


> I think the answer is to not use the standard LTO passes and to create
> your own versions that are careful not to do things like delete types
> and prototypes that you might need later.

But standard passes exist for a reason. I tried the approach you suggest, and since I did it (around 2.5 I guess), I didn't keep up. That cost me something like 20% in performance compared to standard passes.

Now, copy-pasting standard passes code just to remove the passes I don't want... nuf said.

It's actually easier in my case to recreate the prototypes each time. But I wanted to check first if there wasn't an obvious way I had missed to bump the use count of a global value or function to indicate that one of my own classes has a live pointer to it.


Thanks
Christophe

From christophe at taodyne.com  Thu Jan  6 12:36:05 2011
From: christophe at taodyne.com (Christophe de Dinechin)
Date: Thu, 6 Jan 2011 19:36:05 +0100
Subject: [LLVMdev] Marking a function prototype as being "persistent"
In-Reply-To: <mailman.0.1294336801.2003.llvmdev@cs.uiuc.edu>
References: <mailman.0.1294336801.2003.llvmdev@cs.uiuc.edu>
Message-ID: <31F885ED-857C-4A90-AE6F-670202008E55@taodyne.com>


On 6 janv. 2011, at 19:00, llvmdev-request at cs.uiuc.edu wrote:

>> I'm using LLVM to JIT-compile the XL programming language. I've recently added a whole-program optimization phase that gives excellent results, but I noticed that the StripDeadPrototypesPass was removing all references to my runtime support functions.
> 
> why is that a problem?

Because I have pointers to functions which suddenly go bad.

>> Apparently, this depends on the oddly-named UnitAtATime parameter. Set it to false. Try again. Suggestion: what about a comment explaining what "UnitAtATime" means :-)
> 
> If UnitAtATime is false this means that you are optimizing functions as you are
> generating them, rather than first generating all functions and other globals
> and only then optimizing.  It's basically a historical anachronism coming from
> the way GCC used to work.

Thanks for explaining.

Why not redefine it from historical anachronism to architectural flag, that indicates you may generate more code with the same functions and globals later? And then, you could pass the same flag to createStandardLTOPasses, and that would skip the GlobalDCE passes.


>> Even then, my runtime function prorotypes are still being stripped away by the GlobalDCE added by createStandardLTOPasses.
> 
> Sure, and why not?  Unused prototypes are not used for anything, they won't
> turn up in the generated code for example.

They are not used this time. But why can't I generate additional code in the same module after having run LTO?

From dpatel at apple.com  Thu Jan  6 13:13:07 2011
From: dpatel at apple.com (Devang Patel)
Date: Thu, 6 Jan 2011 11:13:07 -0800
Subject: [LLVMdev] Questions about debug info in LLVM 2.8
In-Reply-To: <4D23E658.6010203@oracle.com>
References: <4D23E658.6010203@oracle.com>
Message-ID: <2E72D242-582C-4FE6-9861-2E62BFE9E6FF@apple.com>


On Jan 4, 2011, at 7:32 PM, Jacob Zimmermann wrote:

> Hi,
> 
> I'm currently porting some code from LLVM 2.6 to 2.8 and need to be able
> to extract the debug info produced by LLVM-GCC and stored in the
> compiled .bc file. However I admit I'm slightly confused about how
> exactly to do that, the documentation doesn't seem to be very clear
> about this, it mainly describes how to *generate* debug info.
> Specifically I'm wondering about the following points:
> 
> 1) It seems that the various DIDescriptors contain the information I'd
> need, but they can only be constructed from a MDNode How do I retrieve
> the MDNode at the first place? Does MDNode::get() actually retrieve all
> the debug metadata from Module, or does it merely initialise a fresh MDNode?
> 
> 2) DebugLoc has a getAsMDNode() method, but apparently it's only
> available for Instructions?
> 
> 3) How can I retrieve a DIType instance? I can't find a way to obtain a
> MDNode for a Type... ?
> 
> Many thanks if somebody can shed some light on this.

See DebugInfoFinder interface in Analysis/DebugInfo.h

-
Devang

From dpatel at apple.com  Thu Jan  6 13:24:53 2011
From: dpatel at apple.com (Devang Patel)
Date: Thu, 6 Jan 2011 11:24:53 -0800
Subject: [LLVMdev] Identify Loops from within FunctionPass,
	or possible to intermix different types of Passes?
In-Reply-To: <4D25FA0D.6090908@eecg.toronto.edu>
References: <4D25FA0D.6090908@eecg.toronto.edu>
Message-ID: <898C4BD5-369B-44A5-872F-E0A8E3570414@apple.com>


On Jan 6, 2011, at 9:21 AM, Chuck Zhao wrote:

> LLVMers,
> 
> I have a traversal plan which needs to visit certain types of Functions. For each instruction in such functions, I will need to know:
> 1. is it located inside a loop
> 2. if yes, what level of loop nest it is currently in.
> 
> So on the highest level, it should be a FunctionPass. However, in order to identify loops and loop-nest levels, it should also be a LoopPass.
> 
> Is there a reasonably simple way to identify loop(s) within a function under FunctionPass?
> 
> (Any existing LLVM code that I can take a look?)

Your FunctionPass can use LoopInfo to get this information.

-
Devang

> 
> OR
> 
> Is it possible to intermix different types of LLVM Passes?
> 
> E.g.
> 
> class MyPass: public FunctionPass, public LoopPass{
>   ...
> public:
>   bool runOnFunction(...);
>   bool runOnLoop(...);
>   ...
> };
> 
> Does this make any sense?
> I haven't seem to find any existing LLVM pass under such uses.
> 
> 
> Thank you very much
> 
> Chuck
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110106/8eef7199/attachment.html 

From jdkunk3 at gmail.com  Thu Jan  6 14:06:08 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Thu, 6 Jan 2011 15:06:08 -0500
Subject: [LLVMdev] Identify Loops from within FunctionPass,
 or possible to intermix different types of Passes?
In-Reply-To: <898C4BD5-369B-44A5-872F-E0A8E3570414@apple.com>
References: <4D25FA0D.6090908@eecg.toronto.edu>
	<898C4BD5-369B-44A5-872F-E0A8E3570414@apple.com>
Message-ID: <AANLkTinXbNj8DQrtVnkaXZPTw-oV0k7v8yhCGPeOiiuC@mail.gmail.com>

I've never seen a LoopPass, but doing a function pass and grab the loop info
from "\llvm\Analysis\LoopInfo.h".

>From there just you use the LoopInfo api to grap the loop headers and loop
blocks and whatever else you want to do.

- Thank
Jeff Kunkel

On Thu, Jan 6, 2011 at 2:24 PM, Devang Patel <dpatel at apple.com> wrote:

>
> On Jan 6, 2011, at 9:21 AM, Chuck Zhao wrote:
>
>  LLVMers,
>
> I have a traversal plan which needs to visit certain types of Functions.
> For each instruction in such functions, I will need to know:
> 1. is it located inside a loop
> 2. if yes, what level of loop nest it is currently in.
>
> So on the highest level, it should be a FunctionPass. However, in order to
> identify loops and loop-nest levels, it should also be a LoopPass.
>
> Is there a reasonably simple way to identify loop(s) within a function
> under FunctionPass?
>
> (Any existing LLVM code that I can take a look?)
>
>
> Your FunctionPass can use LoopInfo to get this information.
>
> -
> Devang
>
>
> OR
>
> Is it possible to intermix different types of LLVM Passes?
>
> E.g.
>
> class MyPass: public FunctionPass, public LoopPass{
>   ...
> public:
>   bool runOnFunction(...);
>   bool runOnLoop(...);
>   ...
> };
>
> Does this make any sense?
> I haven't seem to find any existing LLVM pass under such uses.
>
>
> Thank you very much
>
> Chuck
>
>  _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110106/5ae345ce/attachment.html 

From jdkunk3 at gmail.com  Thu Jan  6 16:15:15 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Thu, 6 Jan 2011 17:15:15 -0500
Subject: [LLVMdev] [LLVMDev] Stack Space and Removing it's Attachment to
	Register Allocation
Message-ID: <AANLkTik8WnfBrTnrNzcWZszgdGUDjaTk62aSYsvH_pdi@mail.gmail.com>

Hi, I would like to know what you guys think about building a model such
that stack allocation does not depend on register allocation.

I would like to create virtual stack space variables where variables will be
spilled. Then the final stack allocation algorithm can commence without
having to look at the register allocation scheme. The virtual stack space
variables would have the same rules as virtual registers variables.
Pre-coloring rules apply like a variable which is volatile so it's stack
space  cannot be stored on the stack.

- Thanks
- Jeff Kunkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110106/58af8613/attachment.html 

From baldrick at free.fr  Thu Jan  6 18:00:53 2011
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 07 Jan 2011 01:00:53 +0100
Subject: [LLVMdev] Marking a function prototype as being "persistent"
In-Reply-To: <31F885ED-857C-4A90-AE6F-670202008E55@taodyne.com>
References: <mailman.0.1294336801.2003.llvmdev@cs.uiuc.edu>
	<31F885ED-857C-4A90-AE6F-670202008E55@taodyne.com>
Message-ID: <4D2657B5.6050902@free.fr>

Hi Christophe,

>>> Apparently, this depends on the oddly-named UnitAtATime parameter. Set it to false. Try again. Suggestion: what about a comment explaining what "UnitAtATime" means :-)
>>
>> If UnitAtATime is false this means that you are optimizing functions as you are
>> generating them, rather than first generating all functions and other globals
>> and only then optimizing.  It's basically a historical anachronism coming from
>> the way GCC used to work.
>
> Thanks for explaining.
>
> Why not redefine it from historical anachronism to architectural flag, that indicates you may generate more code with the same functions and globals later? And then, you could pass the same flag to createStandardLTOPasses, and that would skip the GlobalDCE passes.

LTO is for doing optimizations that are only valid when the module contains
everything that is needed to build the final executable.  So adding a flag to
say "not everything is there after all" makes no sense to me.

>>> Even then, my runtime function prorotypes are still being stripped away by the GlobalDCE added by createStandardLTOPasses.
>>
>> Sure, and why not?  Unused prototypes are not used for anything, they won't
>> turn up in the generated code for example.
>
> They are not used this time. But why can't I generate additional code in the same module after having run LTO?

Because by definition LTO is for when everything is there!  Why don't you
create your own sequence of passes that does what you want rather than calling
createStandardLTOPasses?  One of the nice features of LLVM is that you can
run any passes you choose in any order you like.  That said, probably the reason
you are getting improved optimization is due to running the "internalize" pass.
If so be warned that it is not safe to run internalize unless all functions and
their bodies are present in the module.  If you run internalize, optimize, and
then later add a few more functions to the module all kinds of nasty subtle
things can go wrong, not just those you saw with GlobalDCE.

Ciao, Duncan.

From yulin at nvidia.com  Thu Jan  6 18:17:15 2011
From: yulin at nvidia.com (Yuan Lin)
Date: Thu, 6 Jan 2011 16:17:15 -0800
Subject: [LLVMdev] DWARF version
Message-ID: <7EBA7A880CFD5440A1AA2C987DFACB2D10781779A9@HQMAIL04.nvidia.com>

Hi, I have a newbie question regarding debugging support in llvm.

Is llvm generating DWARF2 or DWARF3? The comments in the trunk source code refer to the DWARF 3 spec, but DWARF_VERSION is set to 2 in Support/Dwarf.h.

What am I missing? Thanks.

-- Yuan




-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110106/3788bb52/attachment.html 

From jacob.zimmermann at oracle.com  Thu Jan  6 18:21:08 2011
From: jacob.zimmermann at oracle.com (Jacob Zimmermann)
Date: Fri, 07 Jan 2011 10:21:08 +1000
Subject: [LLVMdev] Questions about debug info in LLVM 2.8
In-Reply-To: <2E72D242-582C-4FE6-9861-2E62BFE9E6FF@apple.com>
References: <4D23E658.6010203@oracle.com>
	<2E72D242-582C-4FE6-9861-2E62BFE9E6FF@apple.com>
Message-ID: <1294359668.6207.1.camel@easteregg>


On Thu, 2011-01-06 at 11:13 -0800, Devang Patel wrote:

> On Jan 4, 2011, at 7:32 PM, Jacob Zimmermann wrote:
> 
> > Hi,
> > 
> > I'm currently porting some code from LLVM 2.6 to 2.8 and need to be able
> > to extract the debug info produced by LLVM-GCC and stored in the
> > compiled .bc file. However I admit I'm slightly confused about how
> > exactly to do that, the documentation doesn't seem to be very clear
> > about this, it mainly describes how to *generate* debug info.
> > Specifically I'm wondering about the following points:
> > 
> > 1) It seems that the various DIDescriptors contain the information I'd
> > need, but they can only be constructed from a MDNode How do I retrieve
> > the MDNode at the first place? Does MDNode::get() actually retrieve all
> > the debug metadata from Module, or does it merely initialise a fresh MDNode?
> > 
> > 2) DebugLoc has a getAsMDNode() method, but apparently it's only
> > available for Instructions?
> > 
> > 3) How can I retrieve a DIType instance? I can't find a way to obtain a
> > MDNode for a Type... ?
> > 
> > Many thanks if somebody can shed some light on this.
> 
> See DebugInfoFinder interface in Analysis/DebugInfo.h


Thanks Devang, however this doesn't seem to let me access local
variables, do you know how I can get at them?

Thanks
Jacob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110107/f1bf5329/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110107/f1bf5329/attachment.bin 

From chenwj at iis.sinica.edu.tw  Thu Jan  6 19:17:01 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Fri, 7 Jan 2011 09:17:01 +0800
Subject: [LLVMdev] Building dragonegg.so failed
In-Reply-To: <4D25F97F.1080305@free.fr>
References: <20110106060506.GA19464@cs.nctu.edu.tw> <4D25F97F.1080305@free.fr>
Message-ID: <20110107011701.GA21492@cs.nctu.edu.tw>

Hi, Duncan

> you need to build dragonegg-2.8 against LLVM-2.8.

  I did build LLVM-2.8, however it's not system-wide. I wonder if it is
because it cannot find the path to my LLVM-2.8 direcotry. If so, how can
I tell him?
  
  Thanks!

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From ww345ww at gmail.com  Thu Jan  6 20:43:19 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Fri, 7 Jan 2011 10:43:19 +0800
Subject: [LLVMdev] about NDEBUG
Message-ID: <AANLkTi=0SODHUVt0BtmhdjDEOxVbuxAFZKRvBB=8jSau@mail.gmail.com>

Hi Mr/Mz,

I have built and installed llvm-2.8 in debug mode using:

>SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime
 --disable-optimized --enable-debug-symbols

>make install


It seems the NDEBUG controls a lot of print-out of debug information, by
using DEBUG() or dbgs().

And it is said that NDEBUG is in enabled in debug mode, but I find it does
not work and the -debug option is not recognized. How should I enable NDEBUG
or enable DEBUG() and dbgs()? Should I define NDEBUG in the .cpp files
related, when I need the debug information?



-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110107/09915b37/attachment.html 

From bijoy123_8 at yahoo.com  Thu Jan  6 21:31:09 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Thu, 6 Jan 2011 19:31:09 -0800 (PST)
Subject: [LLVMdev] Can anyone please give any suggestions?
Message-ID: <421199.7611.qm@web121709.mail.ne1.yahoo.com>

?I tried the automated scripts (create-snapshots.sh and build-install-linux.sh) that?are in the LLVM repository for building crosstoll for ARM (http://llvm.org/svn/llvm-project/llvm/trunk/utils/crosstool/) but get the following error for building llvm-gcc (llvm built successfully):
?
'arm1026ej-s' is not a recognized processor for this target (ignoring processor)
'arm1026ej-s' is not a recognized processor for this target (ignoring processor)
/tmp/llvm-project.YZQXqN/src/llvm-gcc-4.2/gcc/crtstuff.c:1: internal compiler er
ror: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs/> for instructions.
make[2]: *** [crtbegin.o] Error 1
make[2]: Leaving directory `/tmp/llvm-project.YZQXqN/obj/llvm-gcc-4.2/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/tmp/llvm-project.YZQXqN/obj/llvm-gcc-4.2'
make: *** [all] Error 2
~

I am using the latest version of LLVM and LLVM-GCC from SVN (version number: 122872). And I am using arm-2009q1-176-arm-none-linux-gnueabi-i686-mingw32.tar.bz2. I am using CygWin. Can anyone please tell me what is the reason of the problem? 
?
Akramul



-----Inline Attachment Follows-----

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110106/e784ecb6/attachment.html 

From christophe at taodyne.com  Thu Jan  6 23:21:31 2011
From: christophe at taodyne.com (Christophe de Dinechin)
Date: Fri, 7 Jan 2011 06:21:31 +0100
Subject: [LLVMdev] Marking a function prototype as being "persistent"
In-Reply-To: <4D2657B5.6050902@free.fr>
References: <mailman.0.1294336801.2003.llvmdev@cs.uiuc.edu>
	<31F885ED-857C-4A90-AE6F-670202008E55@taodyne.com>
	<4D2657B5.6050902@free.fr>
Message-ID: <AC340417-F03E-418C-B55E-B0BFDF03314E@taodyne.com>

Hi Duncan,

On 7 janv. 2011, at 01:00, Duncan Sands wrote:

> LTO is for doing optimizations that are only valid when the module contains
> everything that is needed to build the final executable.  So adding a flag to
> say "not everything is there after all" makes no sense to me.

And indeed, everything is there when I call LTO. The flag is not "not everything is there after all", but "don't damage your inputs".

> 
>>>> Even then, my runtime function prorotypes are still being stripped away by the GlobalDCE added by createStandardLTOPasses.
>>> 
>>> Sure, and why not?  Unused prototypes are not used for anything, they won't
>>> turn up in the generated code for example.
>> 
>> They are not used this time. But why can't I generate additional code in the same module after having run LTO?
> 
> Because by definition LTO is for when everything is there!

And again, everything is there. I just want to be able to reuse the same inputs later for incremental recompilation.

>  Why don't you create your own sequence of passes that does what you want rather than calling createStandardLTOPasses?

As I wrote in an earlier reply, been there, done that. That forces me to maintain a quasi-clone of standard passes.

>  One of the nice features of LLVM is that you can run any passes you choose in any order you like.

Having standard LTO passes get in the way of incremental recompilation is not a feature.

>  That said, probably the reason you are getting improved optimization is due to running the "internalize" pass. If so be warned that it is not safe to run internalize unless all functions and their bodies are present in the module.

All functions and bodies are present, so that's not the issue. The issue is that some inputs of LTO are destroyed as a side effect of running it.

> If you run internalize, optimize, and then later add a few more functions to the module all kinds of nasty subtle things can go wrong, not just those you saw with GlobalDCE.

Do you mean I should assume for example that the Functions I generated are also irreversibly damaged? If so, what passes do I need to avoid if I want to preserve the ability to do incremental recompilation?


Thanks for your help
Christophe

From etherzhhb at gmail.com  Thu Jan  6 23:36:07 2011
From: etherzhhb at gmail.com (ether zhhb)
Date: Fri, 7 Jan 2011 13:36:07 +0800
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <4D25DCE9.6020205@fim.uni-passau.de>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>
	<4D25DCE9.6020205@fim.uni-passau.de>
Message-ID: <AANLkTik28zXP8ABc69mR--B++oByE7h2SJUVJSswTAar@mail.gmail.com>

Hi tobi,


>> 2. Allow the some generic parallelism information live out specific
>> autopar framework, so these information can benefit more passes in
>> llvm. For example, the X86 and PTX backend could use these information
>> to perform target specific auto-vectorization.
>
> What other types of parallelism are you expecting? We currently support
> thread level parallelism (as in OpenMP) and vector level parallelism (as in
> LLVM-IR vectors). At least for X86 I do not see any reason for
> target specific auto-vectorization as LLVM-IR vectors are lowered extremely
> well to x86 SIMD instructions. I suppose this is the same for all CPU
> targets. I still need to look into GPU targets.
>
I just think the vector units in different target may have a
difference width, so the best unroll count of a loop for vectorization
in not know in high level optimization passes.


> It has however the drawback that instead of just doing code generation once
> after polly, we do sequential code generation -> reparsing/analysis ->
> parallel code generation. Furthermore, the infrastructure needs to pass all
> the information needed
> for efficient parallelisation which are at least the access strides, the
> alignment and privatized variables. Recomputing this information using
> scalar evolution might be difficult as Polly may introduce
> loop ivs using e.g. ceil/floor divisions.

To overcame this, We can encode these kind of "hard to recover"
information as metadata while generating sequential code, and what the
later "Polyhedral Parallelism Analysis" pass need to do is just read
these information form metadata, and reparsing/analysis other
information which is easy to recover. so the process become:
sequential code generation and metadata annotation -> read metadata
(and perform some cheap reparsing/analysis)->parallel code generation

The bigger picture is:
1. Define the common interface for "Parallelism Analysis" or
"LoopDependenceAnalysis", just like AliasAnalysis.
2. Then we can have different implementations of Parallelism Analysis.
    For example, we may have the "SCEVParallelsimAnalysis", which
compute the parallelism information base on SCEV.
    and we can also have the "PolyhedralParallelismAnalysis", which
read "hard to recover" information from metadata and recompute the
cheap information, then provides these information via the common
"Parallelism Analysis" interface.
3. The auto-vectorization and parallelization codegen passes can just
ask the common interface of "Parallelism Analysis" to get necessary
information.

The new approach may also make current work for OpenMP support esaier,
Instead of generate the subfunction directly from clast and insert new
function in a region pass(it seems that we can only insert new
function in a modulepass or callgraphSCC pass), we can extract the
body of the parallel for to a new function with existing CodeExtractor
in LLVM.

best regards
ether

From andrew at sidefx.com  Fri Jan  7 00:11:10 2011
From: andrew at sidefx.com (andrew at sidefx.com)
Date: Fri, 7 Jan 2011 01:11:10 -0500 (EST)
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
Message-ID: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>

Would it be possible to increase TargetRegisterInfo::FirstVirtualRegister
to something quite a bit larger - such as 2^31?  I'm working on a target
where all SSA values need to be assigned physical registers, and the
current limit of 16384 may limit the size of programs that I'm able to
handle.  2^31 is a nice value since there are equal numbers of possible
physical and virtual registers, and registers can just inspect the high
bit to determine if it's a virtual register.  My only concern is that
there may be data structures using FirstVirtualRegister to size tables
rather than using the MachineRegisterInfo limit.

Along with this change, I would also propose subtracting
FirstVirtualRegister from the printed values of virtual registers, so that
what used to be "reg16384" would now show up as "reg0".

Andrew


From clattner at apple.com  Fri Jan  7 00:18:48 2011
From: clattner at apple.com (Chris Lattner)
Date: Thu, 6 Jan 2011 22:18:48 -0800
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
Message-ID: <6440836A-4A6A-448D-959B-65E660B3B286@apple.com>


On Jan 6, 2011, at 10:11 PM, andrew at sidefx.com wrote:

> Would it be possible to increase TargetRegisterInfo::FirstVirtualRegister
> to something quite a bit larger - such as 2^31?  I'm working on a target
> where all SSA values need to be assigned physical registers, and the
> current limit of 16384 may limit the size of programs that I'm able to
> handle.  2^31 is a nice value since there are equal numbers of possible
> physical and virtual registers, and registers can just inspect the high
> bit to determine if it's a virtual register.  My only concern is that
> there may be data structures using FirstVirtualRegister to size tables
> rather than using the MachineRegisterInfo limit.

If you're interested in doing this, I'd suggest hacking up the backend to not run register allocation, and represent all your "physical" registers are virtual registers.  This gives you an unlimited number.

-Chris

From andrew at sidefx.com  Fri Jan  7 00:39:09 2011
From: andrew at sidefx.com (andrew at sidefx.com)
Date: Fri, 7 Jan 2011 01:39:09 -0500 (EST)
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
	<6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
Message-ID: <34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>


> If you're interested in doing this, I'd suggest hacking up the backend to
> not run register allocation, and represent all your "physical" registers
> are virtual registers.  This gives you an unlimited number.
>

Yes it would be ideal to use all virtual registers, but a glance at the
code seemed to indicate the the use of physical registers, spilling, etc.
was pretty ingrained in all the register allocation algorithms, so it
seemed like it would be difficult to extract.  I also still need to
minimize the number of registers and minimize copies as if it were
generating code for more restrictive hardware.

Ideally I'd like something like the linear register allocator but that
never spilled or assigned physical registers, along with other goodies
like coalescing and phi elimination.

On the other hand, just increasing the allowable physical registers would
immediately solve most of my problems.

Andrew


From reid.kleckner at gmail.com  Fri Jan  7 00:53:42 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Thu, 6 Jan 2011 23:53:42 -0700
Subject: [LLVMdev] Marking a function prototype as being "persistent"
In-Reply-To: <AC340417-F03E-418C-B55E-B0BFDF03314E@taodyne.com>
References: <mailman.0.1294336801.2003.llvmdev@cs.uiuc.edu>
	<31F885ED-857C-4A90-AE6F-670202008E55@taodyne.com>
	<4D2657B5.6050902@free.fr>
	<AC340417-F03E-418C-B55E-B0BFDF03314E@taodyne.com>
Message-ID: <AANLkTimhHt-fXO0kVsK_mjQzNEySwEoCuFs8hssPAOvk@mail.gmail.com>

On Thu, Jan 6, 2011 at 10:21 PM, Christophe de Dinechin
<christophe at taodyne.com> wrote:
>> ?Why don't you create your own sequence of passes that does what you want rather than calling createStandardLTOPasses?
>
> As I wrote in an earlier reply, been there, done that. That forces me to maintain a quasi-clone of standard passes.

No, this is a different suggestion, it is to maintain a separate list
of what passes are known to not violate your assumptions, ie don't run
GlobalDCE and StripDeadPrototypes, and maybe some others.  I don't
know enough to give you a list.  This could be better documented.  I
know we ran into issues using the standard IPO passes for unladen
swallow, but I don't know what the resolution was.

>> ?One of the nice features of LLVM is that you can run any passes you choose in any order you like.
>
> Having standard LTO passes get in the way of incremental recompilation is not a feature.

I would say that deleting as much dead code as possible during LTO is a feature.

Reid


From clattner at apple.com  Fri Jan  7 01:07:16 2011
From: clattner at apple.com (Chris Lattner)
Date: Thu, 6 Jan 2011 23:07:16 -0800
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
	<6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
	<34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
Message-ID: <1701B32D-079E-45F7-B904-719296C57D6F@apple.com>


On Jan 6, 2011, at 10:39 PM, andrew at sidefx.com wrote:

> 
>> If you're interested in doing this, I'd suggest hacking up the backend to
>> not run register allocation, and represent all your "physical" registers
>> are virtual registers.  This gives you an unlimited number.
>> 
> 
> Yes it would be ideal to use all virtual registers, but a glance at the
> code seemed to indicate the the use of physical registers, spilling, etc.
> was pretty ingrained in all the register allocation algorithms, so it
> seemed like it would be difficult to extract.  I also still need to
> minimize the number of registers and minimize copies as if it were
> generating code for more restrictive hardware.
> 
> Ideally I'd like something like the linear register allocator but that
> never spilled or assigned physical registers, along with other goodies
> like coalescing and phi elimination.
> 
> On the other hand, just increasing the allowable physical registers would
> immediately solve most of my problems.

Unless your goal is to merge this work onto LLVM mainline, the best thing to do is a local hack in your tree.

-Chris

From etherzhhb at gmail.com  Fri Jan  7 01:19:53 2011
From: etherzhhb at gmail.com (ether zhhb)
Date: Fri, 7 Jan 2011 15:19:53 +0800
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
	<6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
	<34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
Message-ID: <AANLkTik63WZaCsDMYbJb8N9E06bDCGkg2weMc=Gfzk9z@mail.gmail.com>

hi andrew,


On Fri, Jan 7, 2011 at 2:39 PM,  <andrew at sidefx.com> wrote:
>
>> If you're interested in doing this, I'd suggest hacking up the backend to
>> not run register allocation, and represent all your "physical" registers
>> are virtual registers. ?This gives you an unlimited number.
>>
>
> Yes it would be ideal to use all virtual registers, but a glance at the
> code seemed to indicate the the use of physical registers, spilling, etc.
you can override the function "addPassesToEmitFile" of your target
machine, so register allocator will not run on your machinefunctions.

best regards
ether


From baldrick at free.fr  Fri Jan  7 01:44:38 2011
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 07 Jan 2011 08:44:38 +0100
Subject: [LLVMdev] Building dragonegg.so failed
In-Reply-To: <20110107011701.GA21492@cs.nctu.edu.tw>
References: <20110106060506.GA19464@cs.nctu.edu.tw> <4D25F97F.1080305@free.fr>
	<20110107011701.GA21492@cs.nctu.edu.tw>
Message-ID: <4D26C466.5060806@free.fr>

Hi chenwj,

>> you need to build dragonegg-2.8 against LLVM-2.8.
>
>    I did build LLVM-2.8, however it's not system-wide. I wonder if it is
> because it cannot find the path to my LLVM-2.8 direcotry. If so, how can
> I tell him?

find the llvm-config executable for LLVM-2.8.  If you installed LLVM-2.8 you
can use the one that was installed.  If you only built it, you can use the one
from the build.  Anyway, suppose the path to the executable is PATH/llvm-config.
Then build dragonegg using:
	LLVM_CONFIG=PATH/llvm-config make

Ciao, Duncan.

From baldrick at free.fr  Fri Jan  7 01:56:12 2011
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 07 Jan 2011 08:56:12 +0100
Subject: [LLVMdev] about NDEBUG
In-Reply-To: <AANLkTi=0SODHUVt0BtmhdjDEOxVbuxAFZKRvBB=8jSau@mail.gmail.com>
References: <AANLkTi=0SODHUVt0BtmhdjDEOxVbuxAFZKRvBB=8jSau@mail.gmail.com>
Message-ID: <4D26C71C.1020107@free.fr>

Hi Li Qingan,

> I have built and installed llvm-2.8 in debug mode using:
> 
>>SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime --disable-optimized 
> --enable-debug-symbols
> 
>>make install
> 
> 
> It seems the NDEBUG controls a lot of print-out of debug information, by using 
> DEBUG() or dbgs().
> 
> And it is said that NDEBUG is in enabled in debug mode, but I find it does not 
> work and the -debug option is not recognized. How should I enable NDEBUG or 
> enable DEBUG() and dbgs()? Should I define NDEBUG in the .cpp files related, 
> when I need the debug information?

actually it is the opposite: NDEBUG is enabled when not in debug mode.  The "N" in
NDEBUG stands for "Not".

Ciao, Duncan.

From chenwj at iis.sinica.edu.tw  Fri Jan  7 02:26:41 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Fri, 7 Jan 2011 16:26:41 +0800
Subject: [LLVMdev] Building dragonegg.so failed
In-Reply-To: <4D26C466.5060806@free.fr>
References: <20110106060506.GA19464@cs.nctu.edu.tw> <4D25F97F.1080305@free.fr>
	<20110107011701.GA21492@cs.nctu.edu.tw> <4D26C466.5060806@free.fr>
Message-ID: <20110107082641.GA58364@cs.nctu.edu.tw>

Hi Duncan,

  Thanks. I wonder if this hint can be put on http://dragonegg.llvm.org/.
And one comment, building dragonegg.so needs a gcc built with
"--enable-lto" option. Could this also be put on the web site?

  Thanks again.

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From baldrick at free.fr  Fri Jan  7 02:33:27 2011
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 07 Jan 2011 09:33:27 +0100
Subject: [LLVMdev] Erasing dead blocks
In-Reply-To: <AANLkTi=+JbNqtqTmLKizK+UeAKhZ=_OucaK+5m2+zFYy@mail.gmail.com>
References: <AANLkTi=+JbNqtqTmLKizK+UeAKhZ=_OucaK+5m2+zFYy@mail.gmail.com>
Message-ID: <4D26CFD7.4080504@free.fr>

Hi Gordan,

> I have a question regarding the IPSCCP class and the handling of dead blocks:
>
> The file lib/Transforms/Scalar/SCCP.cpp of llvm 2.8 from contains some
> code to deal with a dead block which could not be folded (line
> 1909ff). This happens when a user of this dead block is a branch or
> switch with an undef condition. The action taken than is to replace
> this terminator with an unconditional branch to the first successor of
> this undef branch/switch.
> I do not see how this ensures that the dead block is disconnected from
> the control flow graph. If the dead block is the first successor of
> the switch resp. branch the dead block will be still reachable after
> this code. Am I wrong here? Is there somewhere else code ensuring that
> the dead block is not the first successor of an undef branch/switch
> instruction?

I don't know much about SCCP, but I noticed that here a branch or switch on
undef causes SCCP to choose the *second* successor:

     // Check to see if we have a branch or switch on an undefined value.  If so
     // we force the branch to go one way or the other to make the successor
     // values live.  It doesn't really matter which way we force it.
     TerminatorInst *TI = BB->getTerminator();
     if (BranchInst *BI = dyn_cast<BranchInst>(TI)) {
       if (!BI->isConditional()) continue;
       if (!getValueState(BI->getCondition()).isUndefined())
         continue;

       // If the input to SCCP is actually branch on undef, fix the undef to
       // false.
       if (isa<UndefValue>(BI->getCondition())) {
         BI->setCondition(ConstantInt::getFalse(BI->getContext()));
         markEdgeExecutable(BB, TI->getSuccessor(1));
         return true;
       }
...

So in order to be consistent I would have expected the dead block erasing code
to also choose the second successor.  It looks like a bug to me.

Ciao, Duncan.

From chenwj at iis.sinica.edu.tw  Fri Jan  7 03:35:09 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Fri, 7 Jan 2011 17:35:09 +0800
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <AANLkTinhc-+bJMfAsnA0GK6vCq+wVtwSfgQ8HMCwqYYR@mail.gmail.com>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<AANLkTik7B486GR5fSQj5shyBN_-2Hds6aBho943u2FF=@mail.gmail.com>
	<20110106044736.GA19379@cs.nctu.edu.tw>
	<AANLkTinhc-+bJMfAsnA0GK6vCq+wVtwSfgQ8HMCwqYYR@mail.gmail.com>
Message-ID: <20110107093509.GA59376@cs.nctu.edu.tw>

Hi, Anton

  Finally, I built LLVM-GCC 2.8 on a Linux/PS3 machine.

  I just put my configuration options here,

---------------------------------------------------------------------------
../llvm-gcc-4.2-2.8.source/configure -prefix=/tmp/chenwj/install
--disable-bootstrap --disable-libmudflap --disable-multilib
--disable-libgomp --program-prefix=llvm-
--enable-llvm=/tmp/chenwj/install --enable-languages=c,c++
---------------------------------------------------------------------------

  Hope this help others. :)

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From chenwj at iis.sinica.edu.tw  Fri Jan  7 03:39:09 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Fri, 7 Jan 2011 17:39:09 +0800
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <20110107093509.GA59376@cs.nctu.edu.tw>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<AANLkTik7B486GR5fSQj5shyBN_-2Hds6aBho943u2FF=@mail.gmail.com>
	<20110106044736.GA19379@cs.nctu.edu.tw>
	<AANLkTinhc-+bJMfAsnA0GK6vCq+wVtwSfgQ8HMCwqYYR@mail.gmail.com>
	<20110107093509.GA59376@cs.nctu.edu.tw>
Message-ID: <20110107093909.GB59376@cs.nctu.edu.tw>

  P.S.
    I repeat your trick again when it failed at compiling the gomp library,
i.e., add "--disable-libgomp" option.
 
Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From baldrick at free.fr  Fri Jan  7 03:40:32 2011
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 07 Jan 2011 10:40:32 +0100
Subject: [LLVMdev] Building dragonegg.so failed
In-Reply-To: <20110107082641.GA58364@cs.nctu.edu.tw>
References: <20110106060506.GA19464@cs.nctu.edu.tw> <4D25F97F.1080305@free.fr>
	<20110107011701.GA21492@cs.nctu.edu.tw> <4D26C466.5060806@free.fr>
	<20110107082641.GA58364@cs.nctu.edu.tw>
Message-ID: <4D26DF90.3060902@free.fr>

Hi chenwj,

>    Thanks. I wonder if this hint can be put on http://dragonegg.llvm.org/.
> And one comment, building dragonegg.so needs a gcc built with
> "--enable-lto" option. Could this also be put on the web site?

I have done this.  The README already contained this info.

Ciao, Duncan.

From jocke at tbricks.com  Fri Jan  7 04:05:08 2011
From: jocke at tbricks.com (Joakim Johansson)
Date: Fri, 7 Jan 2011 11:05:08 +0100
Subject: [LLVMdev] [PATCH] compiler-rt patch for clean build on Solaris 10 /
	x86
Message-ID: <C13CDD66-3FD9-4F48-8FF8-23635E0DC81D@tbricks.com>

Hi,

Attached is small patch (based of r122998 of compiler-rt), required for clean builds on Solaris 10 / x86 using clang 2.8.

Please consider it for inclusion.

Cheers,

Joakim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: solaris_stdint.patch
Type: application/octet-stream
Size: 457 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110107/f2276c85/attachment.obj 
-------------- next part --------------


------------
-bash-3.00$ svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
...
-bash-3.00$ mkdir build
-bash-3.00$ cd build
-bash-3.00$ cmake -DCMAKE_C_FLAGS=-m64 -DCMAKE_CXX_FLAGS=-m64 ../compiler-rt/
-- The C compiler identification is Clang
-- Check for working C compiler: /home/jocke/llvm/build/Release/bin/clang
-- Check for working C compiler: /home/jocke/llvm/build/Release/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Looking for sys/byteorder.h
-- Looking for sys/byteorder.h - not found
-- Looking for AvailabilityMacros.h
-- Looking for AvailabilityMacros.h - not found
-- Looking for TargetConditionals.h
-- Looking for TargetConditionals.h - not found
-- Looking for libkern/OSAtomic.h
-- Looking for libkern/OSAtomic.h - not found
-- Looking for sysconf
-- Looking for sysconf - found
-- Looking for OSAtomicCompareAndSwapInt
-- Looking for OSAtomicCompareAndSwapInt - not found.
-- Looking for OSAtomicCompareAndSwapLong
-- Looking for OSAtomicCompareAndSwapLong - not found.
-- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT
-- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT - Success
-- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG
-- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG - Success
CMake Warning (dev) at test/CMakeLists.txt:8 (TARGET_LINK_LIBRARIES):
  Cannot specify link libraries for target "CompilerRT" which is not built by
  this project.

  CMake does not support this but it used to work accidentally and is being
  allowed for compatibility.

  Policy CMP0016 is not set: target_link_libraries() reports error if only
  argument is not a target.  Run "cmake --help-policy CMP0016" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done
-- Generating done
-- Build files have been written to: /home/jocke/llvm/clean/build
-bash-3.00$ 
-bash-3.00$ gmake
Scanning dependencies of target BlocksRuntime
[  0%] Building C object BlocksRuntime/CMakeFiles/BlocksRuntime.dir/runtime.c.o
[  1%] Building C object BlocksRuntime/CMakeFiles/BlocksRuntime.dir/data.c.o
Linking C shared library libBlocksRuntime.so
[  1%] Built target BlocksRuntime
Scanning dependencies of target CompilerRT-Generic
[  2%] Building C object lib/CMakeFiles/CompilerRT-Generic.dir/absvdi2.c.o
In file included from /home/jocke/llvm/clean/compiler-rt/lib/absvdi2.c:15:
In file included from /home/jocke/llvm/clean/compiler-rt/lib/int_lib.h:23:
In file included from /home/jocke/llvm/clean/compiler-rt/lib/endianness.h:25:
/usr/include/sys/byteorder.h:60:9: error: unknown type name 'uint16_t'
typedef uint16_t in_port_t;
        ^
/usr/include/sys/byteorder.h:65:9: error: unknown type name 'uint32_t'
typedef uint32_t in_addr_t;
        ^
/usr/include/sys/byteorder.h:69:8: error: unknown type name 'uint32_t'
extern  uint32_t htonl(uint32_t);
        ^
/usr/include/sys/byteorder.h:69:23: error: a parameter list without types is only allowed in a function definition
extern  uint32_t htonl(uint32_t);
                       ^
/usr/include/sys/byteorder.h:70:8: error: unknown type name 'uint16_t'
extern  uint16_t htons(uint16_t);
        ^
/usr/include/sys/byteorder.h:70:23: error: a parameter list without types is only allowed in a function definition
extern  uint16_t htons(uint16_t);
                       ^
/usr/include/sys/byteorder.h:71:9: error: unknown type name 'uint32_t'
extern  uint32_t ntohl(uint32_t);
        ^
/usr/include/sys/byteorder.h:71:24: error: a parameter list without types is only allowed in a function definition
extern  uint32_t ntohl(uint32_t);
                       ^
/usr/include/sys/byteorder.h:72:8: error: unknown type name 'uint16_t'
extern  uint16_t ntohs(uint16_t);
        ^
/usr/include/sys/byteorder.h:72:23: error: a parameter list without types is only allowed in a function definition
extern  uint16_t ntohs(uint16_t);
                       ^
10 errors generated.
gmake[2]: *** [lib/CMakeFiles/CompilerRT-Generic.dir/absvdi2.c.o] Error 1
gmake[1]: *** [lib/CMakeFiles/CompilerRT-Generic.dir/all] Error 2
gmake: *** [all] Error 2
-bash-3.00$ 
octo.tbricks.com:llvm/clean/compiler-rt> patch -p0 < ../solaris_stdint.patch
patching file lib/int_lib.h
octo.tbricks.com:llvm/clean/compiler-rt> 
-bash-3.00$ gmake
[  1%] Built target BlocksRuntime
[  2%] Building C object lib/CMakeFiles/CompilerRT-Generic.dir/absvdi2.c.o
[  2%] Building C object lib/CMakeFiles/CompilerRT-Generic.dir/absvsi2.c.o
.
.
.
[100%] Building C object test/CMakeFiles/umodti3_test.dir/Unit/umodti3_test.c.o
Linking C executable umodti3_test
[100%] Built target umodti3_test
-bash-3.00$ file BlocksRuntime/libBlocksRuntime.so 
BlocksRuntime/libBlocksRuntime.so:      ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not stripped, no debugging information available
-bash-3.00$ 



From kalle.raiskila at nokia.com  Fri Jan  7 04:11:55 2011
From: kalle.raiskila at nokia.com (Kalle Raiskila)
Date: Fri, 07 Jan 2011 12:11:55 +0200
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <95189AD2-6430-4450-B1EB-E90B1F640386@apple.com>
References: <20101230015403.GA4747@cs.nctu.edu.tw>	<20110105072351.GA76853@cs.nctu.edu.tw>	<1294235328.1880.16.camel@LLVMbuilder.research.nokia.com>	<20110106084750.acf6ca54.mle+cl@mega-nerd.com>
	<95189AD2-6430-4450-B1EB-E90B1F640386@apple.com>
Message-ID: <4D26E6EB.6080008@nokia.com>

dalej skrev:
> On Jan 5, 2011, at 1:47 PM, Erik de Castro Lopo wrote:
> 
>> Kalle Raiskila wrote:
>>
>>> And I probably should file a bug. Is ppc32 still maintained?
>> I have no concrete knowledge of this, but llvm compiles
>> and passes all tests on ppc32, so it seems to be maintained.
>> About once a week I grab the latest SVN head and check this.
> 
> It is run by one of the automatic testers, and introduced bugs that break the tester get fixed.    Nobody is doing new work on it.

Strange. Perhaps it is my setup then - I don't work with the PPC parts anyways.

The system assembler is

	as --version
	GNU assembler (GNU Binutils for Ubuntu) 2.18.93.20081009
	...
	This assembler was configured for a target of `powerpc-linux-gnu'.

perhaps it is too old? It chokes on the assembly lines:
	lis 3, ha16(.L.str)
	la 3, lo16(.L.str)(3)



That assembly is generated out of a trivial hello world:

@.str = private constant [14 x i8] c"Hello, world\0A\00"
define i32 @main() nounwind {
entry:
   %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([14 x i8]* 
@.str, i32 0, i32 0))
   ret i32 42
}
declare i32 @printf(i8*, ...)

That .ll file works on SPU at least - probably also on x86 ;)

kalle

From baldrick at free.fr  Fri Jan  7 09:31:06 2011
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 07 Jan 2011 16:31:06 +0100
Subject: [LLVMdev] the optional function return attribute and the llvm-c
 bindings
In-Reply-To: <6814972D-D838-41EB-A47C-F9177416747E@conjury.org>
References: <3931E5FD-4374-492E-9522-1C5CA03667E5@conjury.org>	<4D106898.9030401@free.fr>	<9F605850-2255-4EBB-8DD1-649620FD69E6@conjury.org>
	<6814972D-D838-41EB-A47C-F9177416747E@conjury.org>
Message-ID: <4D2731BA.1030408@free.fr>

Hi James,

> On Dec 21, 2010, at 11:33, james woodyatt wrote:
>> On Dec 21, 2010, at 00:43, Duncan Sands wrote:
>>>
>>> IIRC the function return value is considered to be the parameter with index 0.
>>> The function itself is considered to be the parameter with index ~0U.
>>
>> Yes, that's what the documentation seems to say is the proper mode for indexing the return parameter, but when I set an attribute on the parameter with index zero, it gets applied to the first function argument and not the return parameter.
>>
>> I believe the reason for this to be that LLVMGetParams() [and its cognates] all use Function::arg_iterator, which begins with the first function *argument* parameter and not the return parameter.  The index argument to LLVMGetParams() is actually incremented by one when it's mapped to the index used for the Function::AttributeList member.  There are separate functions for the function attributes, which are at index ~0UL, but no similar functions for handling the function return parameter attribute at index zero.
>>
>> Is this intentional?  What is the correct way to get and set a function return parameter attribute with C-language binding to the LLVM core?
>
> I'm sorry to be a pest about this question, but it's a thorn in my paw.
>
> Assuming I'm right and there currently isn't a way to get at the return parameter attribute from the C-language bindings, would a patch to add the facility be welcomed?  If so, then it would be nice to have some guidance on naming issues.

a patch would be welcome.  I suggest you copy the naming style used in the
existing bindings, and base names on the C++ API names when possible.

> I propose to add the following declarations to<llvm-c/Core.h>  along with corresponding definitions in $LLVM/lib/VMCore/Core.cpp:
>
>    extern void LLVMAddReturnAttr(LLVMValueRef Fn, LLVMAttribute PA);
>    extern void LLVMRemoveReturnAttr(LLVMValueRef Fn, LLVMAttribute PA);

Looks good to me.

> I also propose to add the corresponding OCaml functions to the "Operations on functions" section of the Llvm module in the OCaml bindings too, of course:
>
>    (** [add_return_attr f a] adds the return parameter
>        attribute [a] to the return type of the function [f].
>    *)
>    val add_return_attr: llvalue ->  Attribute.t ->  unit
>
>    (** [remove_return_attr f a] removes the return parameter
>        attribute [a] from the return type of the function [f].
>    *)
>    val remove_return_attr: llvalue ->  Attribute.t ->  unit

I don't know anything about OCaml, but except for that it looks OK!

> I also propose to update the ocamldoc text for the following OCaml functions to reflect that the list traversed is the function *argument* list and not the parameter list:
>
>    Llvm.param
>    Llvm.params
>    Llvm.param_begin
>    Llvm.param_end
>    Llvm.param_succ
>    Llvm.param_pred
>    Llvm.iter_params
>    Llvm.rev_iter_params
>    Llvm.fold_left_params
>    Llvm.fold_right_params
>
> Finally, I think the ocamldoc texts for Llvm.add_function_attr and Llvm.remove_function_attr are wrong.  They actually add and remove function attributes, not return parameter attributes, which are no longer the same thing.  I propose to fix those too.
>
> If these contributions would be welcomed, then I'd like to write and submit two patches: one with the above changes to the VMCore, and another with the above changes to the OCaml bindings.  I could get started soon and probably have them ready by the end of the week.

Looking forward to seeing the patch.

Ciao, Duncan.

From dag at cray.com  Fri Jan  7 11:26:43 2011
From: dag at cray.com (David Greene)
Date: Fri, 07 Jan 2011 11:26:43 -0600
Subject: [LLVMdev] TableGen Operator Names
Message-ID: <nngpqs8bp64.fsf@royale.us.cray.com>

I just submitted a change to TableGen to make the lisp-like operator
names more readable (as suggested by Gabor a very long time ago).

I would also like to change the way operators are invoked.  As I keep
adding more functionality, the bang invocation syntax is making things
hard to read.  For example:

!if(!empty(arg),then,else)

Does this mean "if empty," "if not empty" or "not if not empty?"  It's
the first but that's less than obvious.

Would anyone object if I changed the syntax from !operator to &operator?
This is at least consistent with Perl, which is not my favorite language
but is familiar to a lot of people.  Some viable options are:

!operator    (Keep as-is and deal with logical operator confusion)
&operator    (Perl-like, no address-of concept in TableGen so less confusion)
@operator    (Not a common operator)
#operator    (Looks too much like a comment or preprocessor directive)
$operator    (Looks too much like a variable)
%operator    (Or +,-,/,^,*: could be confused with arithmetic, but not likely)
~operator    (Could be confused with logical not)
()operator   (Redundant with parameter parens)
\operator    ("Escape" into metacode?)

There are plenty of other spellings, I've just tried to present my
thoughts on a few.

At the same time I would try to add syntax-highlighting support for
operators so they stand out better when reading .td files.

Is this a good idea?  If so, does anyone have a strong syntax
preference?

                               -Dave

From dpatel at apple.com  Fri Jan  7 11:30:26 2011
From: dpatel at apple.com (Devang Patel)
Date: Fri, 7 Jan 2011 09:30:26 -0800
Subject: [LLVMdev] DWARF version
In-Reply-To: <7EBA7A880CFD5440A1AA2C987DFACB2D10781779A9@HQMAIL04.nvidia.com>
References: <7EBA7A880CFD5440A1AA2C987DFACB2D10781779A9@HQMAIL04.nvidia.com>
Message-ID: <BB0A890E-9D22-4F30-8CE1-38A504381ADB@apple.com>

LLVM follows DWARF3 spec. I think, DWARF_VERSION is set to 2 for historical reasons/debugger needs.
-
Devang
On Jan 6, 2011, at 4:17 PM, Yuan Lin wrote:

> Hi, I have a newbie question regarding debugging support in llvm.
>  
> Is llvm generating DWARF2 or DWARF3? The comments in the trunk source code refer to the DWARF 3 spec, but DWARF_VERSION is set to 2 in Support/Dwarf.h.
>  
> What am I missing? Thanks.
>  
> -- Yuan
>  
>  
>  
> This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110107/f12ef778/attachment.html 

From dpatel at apple.com  Fri Jan  7 11:30:53 2011
From: dpatel at apple.com (Devang Patel)
Date: Fri, 7 Jan 2011 09:30:53 -0800
Subject: [LLVMdev] Questions about debug info in LLVM 2.8
In-Reply-To: <1294359668.6207.1.camel@easteregg>
References: <4D23E658.6010203@oracle.com>
	<2E72D242-582C-4FE6-9861-2E62BFE9E6FF@apple.com>
	<1294359668.6207.1.camel@easteregg>
Message-ID: <5806CE09-3689-4622-ADDB-B2B954B4F1C4@apple.com>


On Jan 6, 2011, at 4:21 PM, Jacob Zimmermann wrote:

> 
> On Thu, 2011-01-06 at 11:13 -0800, Devang Patel wrote:
>> 
>> On Jan 4, 2011, at 7:32 PM, Jacob Zimmermann wrote:
>> 
>> > Hi,
>> > 
>> > I'm currently porting some code from LLVM 2.6 to 2.8 and need to be able
>> > to extract the debug info produced by LLVM-GCC and stored in the
>> > compiled .bc file. However I admit I'm slightly confused about how
>> > exactly to do that, the documentation doesn't seem to be very clear
>> > about this, it mainly describes how to *generate* debug info.
>> > Specifically I'm wondering about the following points:
>> > 
>> > 1) It seems that the various DIDescriptors contain the information I'd
>> > need, but they can only be constructed from a MDNode How do I retrieve
>> > the MDNode at the first place? Does MDNode::get() actually retrieve all
>> > the debug metadata from Module, or does it merely initialise a fresh MDNode?
>> > 
>> > 2) DebugLoc has a getAsMDNode() method, but apparently it's only
>> > available for Instructions?
>> > 
>> > 3) How can I retrieve a DIType instance? I can't find a way to obtain a
>> > MDNode for a Type... ?
>> > 
>> > Many thanks if somebody can shed some light on this.
>> 
>> See DebugInfoFinder interface in Analysis/DebugInfo.h
> 
> Thanks Devang, however this doesn't seem to let me access local variables, do you know how I can get at them?

Scan llvm.dbg.declare intrinsic for arguments and local variables.

-
Devang
> 
> Thanks
> Jacob
> 



From dalej at apple.com  Fri Jan  7 12:54:21 2011
From: dalej at apple.com (Dale Johannesen)
Date: Fri, 7 Jan 2011 10:54:21 -0800
Subject: [LLVMdev] Building LLVM-GCC on Linux/PowerPC failed
In-Reply-To: <4D26E6EB.6080008@nokia.com>
References: <20101230015403.GA4747@cs.nctu.edu.tw>
	<20110105072351.GA76853@cs.nctu.edu.tw>
	<1294235328.1880.16.camel@LLVMbuilder.research.nokia.com>
	<20110106084750.acf6ca54.mle+cl@mega-nerd.com>
	<95189AD2-6430-4450-B1EB-E90B1F640386@apple.com>
	<4D26E6EB.6080008@nokia.com>
Message-ID: <3646D9B1-4544-4A28-9330-448C4A8282F7@apple.com>


On Jan 7, 2011, at 2:11 AMPST, Kalle Raiskila wrote:

> dalej skrev:
>> On Jan 5, 2011, at 1:47 PM, Erik de Castro Lopo wrote:
>>> Kalle Raiskila wrote:
>>> 
>>>> And I probably should file a bug. Is ppc32 still maintained?
>>> I have no concrete knowledge of this, but llvm compiles
>>> and passes all tests on ppc32, so it seems to be maintained.
>>> About once a week I grab the latest SVN head and check this.
>> It is run by one of the automatic testers, and introduced bugs that break the tester get fixed.    Nobody is doing new work on it.
> 
> Strange. Perhaps it is my setup then - I don't work with the PPC parts anyways.

As Anton clarified (and I should have), I was talking about Darwin only.  That tester is currently green.  I don't think anybody is testing or maintaining other OSs.

> The system assembler is
> 
> 	as --version
> 	GNU assembler (GNU Binutils for Ubuntu) 2.18.93.20081009
> 	...
> 	This assembler was configured for a target of `powerpc-linux-gnu'.
> 
> perhaps it is too old? It chokes on the assembly lines:
> 	lis 3, ha16(.L.str)
> 	la 3, lo16(.L.str)(3)
> 
> 
> 
> That assembly is generated out of a trivial hello world:
> 
> @.str = private constant [14 x i8] c"Hello, world\0A\00"
> define i32 @main() nounwind {
> entry:
>  %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([14 x i8]* @.str, i32 0, i32 0))
>  ret i32 42
> }
> declare i32 @printf(i8*, ...)
> 
> That .ll file works on SPU at least - probably also on x86 ;)
> 
> kalle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110107/963471dc/attachment.html 

From evan.cheng at apple.com  Fri Jan  7 13:01:38 2011
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 7 Jan 2011 11:01:38 -0800
Subject: [LLVMdev] Announcement: Summer 2011 Internship in Apple's LLVM team
Message-ID: <11D795F9-EDEA-4DC9-93F5-9F529B80297E@apple.com>

Hi all,

The Apple compiler code generator team is looking for an exceptional intern for summer 2011 (3+ months from early May). This is a paid internship position in the Cupertino, CA area. This is a great opportunity to work with many of the leaders of the LLVM community.

The ideal candidate is someone who have experience working on the LLVM optimizer and / or code generator. We strongly prefer candidates who have contributed code to the LLVM public repository.

If you are interested in this position, please send me your resume / CV and relevant information to evan.cheng at apple.com.

Evan

From andrew at sidefx.com  Fri Jan  7 13:08:12 2011
From: andrew at sidefx.com (Andrew Clinton)
Date: Fri, 07 Jan 2011 14:08:12 -0500
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <1701B32D-079E-45F7-B904-719296C57D6F@apple.com>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
	<6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
	<34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
	<1701B32D-079E-45F7-B904-719296C57D6F@apple.com>
Message-ID: <4D27649C.5040506@sidefx.com>

On 01/07/2011 02:07 AM, Chris Lattner wrote:
>
> Unless your goal is to merge this work onto LLVM mainline, the best thing to do is a local hack in your tree.
>
> -Chris

Yes, I will create a patch for my tree to increase 
FirstVirtualRegister.  Would this be a good change to include in 2.9?

From kledzik at apple.com  Fri Jan  7 13:13:17 2011
From: kledzik at apple.com (Nick Kledzik)
Date: Fri, 7 Jan 2011 11:13:17 -0800
Subject: [LLVMdev] [PATCH] compiler-rt patch for clean build on Solaris
	10 /	x86
In-Reply-To: <C13CDD66-3FD9-4F48-8FF8-23635E0DC81D@tbricks.com>
References: <C13CDD66-3FD9-4F48-8FF8-23635E0DC81D@tbricks.com>
Message-ID: <71935ACD-B51C-4219-928B-15A7C063B25B@apple.com>

Applied r123006, thanks!

-Nick

On Jan 7, 2011, at 2:05 AM, Joakim Johansson wrote:
> Hi,
> 
> Attached is small patch (based of r122998 of compiler-rt), required for clean builds on Solaris 10 / x86 using clang 2.8.
> 
> Please consider it for inclusion.
> 
> Cheers,
> 
> Joakim
> 
> <solaris_stdint.patch>
> 
> ------------
> -bash-3.00$ svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
> ...
> -bash-3.00$ mkdir build
> -bash-3.00$ cd build
> -bash-3.00$ cmake -DCMAKE_C_FLAGS=-m64 -DCMAKE_CXX_FLAGS=-m64 ../compiler-rt/
> -- The C compiler identification is Clang
> -- Check for working C compiler: /home/jocke/llvm/build/Release/bin/clang
> -- Check for working C compiler: /home/jocke/llvm/build/Release/bin/clang -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Looking for sys/byteorder.h
> -- Looking for sys/byteorder.h - not found
> -- Looking for AvailabilityMacros.h
> -- Looking for AvailabilityMacros.h - not found
> -- Looking for TargetConditionals.h
> -- Looking for TargetConditionals.h - not found
> -- Looking for libkern/OSAtomic.h
> -- Looking for libkern/OSAtomic.h - not found
> -- Looking for sysconf
> -- Looking for sysconf - found
> -- Looking for OSAtomicCompareAndSwapInt
> -- Looking for OSAtomicCompareAndSwapInt - not found.
> -- Looking for OSAtomicCompareAndSwapLong
> -- Looking for OSAtomicCompareAndSwapLong - not found.
> -- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT
> -- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT - Success
> -- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG
> -- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG - Success
> CMake Warning (dev) at test/CMakeLists.txt:8 (TARGET_LINK_LIBRARIES):
>  Cannot specify link libraries for target "CompilerRT" which is not built by
>  this project.
> 
>  CMake does not support this but it used to work accidentally and is being
>  allowed for compatibility.
> 
>  Policy CMP0016 is not set: target_link_libraries() reports error if only
>  argument is not a target.  Run "cmake --help-policy CMP0016" for policy
>  details.  Use the cmake_policy command to set the policy and suppress this
>  warning.
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/jocke/llvm/clean/build
> -bash-3.00$ 
> -bash-3.00$ gmake
> Scanning dependencies of target BlocksRuntime
> [  0%] Building C object BlocksRuntime/CMakeFiles/BlocksRuntime.dir/runtime.c.o
> [  1%] Building C object BlocksRuntime/CMakeFiles/BlocksRuntime.dir/data.c.o
> Linking C shared library libBlocksRuntime.so
> [  1%] Built target BlocksRuntime
> Scanning dependencies of target CompilerRT-Generic
> [  2%] Building C object lib/CMakeFiles/CompilerRT-Generic.dir/absvdi2.c.o
> In file included from /home/jocke/llvm/clean/compiler-rt/lib/absvdi2.c:15:
> In file included from /home/jocke/llvm/clean/compiler-rt/lib/int_lib.h:23:
> In file included from /home/jocke/llvm/clean/compiler-rt/lib/endianness.h:25:
> /usr/include/sys/byteorder.h:60:9: error: unknown type name 'uint16_t'
> typedef uint16_t in_port_t;
>        ^
> /usr/include/sys/byteorder.h:65:9: error: unknown type name 'uint32_t'
> typedef uint32_t in_addr_t;
>        ^
> /usr/include/sys/byteorder.h:69:8: error: unknown type name 'uint32_t'
> extern  uint32_t htonl(uint32_t);
>        ^
> /usr/include/sys/byteorder.h:69:23: error: a parameter list without types is only allowed in a function definition
> extern  uint32_t htonl(uint32_t);
>                       ^
> /usr/include/sys/byteorder.h:70:8: error: unknown type name 'uint16_t'
> extern  uint16_t htons(uint16_t);
>        ^
> /usr/include/sys/byteorder.h:70:23: error: a parameter list without types is only allowed in a function definition
> extern  uint16_t htons(uint16_t);
>                       ^
> /usr/include/sys/byteorder.h:71:9: error: unknown type name 'uint32_t'
> extern  uint32_t ntohl(uint32_t);
>        ^
> /usr/include/sys/byteorder.h:71:24: error: a parameter list without types is only allowed in a function definition
> extern  uint32_t ntohl(uint32_t);
>                       ^
> /usr/include/sys/byteorder.h:72:8: error: unknown type name 'uint16_t'
> extern  uint16_t ntohs(uint16_t);
>        ^
> /usr/include/sys/byteorder.h:72:23: error: a parameter list without types is only allowed in a function definition
> extern  uint16_t ntohs(uint16_t);
>                       ^
> 10 errors generated.
> gmake[2]: *** [lib/CMakeFiles/CompilerRT-Generic.dir/absvdi2.c.o] Error 1
> gmake[1]: *** [lib/CMakeFiles/CompilerRT-Generic.dir/all] Error 2
> gmake: *** [all] Error 2
> -bash-3.00$ 
> octo.tbricks.com:llvm/clean/compiler-rt> patch -p0 < ../solaris_stdint.patch
> patching file lib/int_lib.h
> octo.tbricks.com:llvm/clean/compiler-rt> 
> -bash-3.00$ gmake
> [  1%] Built target BlocksRuntime
> [  2%] Building C object lib/CMakeFiles/CompilerRT-Generic.dir/absvdi2.c.o
> [  2%] Building C object lib/CMakeFiles/CompilerRT-Generic.dir/absvsi2.c.o
> .
> .
> .
> [100%] Building C object test/CMakeFiles/umodti3_test.dir/Unit/umodti3_test.c.o
> Linking C executable umodti3_test
> [100%] Built target umodti3_test
> -bash-3.00$ file BlocksRuntime/libBlocksRuntime.so 
> BlocksRuntime/libBlocksRuntime.so:      ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not stripped, no debugging information available
> -bash-3.00$ 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From dalej at apple.com  Fri Jan  7 13:25:46 2011
From: dalej at apple.com (Dale Johannesen)
Date: Fri, 7 Jan 2011 11:25:46 -0800
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <4D27649C.5040506@sidefx.com>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
	<6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
	<34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
	<1701B32D-079E-45F7-B904-719296C57D6F@apple.com>
	<4D27649C.5040506@sidefx.com>
Message-ID: <699FE8C7-6849-4FA2-A3C8-779463133639@apple.com>

We might want to make physical registers negative and virtuals positive, or vice versa.   Then FirstVirtualRegister is 0 or 1, and we could get rid of those annoying subtractions of FirstVirtualRegister all over the virtual-register-handling passes.  Since 0 is used all over the place as "invalid register" it is probably best to leave this alone, let FirstVirtualRegister be 1, and simply ignore (i.e. treat as erroneous) the 0th element of anything keyed off FirstVirtualRegister.

On Jan 7, 2011, at 11:08 AMPST, Andrew Clinton wrote:

> On 01/07/2011 02:07 AM, Chris Lattner wrote:
>> 
>> Unless your goal is to merge this work onto LLVM mainline, the best thing to do is a local hack in your tree.
>> 
>> -Chris
> 
> Yes, I will create a patch for my tree to increase 
> FirstVirtualRegister.  Would this be a good change to include in 2.9?
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110107/d9f7bc34/attachment.html 

From clattner at apple.com  Fri Jan  7 13:59:19 2011
From: clattner at apple.com (Chris Lattner)
Date: Fri, 7 Jan 2011 11:59:19 -0800
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <4D27649C.5040506@sidefx.com>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
	<6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
	<34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
	<1701B32D-079E-45F7-B904-719296C57D6F@apple.com>
	<4D27649C.5040506@sidefx.com>
Message-ID: <232285BF-D318-4007-84BF-538A7D4E2229@apple.com>


On Jan 7, 2011, at 11:08 AM, Andrew Clinton wrote:

> On 01/07/2011 02:07 AM, Chris Lattner wrote:
>> 
>> Unless your goal is to merge this work onto LLVM mainline, the best thing to do is a local hack in your tree.
>> 
>> -Chris
> 
> Yes, I will create a patch for my tree to increase 
> FirstVirtualRegister.  Would this be a good change to include in 2.9?

I think it makes the most sense to discuss that when you're interested in merging the dependent work onto mainline.  Dales's idea of using positive/negative numbers makes sense to me.

-Chris



From venkatra at cs.wisc.edu  Fri Jan  7 14:36:26 2011
From: venkatra at cs.wisc.edu (Venkatraman Govindaraju)
Date: Fri, 7 Jan 2011 14:36:26 -0600
Subject: [LLVMdev] Unreachable executed with fast Regalloc and Sparc backend
Message-ID: <AANLkTi=7Oo2NPB3J=X0tTL+RiNTV=ichOHQZO-UQRLDO@mail.gmail.com>

Hello,

  When I run LLC with option "-O0 -march=sparc" on following testcase,
fast register allocator crashes with "UNREACHABLE executed" error. LLC
generates code successfully with other standard register allocators
available.


$ cat call.ll

define void @test() nounwind {
entry:
  %0 = tail call i32 (...)* @foo() nounwind
  tail call void (...)* @bar() nounwind
  ret void
}

declare i32 @foo(...)

declare void @bar(...)

$ llc -march=sparc -O0 call.ll
Instruction uses an allocated register
UNREACHABLE executed at
/scratch/venkatra/projects/llvm/src/llvm/lib/CodeGen/RegAllocFast.cpp:339!
...


Thanks,
Venkatraman

From lockalsash at gmail.com  Fri Jan  7 15:31:10 2011
From: lockalsash at gmail.com (Lockal)
Date: Sat, 8 Jan 2011 00:31:10 +0300
Subject: [LLVMdev] Problem returning structures by value from C
Message-ID: <AANLkTin6HZNk2fB2cbr3dqFGoa1Q4NLs-zRepZz71N6o@mail.gmail.com>

I have a simple structure in my program:

struct pair { double value; int32_t type; };

Also I have 2 functions, which are called from LLVM code:

extern "C" void dump(pair s) {
    unsigned char *p = reinterpret_cast<unsigned char *>(&s);
    printf("#dump, %02x%02x%02x%02x %02x%02x%02x%02x %02x%02x%02x%02x\n",
      p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9], p[10], p[11]);
}

extern "C" pair set() {
    pair ret = { 0, 3 };

    unsigned char *p = reinterpret_cast<unsigned char *>(&ret);
    printf("#set, %02x%02x%02x%02x %02x%02x%02x%02x %02x%02x%02x%02x\n",
      p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9], p[10], p[11]);

    return ret;
}

LLVM code contains the same structure definition and prototypes for functions:

%0 = type { double, i32 }
declare %0 @set()
declare void @dump(%0)


So the question is: why the structure data is smashed after this code?

%a = call %0 @set()
call void @dump(%0 %a)

Output:
#set, 00000000 00000000 03000000
#dump, 00000000 0000f8ff 88b93709

Is there any way to return structure from C to LLVM by value?

From dalej at apple.com  Fri Jan  7 15:38:24 2011
From: dalej at apple.com (Dale Johannesen)
Date: Fri, 7 Jan 2011 13:38:24 -0800
Subject: [LLVMdev] Problem returning structures by value from C
In-Reply-To: <AANLkTin6HZNk2fB2cbr3dqFGoa1Q4NLs-zRepZz71N6o@mail.gmail.com>
References: <AANLkTin6HZNk2fB2cbr3dqFGoa1Q4NLs-zRepZz71N6o@mail.gmail.com>
Message-ID: <466A5BBF-2E7E-4234-81D2-ECE40AF5D207@apple.com>


On Jan 7, 2011, at 1:31 PMPST, Lockal wrote:

> I have a simple structure in my program:
> 
> struct pair { double value; int32_t type; };
> 
> Also I have 2 functions, which are called from LLVM code:
> 
> extern "C" void dump(pair s) {
>    unsigned char *p = reinterpret_cast<unsigned char *>(&s);
>    printf("#dump, %02x%02x%02x%02x %02x%02x%02x%02x %02x%02x%02x%02x\n",
>      p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9], p[10], p[11]);
> }
> 
> extern "C" pair set() {
>    pair ret = { 0, 3 };
> 
>    unsigned char *p = reinterpret_cast<unsigned char *>(&ret);
>    printf("#set, %02x%02x%02x%02x %02x%02x%02x%02x %02x%02x%02x%02x\n",
>      p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8], p[9], p[10], p[11]);
> 
>    return ret;
> }
> 
> LLVM code contains the same structure definition and prototypes for functions:
> 
> %0 = type { double, i32 }
> declare %0 @set()
> declare void @dump(%0)
> 
> 
> So the question is: why the structure data is smashed after this code?
> 
> %a = call %0 @set()
> call void @dump(%0 %a)
> 
> Output:
> #set, 00000000 00000000 03000000
> #dump, 00000000 0000f8ff 88b93709
> 
> Is there any way to return structure from C to LLVM by value?

Yes, but what you're doing won't usually work.  You need to use IR that reflects the calling convention on your target.  sret is often the right thing to use; some targets are more complicated.  The best way to find out what you need is run llvm-gcc -S -emit-llvm on a testcase and look at the output file.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110107/93caaf91/attachment.html 

From peckw at wesleypeck.com  Fri Jan  7 18:56:49 2011
From: peckw at wesleypeck.com (Wesley Peck)
Date: Fri, 7 Jan 2011 18:56:49 -0600
Subject: [LLVMdev] Unreachable executed with fast Regalloc and Sparc
	backend
In-Reply-To: <AANLkTi=7Oo2NPB3J=X0tTL+RiNTV=ichOHQZO-UQRLDO@mail.gmail.com>
References: <AANLkTi=7Oo2NPB3J=X0tTL+RiNTV=ichOHQZO-UQRLDO@mail.gmail.com>
Message-ID: <79ABF6DF-BB99-45ED-9015-6B17847F40B8@wesleypeck.com>

On Jan 7, 2011, at 2:36 PM, Venkatraman Govindaraju wrote:
> When I run LLC with option "-O0 -march=sparc" on following testcase,
> fast register allocator crashes with "UNREACHABLE executed" error. LLC
> generates code successfully with other standard register allocators
> available.

I haven't investigated the Sparc backend specifically but...

My guess is this is related to this entry in SparcInstrInfo.td:
    let Uses = [O0, O1, O2, O3, O4, O5],
        hasDelaySlot = 1, isCall = 1,
        Defs = [O0, O1, O2, O3, O4, O5, O7, G1, G2, G3, G4, G5, G6, G7,
        D0, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15] in {
      def CALL : InstSP<(outs), (ins calltarget:$dst),
                        "call $dst", []> {
        bits<30> disp;
        let op = 1;
        let Inst{29-0} = disp;
      }

The Uses=[O0,O1,O2,O3,O4,O5] is causing this crash (and similar crashes in the PQBP and Greedy allocators if I remember right). I fixed this in the MicroBlaze backend by remodeling the call instructions to be variadic like other backends. See the MBlazeInstrInfo.td changes in this commit:
http://www.llvm.org/viewvc/llvm-project?view=rev&revision=121994

NOTE: In the commit R1 is the dedicated stack register on the MicroBlaze architecture.

--
Wesley Peck
University of Kansas
SLDG Laboratory



From chenwj at iis.sinica.edu.tw  Fri Jan  7 22:23:15 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Sat, 8 Jan 2011 12:23:15 +0800
Subject: [LLVMdev]  DragonEgg on FreeBSD
Message-ID: <20110108042315.GA3945@cs.nctu.edu.tw>

Hi, folks

  I have made DragonEgg supports FreeBSD 8.1. May someone like
to a look? :)

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From nowar100 at gmail.com  Sat Jan  8 00:16:32 2011
From: nowar100 at gmail.com (=?Big5?B?qFq/qyAoV2VuLUhhbik=?=)
Date: Sat, 8 Jan 2011 14:16:32 +0800
Subject: [LLVMdev] Build a static-linked executable using llvm
Message-ID: <AANLkTi=pJ_odNFZGhk-6p=+xWdpt1Nd2v9nLx1xvqGzy@mail.gmail.com>

Hello all,

I wanna build a static linked executable using llvm. But I failed.
My question is Can we use -static using llvm?

Thanks for any response.

Below is details
========
First I use

  $ clang++ test.cc `llvm-config --cxxflags --ldflags --libs`

I works as usual.  But if I use

  $ clang++ test.cc `llvm-config --cxxflags --ldflags --libs` -static

It yells lots of undefined reference, like this

/usr/lib/gcc/x86_64-linux-gnu/4.4.5/libgcc_eh.a(unwind-dw2-fde-glibc.o): In
function `__deregister_frame_info_bases':
(.text+0x1a16): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/libgcc_eh.a(unwind-dw2-fde-glibc.o): In
function `__register_frame_info_bases':
(.text+0x61): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/libgcc_eh.a(unwind-dw2-fde-glibc.o): In
function `__register_frame_info_table_bases':
(.text+0xfa): undefined reference to `pthread_mutex_unlock'
collect2: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to
see invocation)

But in directory <llvm>/lib, I see many libxxx.a.
I think they just have lots of xxx.o archive.
Why cannot these xxx.o build with -static?

Thank you.

-- 
Best regards,
Wen-Han (Nowar)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110108/e100d6d8/attachment.html 

From 6yearold at gmail.com  Sat Jan  8 02:18:07 2011
From: 6yearold at gmail.com (arrowdodger)
Date: Sat, 8 Jan 2011 11:18:07 +0300
Subject: [LLVMdev] Build a static-linked executable using llvm
In-Reply-To: <AANLkTi=pJ_odNFZGhk-6p=+xWdpt1Nd2v9nLx1xvqGzy@mail.gmail.com>
References: <AANLkTi=pJ_odNFZGhk-6p=+xWdpt1Nd2v9nLx1xvqGzy@mail.gmail.com>
Message-ID: <AANLkTi=Aon-3Pqg2cQfHJsEodmkOz8F8VX5ZGMYzEqMp@mail.gmail.com>

You are missing references for pthread. Try to add -pthread to build line.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110108/90c573ca/attachment.html 

From nowar100 at gmail.com  Sat Jan  8 03:11:15 2011
From: nowar100 at gmail.com (=?Big5?B?qFq/qyAoV2VuLUhhbik=?=)
Date: Sat, 8 Jan 2011 17:11:15 +0800
Subject: [LLVMdev] Build a static-linked executable using llvm
In-Reply-To: <AANLkTi=Aon-3Pqg2cQfHJsEodmkOz8F8VX5ZGMYzEqMp@mail.gmail.com>
References: <AANLkTi=pJ_odNFZGhk-6p=+xWdpt1Nd2v9nLx1xvqGzy@mail.gmail.com>
	<AANLkTi=Aon-3Pqg2cQfHJsEodmkOz8F8VX5ZGMYzEqMp@mail.gmail.com>
Message-ID: <AANLkTinyGCZ5h9quYoTaPpoZqgvVKY4uaeWeTUwqjEGo@mail.gmail.com>

Thank you very much!
I use -pthread -ldl and succeed!

2011/1/8 arrowdodger <6yearold at gmail.com>

> You are missing references for pthread. Try to add -pthread to build line.
>



-- 
Best regards,
Wen-Han (Nowar)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110108/8c936e23/attachment.html 

From baldrick at free.fr  Sat Jan  8 07:40:34 2011
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 08 Jan 2011 14:40:34 +0100
Subject: [LLVMdev] DragonEgg on FreeBSD
In-Reply-To: <20110108042315.GA3945@cs.nctu.edu.tw>
References: <20110108042315.GA3945@cs.nctu.edu.tw>
Message-ID: <4D286952.4040107@free.fr>

Hi chenwj,

>    I have made DragonEgg supports FreeBSD 8.1. May someone like
> to a look? :)

great!  Does it work ok?  If you had to make any changes to dragonegg, please
send patches to the mailing list.  If there are some tricks needed to get it
to build, please explain what you had to do and these can be mentioned in the
dragonegg README and on the web-site.

Ciao, Duncan.

From bijoy123_8 at yahoo.com  Sat Jan  8 10:04:53 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Sat, 8 Jan 2011 08:04:53 -0800 (PST)
Subject: [LLVMdev] LLVM-GCC build failed
Message-ID: <871319.76118.qm@web121705.mail.ne1.yahoo.com>











Hi
?
?? I am using LLVM and LLVM-GCC from SVN (version number: 122880). And I am using arm-2009q1-176-arm-none-linux-gnueabi-i686-mingw32.tar.bz2 or arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2. I tried the automated scripts (create-snapshots.sh and build-install-linux.sh) that?are in the LLVM repository for building crosstoll for ARM (http://llvm.org/svn/llvm-project/llvm/trunk/utils/crosstool/) but get the following error for building llvm-gcc (llvm built successfully):

?
When I use arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2: my build fails by the following error:
?
/usr/local/crosstool/codesourcery/arm-2009q1/bin/arm-none-linux-gnueabi-gcc: cannot
?execute binary file
?
make[2]: *** [crtbegin.o] Error 1
?
When I use arm-2009q1-176-arm-none-linux-gnueabi-i686-mingw32.tar.bz2, I get the following error:
?
Assembler messages:^M
Error: can't open /cygdrive/d/DOCUME~2/AZIM/LOCALS~1/Temp/cc19Hfjy.s for reading
: No such file or directory^M
make[2]: *** [crtbegin.o] Error 1
?
Can anyone please tell me why the error?
?
Thanks,
Akramul


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110108/a6255de6/attachment.html 

From pichet2000 at gmail.com  Sat Jan  8 10:27:51 2011
From: pichet2000 at gmail.com (Francois Pichet)
Date: Sat, 8 Jan 2011 11:27:51 -0500
Subject: [LLVMdev] make check on Darwin - some failed tests.
Message-ID: <AANLkTinNnDd-mQbD3C984_aFTBwfA-B+qGwGeS-b=tNz@mail.gmail.com>

Hi,

I started playing with llvm on Darwin.
When I do a "make check" from the llvm root, I am getting these failed tests:
Failing Tests (13):
?? ?LLVM :: FrontendC++/2010-04-30-OptimizedMethod-Dbg.cpp
?? ?LLVM :: FrontendC++/2010-05-12-PtrToMember-Dbg.cpp
?? ?LLVM :: FrontendC/2007-05-16-EmptyStruct.c
?? ?LLVM :: FrontendC/2007-10-01-BuildArrayRef.c
?? ?LLVM :: FrontendC/2010-08-12-asm-aggr-arg.c
?? ?LLVM :: FrontendC/2010-11-16-asmblock.c
?? ?LLVM :: FrontendC/2010-12-01-CommonGlobal.c
?? ?LLVM :: FrontendC/arrayderef.c
?? ?LLVM :: FrontendC/asm-reg-var-local.c
?? ?LLVM :: FrontendC/misaligned-param.c
?? ?LLVM :: FrontendC/vla-1.c
?? ?LLVM :: FrontendC/vla-2.c
?? ?LLVM :: FrontendObjC++/2010-08-02-NonPODObjectValue.mm

The problem is surely that "make check" is picking llvm-gcc from
/usr/bin/. That llvm-gcc was probably installed by xcode and is not up
to date with the llvm trunk

Now I don't want to compile llvm-gcc myself or overwrite what was
installed by xcode?

How to deal with such situation if I want all tests to pass?
Is there a way to disable the llvm-gcc tests when calling make check?


From benny.kra at googlemail.com  Sat Jan  8 10:47:57 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Sat, 8 Jan 2011 17:47:57 +0100
Subject: [LLVMdev] make check on Darwin - some failed tests.
In-Reply-To: <AANLkTinNnDd-mQbD3C984_aFTBwfA-B+qGwGeS-b=tNz@mail.gmail.com>
References: <AANLkTinNnDd-mQbD3C984_aFTBwfA-B+qGwGeS-b=tNz@mail.gmail.com>
Message-ID: <B37B8EA8-B236-4DA9-9F50-B7CEFFAFE665@gmail.com>


On 08.01.2011, at 17:27, Francois Pichet wrote:

> The problem is surely that "make check" is picking llvm-gcc from
> /usr/bin/. That llvm-gcc was probably installed by xcode and is not up
> to date with the llvm trunk
> 
> Now I don't want to compile llvm-gcc myself or overwrite what was
> installed by xcode?
> 
> How to deal with such situation if I want all tests to pass?
> Is there a way to disable the llvm-gcc tests when calling make check?

configuring with "--without-llvmgcc --without-llvmgxx" will keep make check
from picking up your system's or any other llvm-gcc.

From drizzle76 at gmail.com  Sat Jan  8 11:32:13 2011
From: drizzle76 at gmail.com (drizzle drizzle)
Date: Sat, 8 Jan 2011 09:32:13 -0800
Subject: [LLVMdev] i64 type in optimizer
Message-ID: <AANLkTiknXXR0yGQcmM3Zs=Z_DCbtpReXuziKBcCV_NiZ@mail.gmail.com>

Hi
  Is there way to prevent i64 values being generated by the optimizer ?

thanks
dz

From clattner at apple.com  Sat Jan  8 11:36:14 2011
From: clattner at apple.com (Chris Lattner)
Date: Sat, 8 Jan 2011 09:36:14 -0800
Subject: [LLVMdev] i64 type in optimizer
In-Reply-To: <AANLkTiknXXR0yGQcmM3Zs=Z_DCbtpReXuziKBcCV_NiZ@mail.gmail.com>
References: <AANLkTiknXXR0yGQcmM3Zs=Z_DCbtpReXuziKBcCV_NiZ@mail.gmail.com>
Message-ID: <CD2F0F20-F826-4218-9ABD-4C17419DDAE9@apple.com>


On Jan 8, 2011, at 9:32 AM, drizzle drizzle wrote:

> Hi
>  Is there way to prevent i64 values being generated by the optimizer ?

No.  If you add a list of "native" types to the target data string, then the optimizer will avoid types not in the list though (see LangRef.html).  For example, ARM32 sets "i32" as its own native integer type.  i64 can still be generated, but will be less likely to be formed.

-Chris

From grosser at fim.uni-passau.de  Sat Jan  8 12:26:20 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Sat, 08 Jan 2011 13:26:20 -0500
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <AANLkTik28zXP8ABc69mR--B++oByE7h2SJUVJSswTAar@mail.gmail.com>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>	<4D25DCE9.6020205@fim.uni-passau.de>
	<AANLkTik28zXP8ABc69mR--B++oByE7h2SJUVJSswTAar@mail.gmail.com>
Message-ID: <4D28AC4C.8070500@fim.uni-passau.de>

On 01/07/2011 12:36 AM, ether zhhb wrote:
> Hi tobi,
>
>
>>> 2. Allow the some generic parallelism information live out specific
>>> autopar framework, so these information can benefit more passes in
>>> llvm. For example, the X86 and PTX backend could use these information
>>> to perform target specific auto-vectorization.
>>
>> What other types of parallelism are you expecting? We currently support
>> thread level parallelism (as in OpenMP) and vector level parallelism (as in
>> LLVM-IR vectors). At least for X86 I do not see any reason for
>> target specific auto-vectorization as LLVM-IR vectors are lowered extremely
>> well to x86 SIMD instructions. I suppose this is the same for all CPU
>> targets. I still need to look into GPU targets.
>>
> I just think the vector units in different target may have a
> difference width, so the best unroll count of a loop for vectorization
> in not know in high level optimization passes.
I believe we can obtain this information from the target data. If this 
information is not yet available target data should be extended,as also 
high level loop nest transformations should have knowledge about vector 
width and at best even about the number of registers, if we want to 
support effective register tiling.

>> It has however the drawback that instead of just doing code generation once
>> after polly, we do sequential code generation ->  reparsing/analysis ->
>> parallel code generation. Furthermore, the infrastructure needs to pass all
>> the information needed
>> for efficient parallelisation which are at least the access strides, the
>> alignment and privatized variables. Recomputing this information using
>> scalar evolution might be difficult as Polly may introduce
>> loop ivs using e.g. ceil/floor divisions.
>
> To overcame this, We can encode these kind of "hard to recover"
> information as metadata while generating sequential code, and what the
> later "Polyhedral Parallelism Analysis" pass need to do is just read
> these information form metadata, and reparsing/analysis other
> information which is easy to recover. so the process become:
> sequential code generation and metadata annotation ->  read metadata
> (and perform some cheap reparsing/analysis)->parallel code generation
I believe this is a reasonable amount of work and in terms of 
vectorization for Polly I _currently_ see limited benefits. The current 
advantage is- as Renato pointed out - that we could create a very light 
weight vectorizer by taking advantage of the existing loop passes. Also 
in terms of openmp code generation, this might be a good way.

> The bigger picture is:
> 1. Define the common interface for "Parallelism Analysis" or
> "LoopDependenceAnalysis", just like AliasAnalysis.
> 2. Then we can have different implementations of Parallelism Analysis.
>      For example, we may have the "SCEVParallelsimAnalysis", which
> compute the parallelism information base on SCEV.
>      and we can also have the "PolyhedralParallelismAnalysis", which
> read "hard to recover" information from metadata and recompute the
> cheap information, then provides these information via the common
> "Parallelism Analysis" interface.
> 3. The auto-vectorization and parallelization codegen passes can just
> ask the common interface of "Parallelism Analysis" to get necessary
> information.
A reasonable approach.

> The new approach may also make current work for OpenMP support esaier,
> Instead of generate the subfunction directly from clast and insert new
> function in a region pass(it seems that we can only insert new
> function in a modulepass or callgraphSCC pass), we can extract the
> body of the parallel for to a new function with existing CodeExtractor
> in LLVM.
I agree we need to improve the implementation of the OpenMP support. The
reason I did not propose a integrated framework yet is that I still need 
to understand OpenMP a little bit better. Hope after the basic  OpenMP 
support in Polly is finished, we can move to an LLVM integrated 
approach. As we already have an working implementation and test cases we 
can compare against, this will probably be an easier shift.

Maybe we can start in that area, by first introducing some generic 
openmp intrinsics. And later automatically generate those based on meta 
data annotations.

Cheers
Tobi


From grosser at fim.uni-passau.de  Sat Jan  8 12:27:41 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Sat, 08 Jan 2011 13:27:41 -0500
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <AANLkTin02fa09eUwjUUd28auUaKHQdM+dZoU_F7C7pL8@mail.gmail.com>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>	<4D25DCE9.6020205@fim.uni-passau.de>
	<AANLkTin02fa09eUwjUUd28auUaKHQdM+dZoU_F7C7pL8@mail.gmail.com>
Message-ID: <4D28AC9D.3040102@fim.uni-passau.de>

On 01/06/2011 10:59 AM, Renato Golin wrote:
> On 6 January 2011 15:16, Tobias Grosser<grosser at fim.uni-passau.de>  wrote:
>>> The main idea is, we separate the transform passes and codegen passes
>>> for auto-parallelization and vectorization (Graphite[2] for gcc seems
>>> to taking similar approach for auto-vectorization).
>
> I agree with Ether.
>
> A two-stage vectorization would allow you to use the simple
> loop-unroller already in place to generate vector/mp intrinsics from
> them, and if more parallelism is required, use the expensive Poly
> framework to skew loops and remove dependencies, so the loop-unroller
> and other cheap bits can do their job where then couldn't before.
>
> So, in essence, this is a three-stage job. The optional heavy-duty
> Poly analysis, the cheap loop-optimizer and the mp/vector
> transformation pass. The best features of having them three is to be
> able to choose the level of vectorization you want and to re-use the
> current loop analysis into the scheme.

OK. First of all to agree on a name, we decided to call the Polyhedral 
analysis we develop PoLLy, as in Polly the parrot. ;-) Maybe it was a 
misleading choice?

In general as I explained I agree that a three stage approach is useful,
for the reasons you explained, however it is more overhead (and just 
implementation work) than the one we use now. I currently do not have 
the time to implement the proposed approach. In case anybody is 
interested to work on patches, I am happy to support this.

>> What other types of parallelism are you expecting? We currently support
>> thread level parallelism (as in OpenMP) and vector level parallelism (as
>> in LLVM-IR vectors). At least for X86 I do not see any reason for
>> target specific auto-vectorization as LLVM-IR vectors are lowered
>> extremely well to x86 SIMD instructions. I suppose this is the same for
>> all CPU targets. I still need to look into GPU targets.
>
> I'd suggest to try and transform sequential instructions into vector
> instructions (in the third stage) if proven to be correct.
>
> So, when Poly skews a loop, and the loop analysis unrolls it to, say,
> 4 calls to the same instruction, a metadata binding them together can
> hint the third stage to make that a vector operation with the same
> semantics.

I know, this is the classical approach for vector code generation. The 
difference in Polly is that we do not have a loop represented in 
LLVM-IR, which we would like to vectorize, but we have a loop body
and its content which we want to create as vector code. So instead of
creating the LLVM-IR loop structure, write meta data, unroll the loop
and than create merge instructions to vector instructions, the only 
change in polly is, that it either generates N scalar instructions per 
original instruction or one vector instruction (if N is the number of 
loop iterations which is equivalent to the vector width). So 
vectorization in Polly was very easy to implement and already works 
reasonable well.

>> LLVM-IR vector instructions however are generic SIMD
>> instructions so I do not see any reason to create target specific
>> auto vectorizer passes.
>
> If you're assuming the original code is using intrinsics, that is
> correct. But if you want to generate the vector code from Poly, than
> you need to add that support, too.

Why are target specific vectorization passes needed to generate vector 
instructions from Polly? The only target specific information I 
currently see is the vector width, which a generic vectorization pass 
can obtain from the target data information. Could you explain for which 
features target specific vectorization would be needed?

> ARM also has good vector instruction selection (on Cortex-A* with
> NEON), so you also get that for free. ;)
I have read this and the look interesting. I suppose they are created 
out of the box, if a pass generates LLVM-IR vector instructions?

> cheers,
> --renato

Thanks for your comments

Tobi

From echristo at apple.com  Sat Jan  8 13:21:34 2011
From: echristo at apple.com (Eric Christopher)
Date: Sat, 8 Jan 2011 11:21:34 -0800
Subject: [LLVMdev] LLVM-GCC build failed
In-Reply-To: <871319.76118.qm@web121705.mail.ne1.yahoo.com>
References: <871319.76118.qm@web121705.mail.ne1.yahoo.com>
Message-ID: <F153943E-4C4B-47D2-ADDF-911C5C29246E@apple.com>


On Jan 8, 2011, at 8:04 AM, akramul azim wrote:

> Hi
>  
>    I am using LLVM and LLVM-GCC from SVN (version number: 122880). And I am using arm-2009q1-176-arm-none-linux-gnueabi-i686-mingw32.tar.bz2 or arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2. I tried the automated scripts (create-snapshots.sh and build-install-linux.sh) that are in the LLVM repository for building crosstoll for ARM (http://llvm.org/svn/llvm-project/llvm/trunk/utils/crosstool/) but get the following error for building llvm-gcc (llvm built successfully):
>  
> When I use arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2: my build fails by the following error:
>  
> /usr/local/crosstool/codesourcery/arm-2009q1/bin/arm-none-linux-gnueabi-gcc: cannot
>  execute binary file
>  
> make[2]: *** [crtbegin.o] Error 1
>  
> When I use arm-2009q1-176-arm-none-linux-gnueabi-i686-mingw32.tar.bz2, I get the following error:
>  
> Assembler messages:^M
> Error: can't open /cygdrive/d/DOCUME~2/AZIM/LOCALS~1/Temp/cc19Hfjy.s for reading
> : No such file or directory^M
> make[2]: *** [crtbegin.o] Error 1
>  
> Can anyone please tell me why the error?
>  

They're pretty clear and definitely not related to llvm. One says that you can't execute the arm-gcc binary you have from codesourcery the other says that you can't open a temporary .s file for some reason.

I'd guess permissions are hosed on your machines, but I don't know.

Good luck.

-eric

From rengolin at systemcall.org  Sat Jan  8 17:52:04 2011
From: rengolin at systemcall.org (Renato Golin)
Date: Sat, 8 Jan 2011 23:52:04 +0000
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <4D28AC9D.3040102@fim.uni-passau.de>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>
	<4D25DCE9.6020205@fim.uni-passau.de>
	<AANLkTin02fa09eUwjUUd28auUaKHQdM+dZoU_F7C7pL8@mail.gmail.com>
	<4D28AC9D.3040102@fim.uni-passau.de>
Message-ID: <AANLkTimw+LWJAimegyBGdUWx1Nmbeq5UF+tb4uB6MsL_@mail.gmail.com>

On 8 January 2011 18:27, Tobias Grosser <grosser at fim.uni-passau.de> wrote:
> OK. First of all to agree on a name, we decided to call the Polyhedral
> analysis we develop PoLLy, as in Polly the parrot. ;-) Maybe it was a
> misleading choice?

I never realised... ;) Polly it is!


> In general as I explained I agree that a three stage approach is useful,
> for the reasons you explained, however it is more overhead (and just
> implementation work) than the one we use now. I currently do not have the
> time to implement the proposed approach. In case anybody is interested to
> work on patches, I am happy to support this.

Good. If it's just a matter of time (not design), things can be left
ready for future implementation without breaking the current model. I
thought there was a fundamental flaw with the three-stage design (and
was eager to learn it).


> the only change
> in polly is, that it either generates N scalar instructions per original
> instruction or one vector instruction (if N is the number of loop iterations
> which is equivalent to the vector width). So vectorization in Polly was very
> easy to implement and already works reasonable well.

Ok, this comes with another current change in LLVM: OpenCL. I explain.

OpenCL has very large (and odd) vector sizes, that if implemented to
vectorized units (like SSE or NEON), need to be legalised.

Such a pass should be target specific and polly could make use of
that. If polly always generate vector code (instead of reason if the
number of unrolled operations are the same as the current target being
compiled into), the later legalisation pass can deal with the odd
sized vectors and transform into multiples of legal vector + some
surplus of the module as normal instructions.

Also, if the target doesn't have vector units, there could be a
generic (or not) transformation to cpu instructions (if there isn't
one already), so that makes your polly pass completely target
agnostic.


> Why are target specific vectorization passes needed to generate vector
> instructions from Polly? The only target specific information I currently
> see is the vector width, which a generic vectorization pass can obtain from
> the target data information. Could you explain for which features target
> specific vectorization would be needed?

Not target specific, generic vectors. See above.


> I have read this and the look interesting. I suppose they are created out of
> the box, if a pass generates LLVM-IR vector instructions?

Yup. It's pretty neat. SSE is probably similar, but with NEON, a
pattern-match is done when the variable type is a vector.

So, a multiplication followed by an addition in the right way is
transformed into a multiply-and-add NEON instruction.

An example (in a completely wrong IR, just to make a point):

%a = <4 x i32>
%b = <4 x i32>
%c = <4 x i32>
%mul = mul %b, %c
%acc = add %mul, %a

gets transformed into:

VMLA.I32 q0, q1, q2

Multiplying vectors (of the correct size) gets into VMUL, adding gets
to VADD and so on...

cheers,
--renato

From grosser at fim.uni-passau.de  Sat Jan  8 18:07:16 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Sat, 08 Jan 2011 19:07:16 -0500
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <AANLkTimw+LWJAimegyBGdUWx1Nmbeq5UF+tb4uB6MsL_@mail.gmail.com>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>	<4D25DCE9.6020205@fim.uni-passau.de>	<AANLkTin02fa09eUwjUUd28auUaKHQdM+dZoU_F7C7pL8@mail.gmail.com>	<4D28AC9D.3040102@fim.uni-passau.de>
	<AANLkTimw+LWJAimegyBGdUWx1Nmbeq5UF+tb4uB6MsL_@mail.gmail.com>
Message-ID: <4D28FC34.7000209@fim.uni-passau.de>

On 01/08/2011 06:52 PM, Renato Golin wrote:
> On 8 January 2011 18:27, Tobias Grosser<grosser at fim.uni-passau.de>  wrote:
>> OK. First of all to agree on a name, we decided to call the Polyhedral
>> analysis we develop PoLLy, as in Polly the parrot. ;-) Maybe it was a
>> misleading choice?
>
> I never realised... ;) Polly it is!
>
>
>> In general as I explained I agree that a three stage approach is useful,
>> for the reasons you explained, however it is more overhead (and just
>> implementation work) than the one we use now. I currently do not have the
>> time to implement the proposed approach. In case anybody is interested to
>> work on patches, I am happy to support this.
>
> Good. If it's just a matter of time (not design), things can be left
> ready for future implementation without breaking the current model. I
> thought there was a fundamental flaw with the three-stage design (and
> was eager to learn it).
Not at all. It was just soo much easier to create vector instructions 
right inside of Polly that I did not start another large project.

>> the only change
>> in polly is, that it either generates N scalar instructions per original
>> instruction or one vector instruction (if N is the number of loop iterations
>> which is equivalent to the vector width). So vectorization in Polly was very
>> easy to implement and already works reasonable well.
>
> Ok, this comes with another current change in LLVM: OpenCL. I explain.
>
> OpenCL has very large (and odd) vector sizes, that if implemented to
> vectorized units (like SSE or NEON), need to be legalised.
>
> Such a pass should be target specific and polly could make use of
> that. If polly always generate vector code (instead of reason if the
> number of unrolled operations are the same as the current target being
> compiled into), the later legalisation pass can deal with the odd
> sized vectors and transform into multiples of legal vector + some
> surplus of the module as normal instructions.
>
> Also, if the target doesn't have vector units, there could be a
> generic (or not) transformation to cpu instructions (if there isn't
> one already), so that makes your polly pass completely target
> agnostic.

I believe LLVM already has lowering of wide LLVM-IR vectors to a set of 
operations of vectors of target specific wide. This is done in the back 
end and works correct for all cases I tested. The problem with this is 
just performance. They fastest loop nest is different on architectures 
with different vector width and size of vector registers. A generic 
polyhedral optimizer will therefore not generate incorrect code, however 
the proposed transformations are wrong. If Polly e.g. always generates 
vector operations to be 32 floats width, this would result in not very 
pleasant code, but might still be lowered to something well performing 
on cpus supporting AVX. Matching the target vector width in our 
heuristics will obviously give the best performance. So to get optimal 
performance Polly needs to take target data into account.

Talking about OpenCL. The lowering you described for the large vector 
instructions sounds reasonable. Optimal code would however probably 
produced by revisiting the whole loop structure and generating one that 
is performance wise optimal for the target architecture.

>> Why are target specific vectorization passes needed to generate vector
>> instructions from Polly? The only target specific information I currently
>> see is the vector width, which a generic vectorization pass can obtain from
>> the target data information. Could you explain for which features target
>> specific vectorization would be needed?
>
> Not target specific, generic vectors. See above.
>
>
>> I have read this and the look interesting. I suppose they are created out of
>> the box, if a pass generates LLVM-IR vector instructions?
>
> Yup. It's pretty neat. SSE is probably similar, but with NEON, a
> pattern-match is done when the variable type is a vector.
>
> So, a multiplication followed by an addition in the right way is
> transformed into a multiply-and-add NEON instruction.
>
> An example (in a completely wrong IR, just to make a point):
>
> %a =<4 x i32>
> %b =<4 x i32>
> %c =<4 x i32>
> %mul = mul %b, %c
> %acc = add %mul, %a
>
> gets transformed into:
>
> VMLA.I32 q0, q1, q2
>
> Multiplying vectors (of the correct size) gets into VMUL, adding gets
> to VADD and so on...

Yes. I have seen this also for powerpc and hope we can soon use the AVX 
multiply and add instruction too.

Cheers
Tobi

From rengolin at systemcall.org  Sat Jan  8 18:34:18 2011
From: rengolin at systemcall.org (Renato Golin)
Date: Sun, 9 Jan 2011 00:34:18 +0000
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <4D28FC34.7000209@fim.uni-passau.de>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>
	<4D25DCE9.6020205@fim.uni-passau.de>
	<AANLkTin02fa09eUwjUUd28auUaKHQdM+dZoU_F7C7pL8@mail.gmail.com>
	<4D28AC9D.3040102@fim.uni-passau.de>
	<AANLkTimw+LWJAimegyBGdUWx1Nmbeq5UF+tb4uB6MsL_@mail.gmail.com>
	<4D28FC34.7000209@fim.uni-passau.de>
Message-ID: <AANLkTimQcX7Zbayw1B0FumzUP10Ht52aesV1FY27Fb5J@mail.gmail.com>

On 9 January 2011 00:07, Tobias Grosser <grosser at fim.uni-passau.de> wrote:
> Matching the target vector width in our heuristics will obviously give the
> best performance. So to get optimal performance Polly needs to take target
> data into account.

Indeed! And even if you lack target information, you won't generate
wrong code. ;)


> Talking about OpenCL. The lowering you described for the large vector
> instructions sounds reasonable. Optimal code would however probably produced
> by revisiting the whole loop structure and generating one that is
> performance wise optimal for the target architecture.

Yes, and this is an important point in OpenCL for CPUs. If we could
run a sub-pass of Polly (just the vector fiddling) after the
legalization, that would make it much easier for OpenCL
implementations.

However, none of these apply to GPUs, and any pass you run could
completely destroy the semantics for a GPU back-end. The AMD
presentation on the meetings last year expose some of that.

cheers,
--renato

From grosser at fim.uni-passau.de  Sat Jan  8 18:41:42 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Sat, 08 Jan 2011 19:41:42 -0500
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <AANLkTimQcX7Zbayw1B0FumzUP10Ht52aesV1FY27Fb5J@mail.gmail.com>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>	<4D25DCE9.6020205@fim.uni-passau.de>	<AANLkTin02fa09eUwjUUd28auUaKHQdM+dZoU_F7C7pL8@mail.gmail.com>	<4D28AC9D.3040102@fim.uni-passau.de>	<AANLkTimw+LWJAimegyBGdUWx1Nmbeq5UF+tb4uB6MsL_@mail.gmail.com>	<4D28FC34.7000209@fim.uni-passau.de>
	<AANLkTimQcX7Zbayw1B0FumzUP10Ht52aesV1FY27Fb5J@mail.gmail.com>
Message-ID: <4D290446.9070102@fim.uni-passau.de>

On 01/08/2011 07:34 PM, Renato Golin wrote:
> On 9 January 2011 00:07, Tobias Grosser<grosser at fim.uni-passau.de>  wrote:
>> Matching the target vector width in our heuristics will obviously give the
>> best performance. So to get optimal performance Polly needs to take target
>> data into account.
>
> Indeed! And even if you lack target information, you won't generate
> wrong code. ;)
>
>
>> Talking about OpenCL. The lowering you described for the large vector
>> instructions sounds reasonable. Optimal code would however probably produced
>> by revisiting the whole loop structure and generating one that is
>> performance wise optimal for the target architecture.
>
> Yes, and this is an important point in OpenCL for CPUs. If we could
> run a sub-pass of Polly (just the vector fiddling) after the
> legalization, that would make it much easier for OpenCL
> implementations.
I do not get this one? Why would you just use a part of Polly? Was I 
wrong by
assuming LLVM will even today without any special pass generate correct 
code for the width OpenCL vectors. For me Polly just is an optimization,
that could revisit the whole vectorization decision by looking at the 
big picture of the whole loop nest and generating a target specific loop 
nest with target specific vectorization (and openmp parallelisation).

> However, none of these apply to GPUs, and any pass you run could
> completely destroy the semantics for a GPU back-end. The AMD
> presentation on the meetings last year expose some of that.

I have seen the AMD presentation and believe we can generate efficient 
vector code for GPUs. Obviously with some adaptions, however I am 
convinced this is doable.

Cheers
Tobi

From chenwj at iis.sinica.edu.tw  Sat Jan  8 21:28:33 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Sun, 9 Jan 2011 11:28:33 +0800
Subject: [LLVMdev] DragonEgg on FreeBSD
In-Reply-To: <4D286952.4040107@free.fr>
References: <20110108042315.GA3945@cs.nctu.edu.tw> <4D286952.4040107@free.fr>
Message-ID: <20110109032833.GA50410@cs.nctu.edu.tw>

Hi, Duncan

  I only tested dragonegg on simple HelloWorld C/C++ programs. It can emit LLVM IR and
generate a runable executable.

  On FreeBSD, Makefile need to be modified to include a path to gmp.h
header file. I give a patch here,

--------------------------------------------------------------------------------
--- Makefile.orig       2011-01-08 12:39:35.480184745 +0800
+++ Makefile    2011-01-08 12:40:58.569064365 +0800
@@ -52,7 +52,8 @@
             -MD -MP \
             -DIN_GCC -DREVISION=\"$(REVISION)\" \
             -DGCC_MAJOR=$(GCC_MAJOR) -DGCC_MINOR=$(GCC_MINOR) \
-            -I$(SRC_DIR) -I$(GCC_PLUGIN_DIR)/include
+            -I$(SRC_DIR) -I$(GCC_PLUGIN_DIR)/include \
+            -I/usr/local/include

 LD_OPTIONS+=$(LDFLAGS) $(shell $(LLVM_CONFIG) --ldflags)
--------------------------------------------------------------------------------

  And you should make a freebsd directory and copy linux/llvm-os.h to
there.

--------------------------------------------------------------------------------
$ mkdir freebsd
$ cp linux/llvm-os.h freebsd/
--------------------------------------------------------------------------------

  Finally, use "gmake" not "make" on FreeBSD to build dragonegg.so.

  Well, there are warings while building dragonegg.so. But I guess it
doesn't affect dragonegg.so, I just leave it there. Here are the
warnings.

--------------------------------------------------------------------------------
<command-line>: warning: "__STDC_LIMIT_MACROS" redefined
<command-line>: warning: this is the location of the previous definition
--------------------------------------------------------------------------------

Regards,
chenwj
  
-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From rengolin at systemcall.org  Sun Jan  9 08:23:43 2011
From: rengolin at systemcall.org (Renato Golin)
Date: Sun, 9 Jan 2011 14:23:43 +0000
Subject: [LLVMdev] Proposal: Generic auto-vectorization and
 parallelization approach for LLVM and Polly
In-Reply-To: <4D290446.9070102@fim.uni-passau.de>
References: <AANLkTin4HQGo9DH_0OXCPsF-DZWwB_BUfANHNbgpeXPc@mail.gmail.com>
	<4D25DCE9.6020205@fim.uni-passau.de>
	<AANLkTin02fa09eUwjUUd28auUaKHQdM+dZoU_F7C7pL8@mail.gmail.com>
	<4D28AC9D.3040102@fim.uni-passau.de>
	<AANLkTimw+LWJAimegyBGdUWx1Nmbeq5UF+tb4uB6MsL_@mail.gmail.com>
	<4D28FC34.7000209@fim.uni-passau.de>
	<AANLkTimQcX7Zbayw1B0FumzUP10Ht52aesV1FY27Fb5J@mail.gmail.com>
	<4D290446.9070102@fim.uni-passau.de>
Message-ID: <AANLkTinDsLiqYi5o=d1rcxn9r1eUEstsrJTbPpC=y44-@mail.gmail.com>

On 9 January 2011 00:41, Tobias Grosser <grosser at fim.uni-passau.de> wrote:
> I do not get this one? Why would you just use a part of Polly?

Oh, you can. Just that maybe you don't need to go over all Polly if
openCL already has the vector semantics done in the front-end.


> Was I wrong by assuming LLVM will even today without any special pass generate correct code
> for the width OpenCL vectors. For me Polly just is an optimization,
> that could revisit the whole vectorization decision by looking at the big
> picture of the whole loop nest and generating a target specific loop nest
> with target specific vectorization (and openmp parallelisation).

I'm really not the OpenCL expert, but I hear that it's not as trivial
as one would think.

I know from generating NEON code in the front-end that any fiddling in
the semantics of the instructions could make the pattern-matching
algorithm to fail and you fall back to normal instructions.

I'm just trying to be cautions here not to fall into false hopes, but
someone with more knowledge in OpenCL would know better.


> I have seen the AMD presentation and believe we can generate efficient
> vector code for GPUs. Obviously with some adaptions, however I am convinced
> this is doable.

Great! Even better than I thought! ;)

cheers,
--renatoorder

From bijoy123_8 at yahoo.com  Sun Jan  9 17:08:11 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Sun, 9 Jan 2011 15:08:11 -0800 (PST)
Subject: [LLVMdev] LLVM-GCC build failed
In-Reply-To: <F153943E-4C4B-47D2-ADDF-911C5C29246E@apple.com>
Message-ID: <610196.37841.qm@web121706.mail.ne1.yahoo.com>

Now I get the following error:
?
checking for ld that supports -Wl,--gc-sections... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/MinGW/llvm-project/obj/llvm-gcc-4.2'
make: *** [all] Error 2

Can anyone please tell me how to resolve the problem?
?
Akramul
--- On Sat, 8/1/11, Eric Christopher <echristo at apple.com> wrote:


From: Eric Christopher <echristo at apple.com>
Subject: Re: [LLVMdev] LLVM-GCC build failed
To: "akramul azim" <bijoy123_8 at yahoo.com>
Cc: llvmdev at cs.uiuc.edu
Date: Saturday, 8 January, 2011, 7:21 PM



On Jan 8, 2011, at 8:04 AM, akramul azim wrote:

> Hi
>? 
>? ? I am using LLVM and LLVM-GCC from SVN (version number: 122880). And I am using arm-2009q1-176-arm-none-linux-gnueabi-i686-mingw32.tar.bz2 or arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2. I tried the automated scripts (create-snapshots.sh and build-install-linux.sh) that are in the LLVM repository for building crosstoll for ARM (http://llvm.org/svn/llvm-project/llvm/trunk/utils/crosstool/) but get the following error for building llvm-gcc (llvm built successfully):
>? 
> When I use arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2: my build fails by the following error:
>? 
> /usr/local/crosstool/codesourcery/arm-2009q1/bin/arm-none-linux-gnueabi-gcc: cannot
>? execute binary file
>? 
> make[2]: *** [crtbegin.o] Error 1
>? 
> When I use arm-2009q1-176-arm-none-linux-gnueabi-i686-mingw32.tar.bz2, I get the following error:
>? 
> Assembler messages:^M
> Error: can't open /cygdrive/d/DOCUME~2/AZIM/LOCALS~1/Temp/cc19Hfjy.s for reading
> : No such file or directory^M
> make[2]: *** [crtbegin.o] Error 1
>? 
> Can anyone please tell me why the error?
>? 

They're pretty clear and definitely not related to llvm. One says that you can't execute the arm-gcc binary you have from codesourcery the other says that you can't open a temporary .s file for some reason.

I'd guess permissions are hosed on your machines, but I don't know.

Good luck.

-eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110109/778c4c91/attachment.html 

From stoklund at 2pi.dk  Sun Jan  9 17:15:44 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Sun, 9 Jan 2011 15:15:44 -0800
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <699FE8C7-6849-4FA2-A3C8-779463133639@apple.com>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
	<6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
	<34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
	<1701B32D-079E-45F7-B904-719296C57D6F@apple.com>
	<4D27649C.5040506@sidefx.com>
	<699FE8C7-6849-4FA2-A3C8-779463133639@apple.com>
Message-ID: <BA5EAA28-271E-44E4-8EAA-CB1CABD0542E@2pi.dk>


On Jan 7, 2011, at 11:25 AM, Dale Johannesen wrote:

> We might want to make physical registers negative and virtuals positive, or vice versa.   Then FirstVirtualRegister is 0 or 1, and we could get rid of those annoying subtractions of FirstVirtualRegister all over the virtual-register-handling passes.  Since 0 is used all over the place as "invalid register" it is probably best to leave this alone, let FirstVirtualRegister be 1, and simply ignore (i.e. treat as erroneous) the 0th element of anything keyed off FirstVirtualRegister.

Fixed in r123137.

I decided to move the virtual register numbers because there is so much code already using physical register numbers as direct indices.

My first attempt was to let the virtuals run from -1 downwards, but it turns out that we have code in isel depending on createVirtualRegister() returning increasing numbers. DenseMap<unsigned> also complained because it uses -1u and -2u as sentinels.

So I moved the virtual register range to 2^31 growing upwards.

The range from 2^30 to 2^31 is reserved for representing stack slots.

Physical registers get 1 .. 2^30-1.

/jakob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110109/14fb5266/attachment.bin 

From stoklund at 2pi.dk  Sun Jan  9 18:07:31 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Sun, 9 Jan 2011 16:07:31 -0800
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <BA5EAA28-271E-44E4-8EAA-CB1CABD0542E@2pi.dk>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
	<6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
	<34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
	<1701B32D-079E-45F7-B904-719296C57D6F@apple.com>
	<4D27649C.5040506@sidefx.com>
	<699FE8C7-6849-4FA2-A3C8-779463133639@apple.com>
	<BA5EAA28-271E-44E4-8EAA-CB1CABD0542E@2pi.dk>
Message-ID: <870E29AB-E850-4123-B738-D33E294E20EF@2pi.dk>


On Jan 9, 2011, at 3:15 PM, Jakob Stoklund Olesen wrote:

> So I moved the virtual register range to 2^31 growing upwards.

Note that this allows the index translation in an IndexedMap to be optimized away completely in 32-bit builds.

MachineRegisterInfo::setRegClass(unsigned Reg, const TargetRegisterClass *RC) {
  const TargetRegisterClass *OldRC = VRegInfo[Reg].first;

Becomes:

movl		12(%ebp), %esi 
movl		8(%ebp), %eax
movl		(%eax), %ecx
movl		(%ecx,%esi,8), %edx

The high bit on the virtual register number falls off in the address computation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110109/ee9c58db/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110109/ee9c58db/attachment.bin 

From drizzle76 at gmail.com  Sun Jan  9 21:38:24 2011
From: drizzle76 at gmail.com (drizzle drizzle)
Date: Sun, 9 Jan 2011 19:38:24 -0800
Subject: [LLVMdev] readonly registers
Message-ID: <AANLkTi=i0nOfM1j-2szC0T6K=GtrRy0aNu-bRq5uqBxt@mail.gmail.com>

Hi
   Any ideas on how I can represent readonly registers? I do not want
any register allocation/liveness analysis  to happen for these.

thanks
dz

From stoklund at 2pi.dk  Sun Jan  9 22:45:33 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Sun, 9 Jan 2011 20:45:33 -0800
Subject: [LLVMdev] readonly registers
In-Reply-To: <AANLkTi=i0nOfM1j-2szC0T6K=GtrRy0aNu-bRq5uqBxt@mail.gmail.com>
References: <AANLkTi=i0nOfM1j-2szC0T6K=GtrRy0aNu-bRq5uqBxt@mail.gmail.com>
Message-ID: <7EFD5995-FDA4-40F5-ACCC-FBBA03A25172@2pi.dk>


On Jan 9, 2011, at 7:38 PM, drizzle drizzle wrote:

> Hi
>   Any ideas on how I can represent readonly registers? I do not want
> any register allocation/liveness analysis  to happen for these.

Mark them as reserved. That disables liveness and allocation.

/jakob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110109/90721726/attachment.bin 

From stoklund at 2pi.dk  Sun Jan  9 22:53:35 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Sun, 9 Jan 2011 20:53:35 -0800
Subject: [LLVMdev] Pass to compute livein info
In-Reply-To: <4D25EAF8.1010608@gmail.com>
References: <4D25EAF8.1010608@gmail.com>
Message-ID: <4B557834-29DB-47EC-A4F6-5F666F22A4C9@2pi.dk>


On Jan 6, 2011, at 8:16 AM, Bin Zeng wrote:

> Hi all,
> 
> Is there a pass that computes livein information for each 
> MachineBasicBlock? I tried to find such a pass but could not find any. I 
> am trying to use the livein information to get dead registers to insert 
> some instructions right before code emission but the livein information 
> seems to be invalidated by some pass. I might need to recompute the 
> livein information before my pass. Thanks a lot.

No, the liveness is not preserved by late code generation passes, and there is currently no way of recomputing it.

/jakob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110109/1b819e71/attachment.bin 

From baldrick at free.fr  Mon Jan 10 11:29:49 2011
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 10 Jan 2011 18:29:49 +0100
Subject: [LLVMdev] About NDEBUG (Cont)
In-Reply-To: <AANLkTin_B4KShpmmZgheeHbTBUn0kdyMyTeDECCL0fHw@mail.gmail.com>
References: <AANLkTin_B4KShpmmZgheeHbTBUn0kdyMyTeDECCL0fHw@mail.gmail.com>
Message-ID: <4D2B420D.5070807@free.fr>

Hi Li Qingan,

> Thanks for your last reply.
> I have made a critical mistake when I stated my question in last email.
> I built llvm in debug mode, but the NDEBUG seemed to be still defined, such that
> the -debug option is not enabled.
> I have restated my configuration below.

you need to configure with --enable-assertions
In spite of the name, NDEBUG is not related to optimization or debugging
symbols, it means that checking (aka assertions) are disabled.  Probably
it should be renamed to NASSERT

Ciao, Duncan.

> Looking forwards to your reply.
>
>
>
>
>
> Hi Li Qingan,
>
>>  I have built and installed llvm-2.8 in debug mode using:
>>
>> >SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime --disable-optimized
>>  --enable-debug-symbols
>>
>> >make install
>>
>>
>>  It seems theNDEBUGcontrols a lot of print-out of debug information, by using
>>  DEBUG() or dbgs().
>>
>>  And it is said thatNDEBUGis in enabled in debug mode, but I find it does not
>>  work and the -debug option is not recognized. How should I enableNDEBUGor
>>  enable DEBUG() and dbgs()? Should I defineNDEBUGin the .cpp files related,
>>  when I need the debug information?
>
> actually it is the opposite:NDEBUGis enabled when not in debug mode.  The "N" in
> NDEBUGstands for "Not".
>
> Ciao, Duncan.
> --
> Best regards,
>
> Li Qingan
>


From dalej at apple.com  Mon Jan 10 13:25:44 2011
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 10 Jan 2011 11:25:44 -0800
Subject: [LLVMdev] About NDEBUG (Cont)
In-Reply-To: <4D2B420D.5070807@free.fr>
References: <AANLkTin_B4KShpmmZgheeHbTBUn0kdyMyTeDECCL0fHw@mail.gmail.com>
	<4D2B420D.5070807@free.fr>
Message-ID: <15822A29-FA2B-4DF3-8F9C-30FC2C4EC6E7@apple.com>


On Jan 10, 2011, at 9:29 AMPST, Duncan Sands wrote:

> Hi Li Qingan,
> 
>> Thanks for your last reply.
>> I have made a critical mistake when I stated my question in last email.
>> I built llvm in debug mode, but the NDEBUG seemed to be still defined, such that
>> the -debug option is not enabled.
>> I have restated my configuration below.
> 
> you need to configure with --enable-assertions
> In spite of the name, NDEBUG is not related to optimization or debugging
> symbols, it means that checking (aka assertions) are disabled.  Probably
> it should be renamed to NASSERT

Use of the name NDEBUG to control assertions comes from the C++ (and C) standards.  I agree this was not a great choice but deviating from the standard would be more confusing than helpful IMO.

> Ciao, Duncan.
> 
>> Looking forwards to your reply.
>> 
>> 
>> 
>> 
>> 
>> Hi Li Qingan,
>> 
>>> I have built and installed llvm-2.8 in debug mode using:
>>> 
>>>> SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime --disable-optimized
>>> --enable-debug-symbols
>>> 
>>>> make install
>>> 
>>> 
>>> It seems theNDEBUGcontrols a lot of print-out of debug information, by using
>>> DEBUG() or dbgs().
>>> 
>>> And it is said thatNDEBUGis in enabled in debug mode, but I find it does not
>>> work and the -debug option is not recognized. How should I enableNDEBUGor
>>> enable DEBUG() and dbgs()? Should I defineNDEBUGin the .cpp files related,
>>> when I need the debug information?
>> 
>> actually it is the opposite:NDEBUGis enabled when not in debug mode.  The "N" in
>> NDEBUGstands for "Not".
>> 
>> Ciao, Duncan.
>> --
>> Best regards,
>> 
>> Li Qingan
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110110/097328b0/attachment.html 

From dalej at apple.com  Mon Jan 10 13:28:36 2011
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 10 Jan 2011 11:28:36 -0800
Subject: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?
In-Reply-To: <BA5EAA28-271E-44E4-8EAA-CB1CABD0542E@2pi.dk>
References: <60743.99.253.252.116.1294380670.squirrel@www.sidefx.com>
	<6440836A-4A6A-448D-959B-65E660B3B286@apple.com>
	<34195.99.253.252.116.1294382349.squirrel@www.sidefx.com>
	<1701B32D-079E-45F7-B904-719296C57D6F@apple.com>
	<4D27649C.5040506@sidefx.com>
	<699FE8C7-6849-4FA2-A3C8-779463133639@apple.com>
	<BA5EAA28-271E-44E4-8EAA-CB1CABD0542E@2pi.dk>
Message-ID: <81471A7E-6DFF-407B-910A-ECB8436B6133@apple.com>

On Jan 9, 2011, at 3:15 PMPST, Jakob Stoklund Olesen wrote:
> On Jan 7, 2011, at 11:25 AM, Dale Johannesen wrote:
> 
>> We might want to make physical registers negative and virtuals positive, or vice versa.   Then FirstVirtualRegister is 0 or 1, and we could get rid of those annoying subtractions of FirstVirtualRegister all over the virtual-register-handling passes.  Since 0 is used all over the place as "invalid register" it is probably best to leave this alone, let FirstVirtualRegister be 1, and simply ignore (i.e. treat as erroneous) the 0th element of anything keyed off FirstVirtualRegister.

Thanks Jakob.  This is a microoptimization, but those subtractions were really kludgy-looking.

After writing the above it occurred to me that negative numbers would run afoul of the widespread practice of declaring registers "unsigned", so this is probably the best way.

> Fixed in r123137.
> 
> I decided to move the virtual register numbers because there is so much code already using physical register numbers as direct indices.
> 
> My first attempt was to let the virtuals run from -1 downwards, but it turns out that we have code in isel depending on createVirtualRegister() returning increasing numbers. DenseMap<unsigned> also complained because it uses -1u and -2u as sentinels.
> 
> So I moved the virtual register range to 2^31 growing upwards.
> 
> The range from 2^30 to 2^31 is reserved for representing stack slots.
> 
> Physical registers get 1 .. 2^30-1.
> 
> /jakob
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110110/0c534897/attachment.html 

From dpatel at apple.com  Mon Jan 10 13:59:28 2011
From: dpatel at apple.com (Devang Patel)
Date: Mon, 10 Jan 2011 11:59:28 -0800
Subject: [LLVMdev] [cfe-dev] Function-level metadata for OpenCL (was	Re:
	OpenCL support)
In-Reply-To: <20101224210217.GA4631@pcc.me.uk>
References: <20101216223345.GB1885@pcc.me.uk>
	<AANLkTikAYtbfG6GX07TYHLmzU-u+S7ivWbqs_AnZwFmz@mail.gmail.com>
	<20101220201112.GA26083@pcc.me.uk>
	<AANLkTikujQahUBH0YVH-ihBPe4Vu8mrTs_GNTLEynSTN@mail.gmail.com>
	<20101224210217.GA4631@pcc.me.uk>
Message-ID: <95F53D7F-DB48-4678-A57B-8676E640B4E5@apple.com>

>>>> Being discardable is a design point of metadata. You might add something
>>>> else to support this, but it won't be metadata.
>>> 
>>> There's nothing intrinsic about the concept of metadata which requires
>>> it to be discardable.  


Metadata objects (MDNode, NamedMDNode etc.. ) are containers. They are always available if you keep track of anchors to find them. The optimizer does not know that they exists and you should design your use-case accordingly. The only thing discardable about metadata is the llvm values being put into these metadata containers. 

For example, if you're using a MDNode M1 to keep track of a parameter P1 then P1 can disappear any time because the optimizer does not know that M1 is "using" P1. That's by design. In this situation, the corresponding M1 element will automatically turn to null and the users of the M1 should be able to handle that. If the optimizer replaces P1 with new parameter P2 then the M1 will automatically update itself.

-
Devang
	

From llvm.org at schrieb.de  Mon Jan 10 15:58:20 2011
From: llvm.org at schrieb.de (Jonas Gefele)
Date: Mon, 10 Jan 2011 22:58:20 +0100
Subject: [LLVMdev] Current state of the (new) CBackend & LLVM/clang with
 Microsoft Visual Studio
Message-ID: <4D2B80FC.1000608@schrieb.de>

Hi.

I am interested in using the CBackend of LLVM. I have read about the 
problems with the current version and that David Greene has started a 
reimplementation. Can you tell me about its current state?

Furthermore, I use Microsoft Visual Studio. The "Getting started with 
MVC" documents for release 2.8 say "To emphasize, there is no C/C++ 
front end currently available" but I had no problems compiling and using 
clang so far. Have I just been lucky and didn't hit a problem so far 
(but will probably do so, as soon as I compile more complex things)? Or 
is clang working fine for my use case (converting C++ to C)?

Ciao,
Jonas

From ofv at wanadoo.es  Mon Jan 10 16:09:57 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Mon, 10 Jan 2011 23:09:57 +0100
Subject: [LLVMdev] Current state of the (new) CBackend & LLVM/clang with
	Microsoft Visual Studio
References: <4D2B80FC.1000608@schrieb.de>
Message-ID: <87vd1wfm16.fsf@wanadoo.es>

Jonas Gefele <llvm.org at schrieb.de> writes:

> Furthermore, I use Microsoft Visual Studio. The "Getting started with 
> MVC" documents for release 2.8 say "To emphasize, there is no C/C++ 
> front end currently available" but I had no problems compiling and using 
> clang so far. Have I just been lucky and didn't hit a problem so far 
> (but will probably do so, as soon as I compile more complex things)? Or 
> is clang working fine for my use case (converting C++ to C)?

Here, using the stdlib (std::vector, iostreams, etc) generates long rows
of errors. VS10.


From jasonwkim at google.com  Mon Jan 10 16:59:19 2011
From: jasonwkim at google.com (Jason Kim)
Date: Mon, 10 Jan 2011 14:59:19 -0800
Subject: [LLVMdev] ARM/MC/ELF Support for pcrel movw/movt coming soon
Message-ID: <AANLkTimudSvinrPEk44K3R4VQO3mnfFAg6kYNjsxvCsY@mail.gmail.com>

Hi everyone, happy new year.

This note is to announce that support for PC relative reloc tags for
movw/movt is nearing completion (hopefully <48hrs!). This work is is
from Jan Voung, David Meyer and myself.

Unfortunately, to test this change, we need to patch ARM/AsmParser to
address http://llvm.org/bugs/show_bug.cgi?id=8721
Locally, we have hacked up a solution to 8721, but its not ideal since
VK_ARM_HI16 and VK_ARM_LO16 should apply to any MCExpr, not just
MCSymbolRef like it is now.
The proper fix to 8721 looks to be nontrivial, so what I will do is
commit the "hack" patch to 8721 separately, and then the main patch,
as 8721 is blocking the testing.
The interim hack for 8721 can then be rolled back separately once
someone (ddunbar? pdox? me? :) get around to refactoring MCExpr so
that :lower16: and :upper16: can apply to arbitrary expressions.

Thanks
-jason

From renato.golin at arm.com  Mon Jan 10 17:21:37 2011
From: renato.golin at arm.com (Renato Golin)
Date: Mon, 10 Jan 2011 23:21:37 +0000
Subject: [LLVMdev] ARM/MC/ELF Support for pcrel movw/movt coming soon
In-Reply-To: <AANLkTimudSvinrPEk44K3R4VQO3mnfFAg6kYNjsxvCsY@mail.gmail.com>
References: <AANLkTimudSvinrPEk44K3R4VQO3mnfFAg6kYNjsxvCsY@mail.gmail.com>
Message-ID: <AANLkTin-tYTVGzoMJ7xyS0BUGZ2_aha9igzKqQiyvsMa@mail.gmail.com>

On 10 January 2011 22:59, Jason Kim <jasonwkim at google.com> wrote:
> Hi everyone, happy new year.
>
> This note is to announce that support for PC relative reloc tags for
> movw/movt is nearing completion (hopefully <48hrs!). This work is is
> from Jan Voung, David Meyer and myself.

Hi Jason,

Happy new year!

That seems a long patch... with many changes... can't wait for it. ;)

Btw, I know this is for ELF printing, but can the same infrastructure
you're using to print the hi/lo be used to print relocation in Asm
output? Or is this a completely separate subject?

cheers,
--renato

From jasonwkim at google.com  Mon Jan 10 17:54:26 2011
From: jasonwkim at google.com (Jason Kim)
Date: Mon, 10 Jan 2011 15:54:26 -0800
Subject: [LLVMdev] ARM/MC/ELF Support for pcrel movw/movt coming soon
In-Reply-To: <AANLkTin-tYTVGzoMJ7xyS0BUGZ2_aha9igzKqQiyvsMa@mail.gmail.com>
References: <AANLkTimudSvinrPEk44K3R4VQO3mnfFAg6kYNjsxvCsY@mail.gmail.com>
	<AANLkTin-tYTVGzoMJ7xyS0BUGZ2_aha9igzKqQiyvsMa@mail.gmail.com>
Message-ID: <AANLkTin7xFZAvBrTb9vgxv8SYAUz=BzELsso=EXzBF-e@mail.gmail.com>

-llvmcommits

On Mon, Jan 10, 2011 at 3:21 PM, Renato Golin <renato.golin at arm.com> wrote:
> Btw, I know this is for ELF printing, but can the same infrastructure
> you're using to print the hi/lo be used to print relocation in Asm
> output? Or is this a completely separate subject?

Hi Renato,
If I am understanding you correctly, then the answer is no, because .s
output doesn't care about relocations per se... BUT..
its also yes because sometimes, the asmwriter will sometimes need to
generate sequences like below

foo:
   movw r0, :lower16:bar-foo
   movt r0, :upper16:bar-foo

The subtraction implies that the value bar-foo is implicitly
pc-relative (at least according to GNU as).

Thanks!

-jason

From venkatra at cs.wisc.edu  Mon Jan 10 22:50:45 2011
From: venkatra at cs.wisc.edu (Venkatraman Govindaraju)
Date: Mon, 10 Jan 2011 22:50:45 -0600
Subject: [LLVMdev] Unreachable executed with fast Regalloc and Sparc
	backend
In-Reply-To: <79ABF6DF-BB99-45ED-9015-6B17847F40B8@wesleypeck.com>
References: <AANLkTi=7Oo2NPB3J=X0tTL+RiNTV=ichOHQZO-UQRLDO@mail.gmail.com>
	<79ABF6DF-BB99-45ED-9015-6B17847F40B8@wesleypeck.com>
Message-ID: <AANLkTimZvhbab-CtFO-y440VerqOYT5xXFyYyO8_mx7_@mail.gmail.com>

Thank you and I will modify call instruction to use variable_ops and
see whether it works for SPARC backend.

Thanks,
Venkatraman

On Fri, Jan 7, 2011 at 6:56 PM, Wesley Peck <peckw at wesleypeck.com> wrote:
> On Jan 7, 2011, at 2:36 PM, Venkatraman Govindaraju wrote:
>> When I run LLC with option "-O0 -march=sparc" on following testcase,
>> fast register allocator crashes with "UNREACHABLE executed" error. LLC
>> generates code successfully with other standard register allocators
>> available.
>
> I haven't investigated the Sparc backend specifically but...
>
> My guess is this is related to this entry in SparcInstrInfo.td:
> ? ?let Uses = [O0, O1, O2, O3, O4, O5],
> ? ? ? ?hasDelaySlot = 1, isCall = 1,
> ? ? ? ?Defs = [O0, O1, O2, O3, O4, O5, O7, G1, G2, G3, G4, G5, G6, G7,
> ? ? ? ?D0, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15] in {
> ? ? ?def CALL : InstSP<(outs), (ins calltarget:$dst),
> ? ? ? ? ? ? ? ? ? ? ? ?"call $dst", []> {
> ? ? ? ?bits<30> disp;
> ? ? ? ?let op = 1;
> ? ? ? ?let Inst{29-0} = disp;
> ? ? ?}
>
> The Uses=[O0,O1,O2,O3,O4,O5] is causing this crash (and similar crashes in the PQBP and Greedy allocators if I remember right). I fixed this in the MicroBlaze backend by remodeling the call instructions to be variadic like other backends. See the MBlazeInstrInfo.td changes in this commit:
> http://www.llvm.org/viewvc/llvm-project?view=rev&revision=121994
>
> NOTE: In the commit R1 is the dedicated stack register on the MicroBlaze architecture.
>
> --
> Wesley Peck
> University of Kansas
> SLDG Laboratory
>
>


From shigoto.shin at gmail.com  Mon Jan 10 23:59:03 2011
From: shigoto.shin at gmail.com (Shin)
Date: Mon, 10 Jan 2011 21:59:03 -0800
Subject: [LLVMdev] VMKit link
Message-ID: <AANLkTikfne5dLm1XsAuKgOHDp20r+zo7XV6T0cbtRV+7@mail.gmail.com>

Hi all,

I am trying to build VMKit on Linux/x86 and I got error messages like below,

llvm[1]: Linking Debug+Asserts executable vmjc
/root/llvm/vmkit/tools/vmjc/Debug+Asserts/vmjc.o: In function
`mvm::SpinLock::acquire()':
/root/llvm/vmkit/include/mvm/Threads/Locks.h:164: undefined reference
to `__sync_val_compare_and_swap_4'
/root/llvm/vmkit/include/mvm/Threads/Locks.h:168: undefined reference
to `__sync_val_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libJ3.a(JavaClass.o): In function
`j3::Class::resolveClass()':
/root/llvm/vmkit/lib/J3/VMCore/JavaClass.cpp:941: undefined reference
to `__sync_val_compare_and_swap_1'
/root/llvm/vmkit/Debug+Asserts/lib/libJ3.a(JavaObject.o): In function
`j3::JavaObject::hashCode(j3::JavaObject*)':
/root/llvm/vmkit/lib/J3/VMCore/JavaObject.cpp:59: undefined reference
to `__sync_val_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libClasspath.a(JavaUpcalls.o): In
function `Java_sun_misc_Unsafe_compareAndSwapInt':
/root/llvm/vmkit/lib/J3/Classpath/Classpath.inc:322: undefined
reference to `__sync_bool_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libClasspath.a(JavaUpcalls.o): In
function `mvm::Collector::objectReferenceTryCASBarrier(gc*, gc**, gc*,
gc*)':
/root/llvm/vmkit/lib/Mvm/GCMmap2/MvmGC.h:375: undefined reference to
`__sync_val_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libJ3Compiler.a(JavaJITCompiler.o):
In function `j3::JavaJ3LazyJITCompiler::addCallback(j3::Class*,
unsigned short, j3::Signdef*, bool, llvm::BasicBlock*)':
/root/llvm/vmkit/lib/J3/Compiler/JavaJITCompiler.cpp:454: undefined
reference to `__sync_val_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libCommonThread.a(CollectionRV.o):
In function `mvm::CooperativeCollectionRV::synchronize()':
/root/llvm/vmkit/lib/Mvm/CommonThread/CollectionRV.cpp:66: undefined
reference to `__sync_bool_compare_and_swap_1'
/root/llvm/vmkit/Debug+Asserts/lib/libCommonThread.a(ObjectLocks.o):
In function `mvm::ThinLock::removeFatLock(mvm::FatLock*,
mvm::LockSystem&)':
/root/llvm/vmkit/lib/Mvm/CommonThread/ObjectLocks.cpp:56: undefined
reference to `__sync_val_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libCommonThread.a(ObjectLocks.o):
In function `mvm::ThinLock::release(gc*, mvm::LockSystem&)':
/root/llvm/vmkit/lib/Mvm/CommonThread/ObjectLocks.cpp:203: undefined
reference to `__sync_val_compare_and_swap_4'
/root/llvm/vmkit/lib/Mvm/CommonThread/ObjectLocks.cpp:215: undefined
reference to `__sync_val_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libCommonThread.a(ObjectLocks.o):
In function `mvm::ThinLock::changeToFatlock(gc*, mvm::LockSystem&)':
/root/llvm/vmkit/lib/Mvm/CommonThread/ObjectLocks.cpp:76: undefined
reference to `__sync_val_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libCommonThread.a(ObjectLocks.o):
In function `mvm::ThinLock::overflowThinLock(gc*, mvm::LockSystem&)':
/root/llvm/vmkit/lib/Mvm/CommonThread/ObjectLocks.cpp:39: undefined
reference to `__sync_val_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libCommonThread.a(ObjectLocks.o):/root/llvm/vmkit/lib/Mvm/CommonThread/ObjectLocks.cpp:120:
more undefined references to `__sync_val_compare_and_swap_4' follow
/root/llvm/vmkit/Debug+Asserts/lib/libCommonThread.a(ctthread.o): In
function `mvm::Thread::leaveUncooperativeCode()':
/root/llvm/vmkit/lib/Mvm/CommonThread/ctthread.cpp:273: undefined
reference to `__sync_bool_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libCommonThread.a(ctthread.o): In
function `mvm::Thread::enterUncooperativeCode(void*)':
/root/llvm/vmkit/lib/Mvm/CommonThread/ctthread.cpp:260: undefined
reference to `__sync_bool_compare_and_swap_4'
/root/llvm/vmkit/Debug+Asserts/lib/libCommonThread.a(ctthread.o): In
function `mvm::Thread::enterUncooperativeCode(unsigned int)':
/root/llvm/vmkit/lib/Mvm/CommonThread/ctthread.cpp:248: undefined
reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
make[1]: *** [/root/llvm/vmkit/Debug+Asserts/bin/vmjc] Error 1
make[1]: Leaving directory `/root/llvm/vmkit/tools/vmjc'
make: *** [all] Error 1

Please help.

Thank you.

Shin

From chenwj at iis.sinica.edu.tw  Tue Jan 11 02:01:32 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Tue, 11 Jan 2011 16:01:32 +0800
Subject: [LLVMdev] VMKit link
In-Reply-To: <AANLkTikfne5dLm1XsAuKgOHDp20r+zo7XV6T0cbtRV+7@mail.gmail.com>
References: <AANLkTikfne5dLm1XsAuKgOHDp20r+zo7XV6T0cbtRV+7@mail.gmail.com>
Message-ID: <20110111080132.GA2356@cs.nctu.edu.tw>

Hi,

  I guess you miss "-lpthread"?

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From nicolas.geoffray at gmail.com  Tue Jan 11 03:00:44 2011
From: nicolas.geoffray at gmail.com (nicolas geoffray)
Date: Tue, 11 Jan 2011 10:00:44 +0100
Subject: [LLVMdev] VMKit link
In-Reply-To: <20110111080132.GA2356@cs.nctu.edu.tw>
References: <AANLkTikfne5dLm1XsAuKgOHDp20r+zo7XV6T0cbtRV+7@mail.gmail.com>
	<20110111080132.GA2356@cs.nctu.edu.tw>
Message-ID: <AANLkTimWK74FyVeCJkiPmqQwyNXSyUq+XX2R2WvYsCT3@mail.gmail.com>

Hi Shen,

Also make sure your version of gcc is at least 4.2 (4.0 does not work with
atomic builtins IIRC), and that you're compiling for something at least i486
(i386 does not have the atomic builtins support).

Nicolas

On Tue, Jan 11, 2011 at 9:01 AM, ??? <chenwj at iis.sinica.edu.tw> wrote:

> Hi,
>
>  I guess you miss "-lpthread"?
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (???)
> Parallel Processing Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110111/11524883/attachment.html 

From renato.golin at arm.com  Tue Jan 11 03:06:04 2011
From: renato.golin at arm.com (Renato Golin)
Date: Tue, 11 Jan 2011 09:06:04 +0000
Subject: [LLVMdev] ARM/MC/ELF Support for pcrel movw/movt coming soon
In-Reply-To: <AANLkTin7xFZAvBrTb9vgxv8SYAUz=BzELsso=EXzBF-e@mail.gmail.com>
References: <AANLkTimudSvinrPEk44K3R4VQO3mnfFAg6kYNjsxvCsY@mail.gmail.com>
	<AANLkTin-tYTVGzoMJ7xyS0BUGZ2_aha9igzKqQiyvsMa@mail.gmail.com>
	<AANLkTin7xFZAvBrTb9vgxv8SYAUz=BzELsso=EXzBF-e@mail.gmail.com>
Message-ID: <AANLkTikwRCF4Y2hAAKin5Ksja_WtW8H1_=Pu9-aJUafy@mail.gmail.com>

On 10 January 2011 23:54, Jason Kim <jasonwkim at google.com> wrote:
> If I am understanding you correctly, then the answer is no, because .s
> output doesn't care about relocations per se...

Hi Jason,

That's not entirely true. ;) If you only use the GNU toolchain, that
is correct. However, CodeSourcery's GCC changed a bit on how it works
for ARM because the ARM toolchain is a bit more strict in build
attributes and relocation information.

The static constructor symbol relocation (target1) and exception
handling table symbols (prel31) are clearly disregarded by gas and
subsequently discarded by armlink.


> its also yes because sometimes, the asmwriter will sometimes need to
> generate sequences like below
>
> foo:
> ? movw r0, :lower16:bar-foo
> ? movt r0, :upper16:bar-foo
>
> The subtraction implies that the value bar-foo is implicitly
> pc-relative (at least according to GNU as).

That was the other part of my question: will your new
MC-relocationator also print the current ASM relocations? ;)

cheers,
--renato


From rcsaba at gmail.com  Tue Jan 11 05:02:06 2011
From: rcsaba at gmail.com (Csaba Raduly)
Date: Tue, 11 Jan 2011 12:02:06 +0100
Subject: [LLVMdev] clang+LLVM fails to compile ctags
Message-ID: <AANLkTiksNboSr9TdKp2RY2jd=YHG9FnmD3btRJym_Tgn@mail.gmail.com>

clang version 2.9 (trunk 123166)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Fails to compile ctags 5.8 (also 5.6), specifically eiffel.c:

$ clang  -v -c e.c -O2 -Wno-unused-value
clang version 2.9 (trunk 123166)
Target: x86_64-unknown-linux-gnu
Thread model: posix
 "/home/csaba/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu
-emit-obj -disable-free -main-file-name e.c -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 11.3 -v -resource-dir
/home/csaba/bin/../lib/clang/2.9 -O2 -Wno-unused-value -ferror-limit
19 -fmessage-length 207 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o e.o -x c e.c
clang -cc1 version 2.9 based upon llvm 2.9svn hosted on x86_64-unknown-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /home/csaba/bin/../lib/clang/2.9/include
 /usr/include
End of search list.
clang: /home/csaba/LLVM/llvm/lib/Transforms/Scalar/LoopRotation.cpp:343:
bool<unnamed>::LoopRotate::rotateLoop(llvm::Loop*): Assertion `DidIt
&& "Block merge failed??"' failed.
0  clang           0x00000000019cbeaf
1  clang           0x00000000019cc9ea
2  libpthread.so.0 0x00007f23a40982e0
3  libc.so.6       0x00007f23a33e09e5 gsignal + 53
4  libc.so.6       0x00007f23a33e1ee6 abort + 390
5  libc.so.6       0x00007f23a33d9235 __assert_fail + 245
6  clang           0x0000000001645767
7  clang           0x0000000001645881
8  clang           0x00000000017d7d67
llvm::LPPassManager::runOnFunction(llvm::Function&) + 1287
9  clang           0x0000000001901937
llvm::FPPassManager::runOnFunction(llvm::Function&) + 599
10 clang           0x000000000178386d
11 clang           0x00000000019014c7
llvm::MPPassManager::runOnModule(llvm::Module&) + 551
12 clang           0x0000000001901617
llvm::PassManagerImpl::run(llvm::Module&) + 167
13 clang           0x00000000007a6f27
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions
const&, clang::TargetOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 2167
14 clang           0x00000000007a3ffb
15 clang           0x00000000009135ed clang::ParseAST(clang::Sema&, bool) + 301
16 clang           0x00000000007a4d74 clang::CodeGenAction::ExecuteAction() + 68
17 clang           0x0000000000683c15
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357
18 clang           0x000000000065d74a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1242
19 clang           0x0000000000653533 cc1_main(char const**, char
const**, char const*, void*) + 707
20 clang           0x000000000065c783 main + 5267
21 libc.so.6       0x00007f23a33ccb7d __libc_start_main + 253
22 clang           0x0000000000653089
Stack dump:
0.      Program arguments: /home/csaba/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name e.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64
-target-linker-version 11.3 -v -resource-dir
/home/csaba/bin/../lib/clang/2.9 -O2 -Wno-unused-value -ferror-limit
19 -fmessage-length 207 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o e.o -x c e.c
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'CallGraph Pass Manager' on module 'e.c'.
4.      Running pass 'Loop Pass Manager' on function '@findEiffelTags'
5.      Running pass 'Rotate Loops' on basic block '%while.cond'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to
see invocation)

I have a preprocessor output from which I commented out parts while
still showing the error. Wher should I send it?

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

From baldrick at free.fr  Tue Jan 11 05:41:32 2011
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 11 Jan 2011 12:41:32 +0100
Subject: [LLVMdev] DragonEgg on FreeBSD
In-Reply-To: <20110109032833.GA50410@cs.nctu.edu.tw>
References: <20110108042315.GA3945@cs.nctu.edu.tw> <4D286952.4040107@free.fr>
	<20110109032833.GA50410@cs.nctu.edu.tw>
Message-ID: <4D2C41EC.3000802@free.fr>

Hi chenwj,

>    I only tested dragonegg on simple HelloWorld C/C++ programs. It can emit LLVM IR and
> generate a runable executable.

thanks for the info.

>    On FreeBSD, Makefile need to be modified to include a path to gmp.h
> header file. I give a patch here,

You can get the same effect by doing:

   CPPFLAGS=-I/usr/local/include gmake

>    And you should make a freebsd directory and copy linux/llvm-os.h to
> there.
>
> --------------------------------------------------------------------------------
> $ mkdir freebsd
> $ cp linux/llvm-os.h freebsd/
> --------------------------------------------------------------------------------

I've added freebsd/llvm-os.h to the repository.  I didn't copy the linux version
because I'm not sure that the definition of LLVM_SET_TARGET_OPTIONS is correct
for freebsd.  Since llvm-gcc doesn't set anything for freebsd, I didn't either.

>
>    Finally, use "gmake" not "make" on FreeBSD to build dragonegg.so.

OK.

>    Well, there are warings while building dragonegg.so. But I guess it
> doesn't affect dragonegg.so, I just leave it there. Here are the
> warnings.
>
> --------------------------------------------------------------------------------
> <command-line>: warning: "__STDC_LIMIT_MACROS" redefined
> <command-line>: warning: this is the location of the previous definition
> --------------------------------------------------------------------------------

This is harmless: __STDC_LIMIT_MACROS is defined twice (the same each time) on
the command line.  I'm not sure it is worth fixing, especially as recent
versions of gcc don't warn about this.

Ciao,

Duncan.

From benny.kra at googlemail.com  Tue Jan 11 06:06:20 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Tue, 11 Jan 2011 13:06:20 +0100
Subject: [LLVMdev] clang+LLVM fails to compile ctags
In-Reply-To: <AANLkTiksNboSr9TdKp2RY2jd=YHG9FnmD3btRJym_Tgn@mail.gmail.com>
References: <AANLkTiksNboSr9TdKp2RY2jd=YHG9FnmD3btRJym_Tgn@mail.gmail.com>
Message-ID: <35D4860D-33F0-4F05-8990-8C66DBA2155D@gmail.com>


On 11.01.2011, at 12:02, Csaba Raduly wrote:

> clang version 2.9 (trunk 123166)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> 
> Fails to compile ctags 5.8 (also 5.6), specifically eiffel.c:
> 
> $ clang  -v -c e.c -O2 -Wno-unused-value
> clang version 2.9 (trunk 123166)
[?]
> bool<unnamed>::LoopRotate::rotateLoop(llvm::Loop*): Assertion `DidIt
> && "Block merge failed??"' failed.

This looks very similar to http://llvm.org/bugs/show_bug.cgi?id=8955 which was a
recent regression and was fixed in r123219.



From rcsaba at gmail.com  Tue Jan 11 06:38:10 2011
From: rcsaba at gmail.com (Csaba Raduly)
Date: Tue, 11 Jan 2011 13:38:10 +0100
Subject: [LLVMdev] clang+LLVM fails to compile ctags
In-Reply-To: <35D4860D-33F0-4F05-8990-8C66DBA2155D@gmail.com>
References: <AANLkTiksNboSr9TdKp2RY2jd=YHG9FnmD3btRJym_Tgn@mail.gmail.com>
	<35D4860D-33F0-4F05-8990-8C66DBA2155D@gmail.com>
Message-ID: <AANLkTi=n2gH7Vnm+KmxZGZe-OMvBhSQEbhtRUSNhOGBU@mail.gmail.com>

On Tue, Jan 11, 2011 at 1:06 PM, Benjamin Kramer wrote:
>
> On 11.01.2011, at 12:02, Csaba Raduly wrote:
>
>> clang version 2.9 (trunk 123166)
>> Target: x86_64-unknown-linux-gnu
>> Thread model: posix
>>
>> Fails to compile ctags 5.8 (also 5.6), specifically eiffel.c:
>>
>> $ clang ?-v -c e.c -O2 -Wno-unused-value
>> clang version 2.9 (trunk 123166)
> [?]
>> bool<unnamed>::LoopRotate::rotateLoop(llvm::Loop*): Assertion `DidIt
>> && "Block merge failed??"' failed.
>
> This looks very similar to http://llvm.org/bugs/show_bug.cgi?id=8955 which was a
> recent regression and was fixed in r123219.

You are right, that fixed it, thanks.

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds


From bijoy123_8 at yahoo.com  Tue Jan 11 09:57:34 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Tue, 11 Jan 2011 07:57:34 -0800 (PST)
Subject: [LLVMdev] --with-arch options in LLVM-GCC for ARM target
Message-ID: <139436.93943.qm@web121702.mail.ne1.yahoo.com>

Hi,
??? I am able to crosscompile llvm-gcc using --with-arch=armv6 but cannot using --with-arch=armv5. Can anyone please tell me what option i should use to crosscIompile for the architecture armv5te (xscale processor). I heard that by default arm 5 code generates, will that work on my target (armv5te)? I get the following when I use --with-arch=armv5 :
?
?
D:/DOCUME~2/AZIM/LOCALS~1/Temp/ccS4shon.s:19245: Error: bad immediate value for offset value
?
make[2]: *** [cplus-dem.o] Error 1
?
Thanks,
Akramul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110111/0ca54e9b/attachment.html 

From clattner at apple.com  Tue Jan 11 10:54:31 2011
From: clattner at apple.com (Chris Lattner)
Date: Tue, 11 Jan 2011 08:54:31 -0800
Subject: [LLVMdev] TableGen Operator Names
In-Reply-To: <nngpqs8bp64.fsf@royale.us.cray.com>
References: <nngpqs8bp64.fsf@royale.us.cray.com>
Message-ID: <DAB73736-AB7E-4835-B3A2-A27B5A9614A7@apple.com>

On Jan 7, 2011, at 9:26 AM, David Greene wrote:
> I just submitted a change to TableGen to make the lisp-like operator
> names more readable (as suggested by Gabor a very long time ago).

Thanks for doing this!

> I would also like to change the way operators are invoked.  As I keep
> adding more functionality, the bang invocation syntax is making things
> hard to read.  For example:
> 
> !if(!empty(arg),then,else)
> 
> Does this mean "if empty," "if not empty" or "not if not empty?"  It's
> the first but that's less than obvious.
> 
> Would anyone object if I changed the syntax from !operator to &operator?

In the absence of a much better proposal, I'd prefer to just keep it the way it is.

-Chris



From vmle at ucdavis.edu  Tue Jan 11 12:41:49 2011
From: vmle at ucdavis.edu (Vu Le)
Date: Tue, 11 Jan 2011 10:41:49 -0800
Subject: [LLVMdev] Unit testing with random input using JIT
Message-ID: <AANLkTikbaBGJQ8mVH6CmxsJ7nU1cx75O=+u-3+7fTjSa@mail.gmail.com>

Hi,
I want to implement a tool that probes a function with several input and
records all the return output.
The function might have more than 1 return value (by reference parameters).

Does ExecutionEngine::runFunction() support function call with complex
argument type?
If not, I guess that I have to create a wrapper function, prepare all the
data, and call the original function.
Am I on the right track?

Thanks a lot.
Vu Le
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110111/40ee78b2/attachment.html 

From dag at cray.com  Tue Jan 11 14:27:48 2011
From: dag at cray.com (David A. Greene)
Date: Tue, 11 Jan 2011 14:27:48 -0600
Subject: [LLVMdev] TableGen Operator Names
In-Reply-To: <DAB73736-AB7E-4835-B3A2-A27B5A9614A7@apple.com> (Chris Lattner's
	message of "Tue, 11 Jan 2011 10:54:31 -0600")
References: <nngpqs8bp64.fsf@royale.us.cray.com>
	<DAB73736-AB7E-4835-B3A2-A27B5A9614A7@apple.com>
Message-ID: <nngfwsz6v97.fsf@royale.us.cray.com>

Chris Lattner <clattner at apple.com> writes:

>> Would anyone object if I changed the syntax from !operator to &operator?
>
> In the absence of a much better proposal, I'd prefer to just keep it the way it is.

Fair enough.  What would make a better proposal?  I'd like to keep the
syntax concise.  I wonder if there is a way we could get rid of the
"operator" entirely and just specify names, like:

strconcat("this", "that")

instead of 

!strconcat("this", "that")

What do you think?

                             -Dave

From jasonwkim at google.com  Tue Jan 11 15:47:30 2011
From: jasonwkim at google.com (Jason Kim)
Date: Tue, 11 Jan 2011 13:47:30 -0800
Subject: [LLVMdev] ARM/MC/ELF Support for pcrel movw/movt coming soon
In-Reply-To: <AANLkTikwRCF4Y2hAAKin5Ksja_WtW8H1_=Pu9-aJUafy@mail.gmail.com>
References: <AANLkTimudSvinrPEk44K3R4VQO3mnfFAg6kYNjsxvCsY@mail.gmail.com>
	<AANLkTin-tYTVGzoMJ7xyS0BUGZ2_aha9igzKqQiyvsMa@mail.gmail.com>
	<AANLkTin7xFZAvBrTb9vgxv8SYAUz=BzELsso=EXzBF-e@mail.gmail.com>
	<AANLkTikwRCF4Y2hAAKin5Ksja_WtW8H1_=Pu9-aJUafy@mail.gmail.com>
Message-ID: <AANLkTi=rdusx3DS3PDCbMVX9QtXPdGZZKG8ARe0y9UNh@mail.gmail.com>

On Tue, Jan 11, 2011 at 1:06 AM, Renato Golin <renato.golin at arm.com> wrote:
> That was the other part of my question: will your new
> MC-relocationator also print the current ASM relocations? ;)

Doesn't look like AsmParser understands RELOC command yet. Sorry:-(

>
> cheers,
> --renato
>

From reid.kleckner at gmail.com  Tue Jan 11 16:40:06 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Tue, 11 Jan 2011 17:40:06 -0500
Subject: [LLVMdev] Unit testing with random input using JIT
In-Reply-To: <AANLkTikbaBGJQ8mVH6CmxsJ7nU1cx75O=+u-3+7fTjSa@mail.gmail.com>
References: <AANLkTikbaBGJQ8mVH6CmxsJ7nU1cx75O=+u-3+7fTjSa@mail.gmail.com>
Message-ID: <AANLkTi=kPAekc2qhJ6vdKwQWeoji3JjEMD6XTe3he6wN@mail.gmail.com>

On Tue, Jan 11, 2011 at 1:41 PM, Vu Le <vmle at ucdavis.edu> wrote:
> Hi,
> I want to implement a tool that probes a function with several input and
> records all the return output.
> The function might have more than 1 return value (by reference parameters).
>
> Does ExecutionEngine::runFunction() support function call with complex
> argument type?
> If not, I guess that I have to create a wrapper function, prepare all the
> data, and call the original function.
> Am I on the right track?

For functions with complicated parameters and return values,
runFunction will generate a wrapper function that calls the function
with the right arguments.  This is fairly expensive and leaks memory
if called more than once for the same function.  If the type of the
function is known, you can just use getPointerToFunction, cast that,
and call it from C.

If it's not known but you want to call it many times with different
arguments, you could generate a wrapper function responsible for
unpacking your own datastructure describing the arguments and calling
the function you are testing with those arguments.  Seems like you are
on the right track there.

Reid

From javagrande2 at gmail.com  Tue Jan 11 16:56:25 2011
From: javagrande2 at gmail.com (JG)
Date: Tue, 11 Jan 2011 14:56:25 -0800
Subject: [LLVMdev] PostRAScheduling for x86
Message-ID: <AANLkTimvY2ywS65CH6qEpDpV+vWw33A7ia+mWz2K-sQ5@mail.gmail.com>

I am trying to understand why PostRAScheduling is done only for ARM. Is
there any limitation which prevents this from being done for x86 ?

Thanks,

Karthik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110111/ecdf61db/attachment.html 

From stoklund at 2pi.dk  Tue Jan 11 17:00:34 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Tue, 11 Jan 2011 15:00:34 -0800
Subject: [LLVMdev] PostRAScheduling for x86
In-Reply-To: <AANLkTimvY2ywS65CH6qEpDpV+vWw33A7ia+mWz2K-sQ5@mail.gmail.com>
References: <AANLkTimvY2ywS65CH6qEpDpV+vWw33A7ia+mWz2K-sQ5@mail.gmail.com>
Message-ID: <102D99A6-E64D-40EE-9D79-F4E994E61A93@2pi.dk>


On Jan 11, 2011, at 2:56 PM, JG wrote:

> I am trying to understand why PostRAScheduling is done only for ARM. Is there any limitation which prevents this from being done for x86 ?

It's a 10% increase in overall compile time, and it does not help very much for x86.

The out-of-order execution on new x86 chips hide any benefits from late scheduling.

/jakob



From rob.nikander at gmail.com  Tue Jan 11 18:16:39 2011
From: rob.nikander at gmail.com (Rob Nikander)
Date: Tue, 11 Jan 2011 19:16:39 -0500
Subject: [LLVMdev] using llvm as library from xcode project?
Message-ID: <AANLkTinUipLjtOOQWU+jV+gPKwk8e=518KsPbDrJsU2x@mail.gmail.com>

Hi all,

I just downloaded and compiled LLVM and I'd like to use the JIT API in
a project that I've got in Xcode. ?I'm confused because I thought I
could use LLVM like a library, but it seems I can't simply include
some headers and link to lib, as usual.  Or can I?  I don't see a
framework or dylib file, which I would usually add to my Xcode
project.  The /usr/local/lib directory has a bunch of .a files.

This page (http://llvm.org/docs/Projects.html) suggests that I need to
learn about the LLVM build system.   If so, why?

I tried simply adding all the .a files in /usr/local/lib, but my
programs fails at:

    engine = EngineBuilder(module).setErrorStr(&err).create();

The 'engine' is null, and 'err' is "Interpreter has not been linked in.".

thanks,
Rob


From yuri at rawbw.com  Tue Jan 11 18:50:33 2011
From: yuri at rawbw.com (Yuri)
Date: Tue, 11 Jan 2011 16:50:33 -0800
Subject: [LLVMdev] Wrong assembly is written for x86_64 target in JIT
	without optimization?
Message-ID: <4D2CFAD9.8010301@rawbw.com>

When I try running one llvm function in JIT without optimization I get 
SEGV. Looking at assembly (below) I see that the local value 
0xffffffffffffffe0(%rbp) is used without being ever initialized (see my 
comment in asm).
Same code on i386 works fine, with and w/out optimization.

My guess is that this is a bug in LLVM.

Yuri

--- llvm ---
%struct.mystruct = type { i32, i8, i8, i8, i8 }

define i32 @xfunc(%struct.mystruct* %a1, %struct.mystruct* %a2) {
   br label %lbl1
lbl1:
   %v1 = call i32 @yfunc(i32 1, i32 0, i32 0)
   %v2 = bitcast %struct.mystruct* %a1 to i8*
   %v3 = getelementptr i8* %v2, i32 %v1
   %v4 = bitcast i8* %v3 to i32*
   %v5 = load i32* %v4
   %v6 = call i32 @yfunc(i32 1, i32 4, i32 0)
   %v7 = bitcast %struct.mystruct* %a2 to i8*
   %v8 = getelementptr i8* %v7, i32 %v6
   %v9 = bitcast i8* %v8 to i32*
   %v10 = load i32* %v9
   %op.dual.plus.uint32 = add i32 %v5, %v10
   br label %lbl2
lbl2:
   ret i32 %op.dual.plus.uint32
}

declare i32 @yfunc(i32, i32, i32)


--- assembly obtained in gdb for JITted code ---
     0x0000000800989bf0:     push   %rbp
     0x0000000800989bf1:     mov    %rsp,%rbp
     0x0000000800989bf4:     sub    $0x30,%rsp
     0x0000000800989bf8:     mov    %rdi,0xfffffffffffffff8(%rbp)
     0x0000000800989bfc:     mov    %rsi,0xfffffffffffffff0(%rbp)
     0x0000000800989c00:     mov    $0x1,%edi
     0x0000000800989c05:     xor    %eax,%eax
     0x0000000800989c07:     mov    $0x800a09060,%rcx
     0x0000000800989c11:     mov    %eax,%esi
     0x0000000800989c13:     mov    %eax,%edx
     0x0000000800989c15:     callq  *%ecx
     0x0000000800989c17:     movslq %eax,%rcx
     0x0000000800989c1a:     mov    0xfffffffffffffff8(%rbp),%r8
     0x0000000800989c1e:     mov    (%r8,%rcx,1),%eax
     0x0000000800989c22:     mov    $0x1,%edi
     0x0000000800989c27:     mov    $0x4,%esi
     0x0000000800989c2c:     xor    %edx,%edx
     0x0000000800989c2e:     mov    $0x800a09060,%rcx
     0x0000000800989c38:     mov    %eax,0xffffffffffffffec(%rbp)
     0x0000000800989c3b:     callq  *%ecx
     0x0000000800989c3d:     mov    0xffffffffffffffec(%rbp),%edx
     0x0000000800989c40:     mov    0xfffffffffffffff0(%rbp),%rcx
     0x0000000800989c44:     mov    0xffffffffffffffe0(%rbp),%r8  ; XXX 
use of uninitialized value
     0x0000000800989c48:     add    (%rcx,%r8,1),%edx             ; SEGV
     0x0000000800989c4c:     movslq %eax,%r8
     0x0000000800989c4f:     mov    %edx,0xffffffffffffffdc(%rbp)
     0x0000000800989c52:     mov    %r8,0xffffffffffffffe0(%rbp)
     0x0000000800989c56:     mov    0xffffffffffffffdc(%rbp),%eax
     0x0000000800989c59:     add    $0x30,%rsp
     0x0000000800989c5d:     pop    %rbp
     0x0000000800989c5e:     retq

--- result after running llvm-as and llc on the same function ---
         subq    $56, %rsp
.Ltmp0:
         movq    %rdi, 48(%rsp)          # 8-byte Spill
         movq    %rsi, 40(%rsp)          # 8-byte Spill
# BB#1:                                 # %lbl1
         movl    $1, %eax
         movl    $4, %esi
         movl    $0, %ecx
         movl    %eax, %edi
         movl    %esi, 36(%rsp)          # 4-byte Spill
         movl    %ecx, %esi
         movl    %ecx, %edx
         movl    %eax, 32(%rsp)          # 4-byte Spill
         movl    %ecx, 28(%rsp)          # 4-byte Spill
         callq   yfunc
         movslq  %eax, %r8
         movq    48(%rsp), %r9           # 8-byte Reload
         movl    (%r9,%r8), %eax
         movl    32(%rsp), %edi          # 4-byte Reload
         movl    36(%rsp), %esi          # 4-byte Reload
         movl    28(%rsp), %edx          # 4-byte Reload
         movl    %eax, 24(%rsp)          # 4-byte Spill
         callq   yfunc
         movl    24(%rsp), %ecx          # 4-byte Reload
         movq    40(%rsp), %r8           # 8-byte Reload
         movq    16(%rsp), %r9           # 8-byte Reload
         addl    (%r8,%r9), %ecx
         movslq  %eax, %r9
         movl    %ecx, 12(%rsp)          # 4-byte Spill
         movq    %r9, 16(%rsp)           # 8-byte Spill
# BB#2:                                 # %lbl2
         movl    12(%rsp), %eax          # 4-byte Reload
         addq    $56, %rsp
         ret


From yuri at rawbw.com  Tue Jan 11 18:57:42 2011
From: yuri at rawbw.com (Yuri)
Date: Tue, 11 Jan 2011 16:57:42 -0800
Subject: [LLVMdev] using llvm as library from xcode project?
In-Reply-To: <AANLkTinUipLjtOOQWU+jV+gPKwk8e=518KsPbDrJsU2x@mail.gmail.com>
References: <AANLkTinUipLjtOOQWU+jV+gPKwk8e=518KsPbDrJsU2x@mail.gmail.com>
Message-ID: <4D2CFC86.7070807@rawbw.com>

On 01/11/2011 16:16, Rob Nikander wrote:
> I just downloaded and compiled LLVM and I'd like to use the JIT API in
> a project that I've got in Xcode.  I'm confused because I thought I
> could use LLVM like a library, but it seems I can't simply include
> some headers and link to lib, as usual.  Or can I?  I don't see a
> framework or dylib file, which I would usually add to my Xcode
> project.  The /usr/local/lib directory has a bunch of .a files.
>
> This page (http://llvm.org/docs/Projects.html) suggests that I need to
> learn about the LLVM build system.   If so, why?
>
> I tried simply adding all the .a files in /usr/local/lib, but my
> programs fails at:
>
>      engine = EngineBuilder(module).setErrorStr(&err).create();
>
> The 'engine' is null, and 'err' is "Interpreter has not been linked in.".
>    

You don't need XCode to compile llvm.
It's best to supply --enable-shared to configure. This will build you 
libLLVM-2.9svn.dylib. This is the only library you need to link your app 
with.

Yuri

From dalej at apple.com  Tue Jan 11 19:07:59 2011
From: dalej at apple.com (Dale Johannesen)
Date: Tue, 11 Jan 2011 17:07:59 -0800
Subject: [LLVMdev] Wrong assembly is written for x86_64 target in
	JIT	without optimization?
In-Reply-To: <4D2CFAD9.8010301@rawbw.com>
References: <4D2CFAD9.8010301@rawbw.com>
Message-ID: <974949FA-5A26-409B-8557-CEF76792BCC0@apple.com>


On Jan 11, 2011, at 4:50 PMPST, Yuri wrote:

> When I try running one llvm function in JIT without optimization I get 
> SEGV. Looking at assembly (below) I see that the local value 
> 0xffffffffffffffe0(%rbp) is used without being ever initialized (see my 
> comment in asm).
> Same code on i386 works fine, with and w/out optimization.
> 
> My guess is that this is a bug in LLVM.
> 
> Yuri

The unitialized load is there in the llc version as well (16(%rsp)).  It looks like it's been erroneously moved ahead of the spill to that slot.  Please file a PR.  (I can see this on Darwin with llc -O0).

> --- llvm ---
> %struct.mystruct = type { i32, i8, i8, i8, i8 }
> 
> define i32 @xfunc(%struct.mystruct* %a1, %struct.mystruct* %a2) {
>   br label %lbl1
> lbl1:
>   %v1 = call i32 @yfunc(i32 1, i32 0, i32 0)
>   %v2 = bitcast %struct.mystruct* %a1 to i8*
>   %v3 = getelementptr i8* %v2, i32 %v1
>   %v4 = bitcast i8* %v3 to i32*
>   %v5 = load i32* %v4
>   %v6 = call i32 @yfunc(i32 1, i32 4, i32 0)
>   %v7 = bitcast %struct.mystruct* %a2 to i8*
>   %v8 = getelementptr i8* %v7, i32 %v6
>   %v9 = bitcast i8* %v8 to i32*
>   %v10 = load i32* %v9
>   %op.dual.plus.uint32 = add i32 %v5, %v10
>   br label %lbl2
> lbl2:
>   ret i32 %op.dual.plus.uint32
> }
> 
> declare i32 @yfunc(i32, i32, i32)
> 
> 
> --- assembly obtained in gdb for JITted code ---
>     0x0000000800989bf0:     push   %rbp
>     0x0000000800989bf1:     mov    %rsp,%rbp
>     0x0000000800989bf4:     sub    $0x30,%rsp
>     0x0000000800989bf8:     mov    %rdi,0xfffffffffffffff8(%rbp)
>     0x0000000800989bfc:     mov    %rsi,0xfffffffffffffff0(%rbp)
>     0x0000000800989c00:     mov    $0x1,%edi
>     0x0000000800989c05:     xor    %eax,%eax
>     0x0000000800989c07:     mov    $0x800a09060,%rcx
>     0x0000000800989c11:     mov    %eax,%esi
>     0x0000000800989c13:     mov    %eax,%edx
>     0x0000000800989c15:     callq  *%ecx
>     0x0000000800989c17:     movslq %eax,%rcx
>     0x0000000800989c1a:     mov    0xfffffffffffffff8(%rbp),%r8
>     0x0000000800989c1e:     mov    (%r8,%rcx,1),%eax
>     0x0000000800989c22:     mov    $0x1,%edi
>     0x0000000800989c27:     mov    $0x4,%esi
>     0x0000000800989c2c:     xor    %edx,%edx
>     0x0000000800989c2e:     mov    $0x800a09060,%rcx
>     0x0000000800989c38:     mov    %eax,0xffffffffffffffec(%rbp)
>     0x0000000800989c3b:     callq  *%ecx
>     0x0000000800989c3d:     mov    0xffffffffffffffec(%rbp),%edx
>     0x0000000800989c40:     mov    0xfffffffffffffff0(%rbp),%rcx
>     0x0000000800989c44:     mov    0xffffffffffffffe0(%rbp),%r8  ; XXX 
> use of uninitialized value
>     0x0000000800989c48:     add    (%rcx,%r8,1),%edx             ; SEGV
>     0x0000000800989c4c:     movslq %eax,%r8
>     0x0000000800989c4f:     mov    %edx,0xffffffffffffffdc(%rbp)
>     0x0000000800989c52:     mov    %r8,0xffffffffffffffe0(%rbp)
>     0x0000000800989c56:     mov    0xffffffffffffffdc(%rbp),%eax
>     0x0000000800989c59:     add    $0x30,%rsp
>     0x0000000800989c5d:     pop    %rbp
>     0x0000000800989c5e:     retq
> 
> --- result after running llvm-as and llc on the same function ---
>         subq    $56, %rsp
> .Ltmp0:
>         movq    %rdi, 48(%rsp)          # 8-byte Spill
>         movq    %rsi, 40(%rsp)          # 8-byte Spill
> # BB#1:                                 # %lbl1
>         movl    $1, %eax
>         movl    $4, %esi
>         movl    $0, %ecx
>         movl    %eax, %edi
>         movl    %esi, 36(%rsp)          # 4-byte Spill
>         movl    %ecx, %esi
>         movl    %ecx, %edx
>         movl    %eax, 32(%rsp)          # 4-byte Spill
>         movl    %ecx, 28(%rsp)          # 4-byte Spill
>         callq   yfunc
>         movslq  %eax, %r8
>         movq    48(%rsp), %r9           # 8-byte Reload
>         movl    (%r9,%r8), %eax
>         movl    32(%rsp), %edi          # 4-byte Reload
>         movl    36(%rsp), %esi          # 4-byte Reload
>         movl    28(%rsp), %edx          # 4-byte Reload
>         movl    %eax, 24(%rsp)          # 4-byte Spill
>         callq   yfunc
>         movl    24(%rsp), %ecx          # 4-byte Reload
>         movq    40(%rsp), %r8           # 8-byte Reload
>         movq    16(%rsp), %r9           # 8-byte Reload
>         addl    (%r8,%r9), %ecx
>         movslq  %eax, %r9
>         movl    %ecx, 12(%rsp)          # 4-byte Spill
>         movq    %r9, 16(%rsp)           # 8-byte Spill
> # BB#2:                                 # %lbl2
>         movl    12(%rsp), %eax          # 4-byte Reload
>         addq    $56, %rsp
>         ret
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110111/f9ee4e32/attachment.html 

From rob.nikander at gmail.com  Tue Jan 11 19:15:53 2011
From: rob.nikander at gmail.com (Rob Nikander)
Date: Tue, 11 Jan 2011 20:15:53 -0500
Subject: [LLVMdev] using llvm as library from xcode project?
In-Reply-To: <4D2CFC86.7070807@rawbw.com>
References: <AANLkTinUipLjtOOQWU+jV+gPKwk8e=518KsPbDrJsU2x@mail.gmail.com>
	<4D2CFC86.7070807@rawbw.com>
Message-ID: <AANLkTimt=K9bc28WBSPi=5KjOQ6cw0TwieJd5Yr+V4H_@mail.gmail.com>

On Tue, Jan 11, 2011 at 7:57 PM, Yuri <yuri at rawbw.com> wrote:
>
> It's best to supply --enable-shared to configure. This will build you
> libLLVM-2.9svn.dylib.
>

Ah, thanks.  I should have seen that configure option.

Rob

From clattner at apple.com  Tue Jan 11 19:39:22 2011
From: clattner at apple.com (Chris Lattner)
Date: Tue, 11 Jan 2011 17:39:22 -0800
Subject: [LLVMdev] TableGen Operator Names
In-Reply-To: <nngfwsz6v97.fsf@royale.us.cray.com>
References: <nngpqs8bp64.fsf@royale.us.cray.com>
	<DAB73736-AB7E-4835-B3A2-A27B5A9614A7@apple.com>
	<nngfwsz6v97.fsf@royale.us.cray.com>
Message-ID: <FE9F9A42-3453-454F-BF40-660D95BA3259@apple.com>


On Jan 11, 2011, at 12:27 PM, David A. Greene wrote:

> Chris Lattner <clattner at apple.com> writes:
> 
>>> Would anyone object if I changed the syntax from !operator to &operator?
>> 
>> In the absence of a much better proposal, I'd prefer to just keep it the way it is.
> 
> Fair enough.  What would make a better proposal?  I'd like to keep the
> syntax concise.  I wonder if there is a way we could get rid of the
> "operator" entirely and just specify names, like:
> 
> strconcat("this", "that")
> 
> instead of 
> 
> !strconcat("this", "that")
> 
> What do you think?

That would be nice.  I haven't looked in years, but I thought that there was a parser ambiguity issue.

-Chris

From yuri at rawbw.com  Tue Jan 11 20:20:01 2011
From: yuri at rawbw.com (Yuri)
Date: Tue, 11 Jan 2011 18:20:01 -0800
Subject: [LLVMdev] Wrong assembly is written for x86_64 target in JIT
 without optimization?
In-Reply-To: <974949FA-5A26-409B-8557-CEF76792BCC0@apple.com>
References: <4D2CFAD9.8010301@rawbw.com>
	<974949FA-5A26-409B-8557-CEF76792BCC0@apple.com>
Message-ID: <4D2D0FD1.70007@rawbw.com>

On 01/11/2011 17:07, Dale Johannesen wrote:
> The unitialized load is there in the llc version as well (16(%rsp)). 
>  It looks like it's been erroneously moved ahead of the spill to that 
> slot.  Please file a PR.  (I can see this on Darwin with llc -O0).

http://llvm.org/bugs/show_bug.cgi?id=8961

From ww345ww at gmail.com  Tue Jan 11 23:30:48 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Wed, 12 Jan 2011 13:30:48 +0800
Subject: [LLVMdev] About adding a pass into llvm
Message-ID: <AANLkTikG6sO8xZfYOvsoRTD0YkAf6_pmJ-O8VU-FaYcY@mail.gmail.com>

I have seen
INITIALIZE_PASS(LiveVariables, "livevars", "Live Variable Analysis", false,
false);
in the llvm/lib/codegen/LiveVariables.cpp, where LiveVariables is a subclass
of MachineFunctionPass, and
#define INITIALIZE_PASS(passName, arg, name, cfg, analysis) \
  static RegisterPass<passName> passName ## _info(arg, name, cfg, analysis)
in PassSupport.h

Is this code used to register and initialize a pass? This kind of
registration is just the way illustrated in the hello example at
http://llvm.org/docs/WritingAnLLVMPass.html#registration.


My problem is:
I wrote a pass (Mypass), also a subclass of MachineFunctionPass. And I wrote
the similar statement:
INITIALIZE_PASS(Mypass, "mypass", "Access Analysis", false, false);
aiming to register and initialize this new pass. I rebuilt the llvm with the
newly added pass, but when I used llc -help-hidden, I could not found the
"-mypass" option. How could I enable the new pass and the related option?
-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/476f0d9b/attachment.html 

From alex_rosenberg at playstation.sony.com  Tue Jan 11 17:35:16 2011
From: alex_rosenberg at playstation.sony.com (alex_rosenberg at playstation.sony.com)
Date: Tue, 11 Jan 2011 15:35:16 -0800
Subject: [LLVMdev] Announcement: Summer 2011 internship with Sony PlayStation
Message-ID: <F65802BB-8682-4DE5-B437-19FE78BCE506@playstation.sony.com>

Sony Computer Entertainment America is looking for an intern to work on LLVM and/or Clang. Please see the official listing for more details:

<http://playstation.taleo.net/careersection/sceaexternal1/jobdetail.ftl?lang=en&job=02232>

-----------------------------------------
Alex Rosenberg
Manager, Platform Architecture
Sony Computer Entertainment America, Inc.



From wubousc at gmail.com  Wed Jan 12 00:06:21 2011
From: wubousc at gmail.com (Bob WM)
Date: Tue, 11 Jan 2011 22:06:21 -0800 (PST)
Subject: [LLVMdev]  build a function type with char parameter
Message-ID: <30650603.post@talk.nabble.com>


I can use Integer::Type.get() to set the type of a parameter to integer. My
question is how I can do this for char *?

Thanks,
Bo
-- 
View this message in context: http://old.nabble.com/build-a-function-type-with-char-parameter-tp30650603p30650603.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From anton at korobeynikov.info  Wed Jan 12 02:39:09 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 12 Jan 2011 11:39:09 +0300
Subject: [LLVMdev] build a function type with char parameter
In-Reply-To: <30650603.post@talk.nabble.com>
References: <30650603.post@talk.nabble.com>
Message-ID: <AANLkTi=kwNT_F+zEaDVpZQKhVk9scUXMEakVnq5Qa08O@mail.gmail.com>

> I can use Integer::Type.get() to set the type of a parameter to integer. My
> question is how I can do this for char *?
It depends on your target, but usually char is just i8, thus char* is i8*

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From baldrick at free.fr  Wed Jan 12 02:36:05 2011
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 12 Jan 2011 09:36:05 +0100
Subject: [LLVMdev] About adding a pass into llvm
In-Reply-To: <AANLkTikG6sO8xZfYOvsoRTD0YkAf6_pmJ-O8VU-FaYcY@mail.gmail.com>
References: <AANLkTikG6sO8xZfYOvsoRTD0YkAf6_pmJ-O8VU-FaYcY@mail.gmail.com>
Message-ID: <4D2D67F5.9070804@free.fr>

Hi Li Qingan,

> I have seen
> INITIALIZE_PASS(LiveVariables, "livevars", "Live Variable Analysis", false, false);
> in the llvm/lib/codegen/LiveVariables.cpp, where LiveVariables is a subclass of
> MachineFunctionPass, and
> #define INITIALIZE_PASS(passName, arg, name, cfg, analysis) \
>    static RegisterPass<passName> passName ## _info(arg, name, cfg, analysis)
> in PassSupport.h
>
> Is this code used to register and initialize a pass? This kind of registration
> is just the way illustrated in the hello example at
> http://llvm.org/docs/WritingAnLLVMPass.html#registration.

how you do this depends on whether your pass will be built in to LLVM, or
whether it will be dynamically loaded by opt at runtime.  The HelloWorld
example on the web-page you mentions shows how to do it when a pass is to
be dynamically loaded - this means using RegisterPass.  If your pass is to
be built into LLVM then you can copy what other passes do.  Note that in
this case you typically need to modify include/llvm/Transforms/Scalar.h
and include/llvm/LinkAllPasses.h.

> My problem is:
> I wrote a pass (Mypass), also a subclass of MachineFunctionPass. And I wrote the
> similar statement:
> INITIALIZE_PASS(Mypass, "mypass", "Access Analysis", false, false);
> aiming to register and initialize this new pass. I rebuilt the llvm with the
> newly added pass, but when I used llc -help-hidden, I could not found the
> "-mypass" option. How could I enable the new pass and the related option?

In this third case of adding a codegen pass, you will need to add your pass to
include/llvm/CodeGen/Passes.h and have it be added to the pass manager in
lib/CodeGen/LLVMTargetMachine.cpp

Ciao, Duncan.

From surifilms at gmail.com  Wed Jan 12 03:02:40 2011
From: surifilms at gmail.com (Surinder)
Date: Wed, 12 Jan 2011 20:02:40 +1100
Subject: [LLVMdev] newbi to llvm - how to get array size
Message-ID: <AANLkTin9-25EzZH+0YHxZaLr50j+aOnKL+LKo6RYu-FL@mail.gmail.com>

Hi,

I am new to llvm to so please be kind to me if I am asking something that is
too simple.  I want to get the bounds of an array when I have a handle to
getelementptr or insertelement or extractvalue instructions.  I am writing a
translation routine from llvm to a non-deterministic language and want to
include array bounds check in it.

The array size gets printed as part of the type of the value <pty>

<result> = getelementptr inbounds <pty>* <ptrval> (ty idx)

I am wrongly expecting I.getOperand(0)->getType()->getNumElements() to
give me the array size (after casting ptrval to array type)

I am not getting the array size, I am getting a value of zero.

Can someone point out to me how to get array size (number of elements in the
array) from the type object.  What about multi-dimension arrays too.

Thanks.

Surinder Kumar Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/5c38c29d/attachment.html 

From baldrick at free.fr  Wed Jan 12 04:41:16 2011
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 12 Jan 2011 11:41:16 +0100
Subject: [LLVMdev] newbi to llvm - how to get array size
In-Reply-To: <AANLkTin9-25EzZH+0YHxZaLr50j+aOnKL+LKo6RYu-FL@mail.gmail.com>
References: <AANLkTin9-25EzZH+0YHxZaLr50j+aOnKL+LKo6RYu-FL@mail.gmail.com>
Message-ID: <4D2D854C.20103@free.fr>

Hi Surinder,

> I am new to llvm to so please be kind to me if I am asking something that is too
> simple.  I want to get the bounds of an array when I have a handle to
> getelementptr or insertelement or extractvalue instructions.  I am writing a
> translation routine from llvm to a non-deterministic language and want to
> include array bounds check in it.
> The array size gets printed as part of the type of the value <pty>
> <result> = getelementptr inbounds <pty>* <ptrval> (ty idx)
> I am wrongly expecting I.getOperand(0)->getType()->getNumElements() to give me
> the array size (after casting ptrval to array type)
> I am not getting the array size, I am getting a value of zero.
> Can someone point out to me how to get array size (number of elements in the
> array) from the type object.  What about multi-dimension arrays too.

the first operand always has pointer type, you need the type of the pointee,
something like this: I.getPointerOperandType()->getElementType()
You can then cast the returned type T to an array type and grab the number
of elements:
   cast<ArrayType>(T)->getNumElements()

Ciao, Duncan.

From leledumbo_cool at yahoo.co.id  Wed Jan 12 05:33:33 2011
From: leledumbo_cool at yahoo.co.id (leledumbo)
Date: Wed, 12 Jan 2011 03:33:33 -0800 (PST)
Subject: [LLVMdev] Mapping of logical NOT in LLVM IR
In-Reply-To: <30651314.post@talk.nabble.com>
References: <30651314.post@talk.nabble.com>
Message-ID: <30652403.post@talk.nabble.com>


Nevermind, I should've used Op XOR 1 instead.
-- 
View this message in context: http://old.nabble.com/Mapping-of-logical-NOT-in-LLVM-IR-tp30651314p30652403.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From lilissun at gmail.com  Wed Jan 12 06:04:26 2011
From: lilissun at gmail.com (Lilissun Li)
Date: Wed, 12 Jan 2011 20:04:26 +0800
Subject: [LLVMdev] VMKit Runtime Link Error
Message-ID: <AANLkTin8DB+nHsYVLy37XsaOEhnHsOr6MsPMJ9=6_zq7@mail.gmail.com>

Hi!

I build VMKit and run some programs successfully. But when
using java.util.concurrent.locks.ReentrantLock and
java.util.concurrent.locks.Condition,
I catch a Throwable :

    java.lang.UnsatisfiedLinkError:
sun.misc.Unsafe.unpark(Ljava/lang/Object;)V

after using the function :

   void java.util.concurrent.locks.Condition.await()

My test program is as follows:

*import* *java.lang*.*;

*import* *java.util.Map*;

*import* *java.io*.*;

*import* java.util.concurrent.locks.*;



*class* BoundedBuffer {

         Lock lock;

         Condition notFull;

         Condition notEmpty;



         *final* Object[] items = *new* Object[100];

         *int* putptr, takeptr, count;



         *public* BoundedBuffer(*int* init_count)

         {

                   lock = *new* ReentrantLock();

                   notFull  = lock.newCondition();

                   notEmpty = lock.newCondition();



                   count = init_count;

                   putptr = takeptr = 0;

         }



         *public* *void* put(Object x) *throws* InterruptedException {

                   lock.lock();

                   *try* {

                            *while* (count == items.length)

                                     notFull.await();

                            items[putptr] = x;

                            *if* (++putptr == items.length)

                                     putptr = 0;

                            ++count;

                            notEmpty.signal();

                   } *finally* {

                            lock.unlock();

                   }

         }



         *public* Object take() *throws* InterruptedException {

                   Object x = *null*;

                   lock.lock();

                   *try* {

                            *while* (count == 0)

                                     notEmpty.await();

                            x = items[takeptr];

                            *if* (++takeptr == items.length)

                                     takeptr = 0;

                            --count;

                            notFull.signal();

                   } *catch* (Throwable t){

                            System.*out*.println("BoundedBuffer.catch " +
t.toString());

                   } *finally* {

                            lock.unlock();

                   }



                   *return* x;

         }



         *public* *static* *void* main(String[] args)
*throws*InterruptedException

         {

                   BoundedBuffer buffer = *new* BoundedBuffer(0);

                   buffer.take();



                   *return* ;

         }

}


Can anyone please tell me why the error?

Thanks!

Li Li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/e588b9c6/attachment-0001.html 

From jay at jcornwall.me.uk  Wed Jan 12 06:15:35 2011
From: jay at jcornwall.me.uk (Jay Cornwall)
Date: Wed, 12 Jan 2011 12:15:35 +0000
Subject: [LLVMdev] Win64 calling convention
Message-ID: <54cb40a4792f2975b795b40951251705@mail.jcornwall.me.uk>

 Hi,

 I've encountered a problem invoking LLVM-generated x86_64 code on 
 Windows from MSVC-compiled code. There seems to be disagreement between 
 the two compilers over the calling convention for passing a 12 or 16 
 byte structure by value. e.g.

 struct aggregate { int a; int b; int c; int d; };
 int test(aggregate byVal) { ... }

 LLVM chooses to pass byVal with a and b packed into rcx and c and d 
 packed into rdx. MSVC (8 here) instead passes a reference to the 
 structure in rcx. My reading of the System V ABI spec is unclear, 
 although Microsoft already deviate in their choice of fastcall registers 
 so perhaps it is irrelevant.

 Should I file a bug for this?

-- 
 Jay Cornwall
 http://www.jcornwall.me.uk/

From geek4civic at gmail.com  Wed Jan 12 06:43:01 2011
From: geek4civic at gmail.com (NAKAMURA Takumi)
Date: Wed, 12 Jan 2011 21:43:01 +0900
Subject: [LLVMdev] Win64 calling convention
In-Reply-To: <54cb40a4792f2975b795b40951251705@mail.jcornwall.me.uk>
References: <54cb40a4792f2975b795b40951251705@mail.jcornwall.me.uk>
Message-ID: <AANLkTinpcpovoPSzLbr7Y4EgNrq417xp+4Uc2ANPQbFP@mail.gmail.com>

Good evening, Jay.


2011/1/12 Jay Cornwall <jay at jcornwall.me.uk>:
> ?Hi,
>
> ?I've encountered a problem invoking LLVM-generated x86_64 code on
> ?Windows from MSVC-compiled code. There seems to be disagreement between
> ?the two compilers over the calling convention for passing a 12 or 16
> ?byte structure by value. e.g.
>
> ?struct aggregate { int a; int b; int c; int d; };
> ?int test(aggregate byVal) { ... }
>
> ?LLVM chooses to pass byVal with a and b packed into rcx and c and d
> ?packed into rdx. MSVC (8 here) instead passes a reference to the
> ?structure in rcx. My reading of the System V ABI spec is unclear,
> ?although Microsoft already deviate in their choice of fastcall registers
> ?so perhaps it is irrelevant.

I guess it might be a clang's issue.
ToT clang does not know Win64 calling conversion and it seems you saw
"amd64-like" cc.

> ?Should I file a bug for this?

You may file one though I have patches for it.
I will post patches for clang soon.


...Takumi


From nicolas.geoffray at gmail.com  Wed Jan 12 06:58:32 2011
From: nicolas.geoffray at gmail.com (nicolas geoffray)
Date: Wed, 12 Jan 2011 13:58:32 +0100
Subject: [LLVMdev] VMKit Runtime Link Error
In-Reply-To: <AANLkTin8DB+nHsYVLy37XsaOEhnHsOr6MsPMJ9=6_zq7@mail.gmail.com>
References: <AANLkTin8DB+nHsYVLy37XsaOEhnHsOr6MsPMJ9=6_zq7@mail.gmail.com>
Message-ID: <AANLkTik1jj7+OqFts0kDHvQt20YEnjdn08SfuEU97oiP@mail.gmail.com>

Hi Lilissun,

VMKit does not implement all sun.misc.Unsafe methods. Looking at your
example, it looks like GNU Classpath (the library that provides java.*
classes) rely on sun.misc.Unsafe.unpark, and that the method must be
implemented by the VM. Implementing them is not trivial and requires a good
understanding of the threading library in VMKit, but I will be happy to help
if you want to take a look at it.

Cheers,
Nicolas

On Wed, Jan 12, 2011 at 1:04 PM, Lilissun Li <lilissun at gmail.com> wrote:

> Hi!
>
> I build VMKit and run some programs successfully. But when
> using java.util.concurrent.locks.ReentrantLock and java.util.concurrent.locks.Condition,
> I catch a Throwable :
>
>     java.lang.UnsatisfiedLinkError:
> sun.misc.Unsafe.unpark(Ljava/lang/Object;)V
>
> after using the function :
>
>    void java.util.concurrent.locks.Condition.await()
>
> My test program is as follows:
>
> *import* *java.lang*.*;
>
> *import* *java.util.Map*;
>
> *import* *java.io*.*;
>
> *import* java.util.concurrent.locks.*;
>
>
>
> *class* BoundedBuffer {
>
>          Lock lock;
>
>          Condition notFull;
>
>          Condition notEmpty;
>
>
>
>          *final* Object[] items = *new* Object[100];
>
>          *int* putptr, takeptr, count;
>
>
>
>          *public* BoundedBuffer(*int* init_count)
>
>          {
>
>                    lock = *new* ReentrantLock();
>
>                    notFull  = lock.newCondition();
>
>                    notEmpty = lock.newCondition();
>
>
>
>                    count = init_count;
>
>                    putptr = takeptr = 0;
>
>          }
>
>
>
>          *public* *void* put(Object x) *throws* InterruptedException {
>
>                    lock.lock();
>
>                    *try* {
>
>                             *while* (count == items.length)
>
>                                      notFull.await();
>
>                             items[putptr] = x;
>
>                             *if* (++putptr == items.length)
>
>                                      putptr = 0;
>
>                             ++count;
>
>                             notEmpty.signal();
>
>                    } *finally* {
>
>                             lock.unlock();
>
>                    }
>
>          }
>
>
>
>          *public* Object take() *throws* InterruptedException {
>
>                    Object x = *null*;
>
>                    lock.lock();
>
>                    *try* {
>
>                             *while* (count == 0)
>
>                                      notEmpty.await();
>
>                             x = items[takeptr];
>
>                             *if* (++takeptr == items.length)
>
>                                      takeptr = 0;
>
>                             --count;
>
>                             notFull.signal();
>
>                    } *catch* (Throwable t){
>
>                             System.*out*.println("BoundedBuffer.catch " +
> t.toString());
>
>                    } *finally* {
>
>                             lock.unlock();
>
>                    }
>
>
>
>                    *return* x;
>
>          }
>
>
>
>          *public* *static* *void* main(String[] args) *throws*InterruptedException
>
>          {
>
>                    BoundedBuffer buffer = *new* BoundedBuffer(0);
>
>                    buffer.take();
>
>
>
>                    *return* ;
>
>          }
>
> }
>
>
> Can anyone please tell me why the error?
>
> Thanks!
>
> Li Li
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/0e429336/attachment.html 

From ww345ww at gmail.com  Wed Jan 12 07:29:17 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Wed, 12 Jan 2011 21:29:17 +0800
Subject: [LLVMdev] About test suits
Message-ID: <AANLkTinpp4qGSv6nyvL74pnwnh0xFGAvi+eak_T=Q=_7@mail.gmail.com>

I have built and configured the test suits as told at
http://llvm.org/docs/TestingGuide.html#testsuite.
The llvm is built with configuration:

SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime
 --disable-optimized --enable-debug-symbols --enable-assertions

This configuration is used again in the re-configure process. However, after
the re-configure process,  the following "make" failed:
qali at qali MultiSource]$ make
make[1]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/MultiSource/Applications'
make[2]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/MultiSource/Applications/Burg'
/home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as Output/be.ll -o
Output/be.bc
/home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as: Output/be.ll:1:2:
error: expected top-level entity
.file
"/home/qali/Src/llvm-2.8/projects/test-suite/MultiSource/Applications/Burg/be.c"
^
make[2]: *** [Output/be.bc] Error 1
make[2]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/MultiSource/Applications/Burg'
make[1]: *** [Burg/.makeall] Error 2
make[1]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/MultiSource/Applications'
make: *** [Applications/.makeall] Error 2
[qali at qali MultiSource]$ tree
.
|-- Applications
|   |-- Burg
|   |   |-- Makefile
|   |   `-- Output
|   |       `-- be.ll
|   `-- Makefile
|-- Makefile
`-- Makefile.multisrc

3 directories, 5 files
[qali at qali MultiSource]$ cd ..
[qali at qali test-suite]$ tree
.
|-- config.log
|-- config.status
|-- External
|   |-- Makefile
|   |-- Makefile.external
|   |-- Povray
|   |   `-- Makefile
|   |-- skidmarks10
|   |   `-- Makefile
|   `-- SPEC
|       |-- CFP2000
|       |   `-- Makefile
|       |-- CFP2006
|       |   `-- Makefile
|       |-- CFP95
|       |   `-- Makefile
|       |-- CINT2000
|       |   `-- Makefile
|       |-- CINT2006
|       |   `-- Makefile
|       |-- CINT95
|       |   `-- Makefile
|       |-- Makefile
|       |-- Makefile.spec
|       |-- Makefile.spec2000
|       |-- Makefile.spec2006
|       |-- Makefile.spec95
|       `-- Makefile.spec.config
|-- Makefile
|-- Makefile.common
|-- Makefile.config
|-- Makefile.f2c
|-- Makefile.nagfortran
|-- Makefile.programs
|-- Makefile.tests
|-- mklib
|-- MultiSource
|   |-- Applications
|   |   |-- Burg
|   |   |   |-- Makefile
|   |   |   `-- Output
|   |   |       `-- be.ll
|   |   `-- Makefile
|   |-- Makefile
|   `-- Makefile.multisrc
|-- SingleSource
|   |-- Makefile
|   |-- Makefile.singlesrc
|   `-- UnitTests
|       |-- Makefile
|       `-- Vector
|           |-- Makefile
|           `-- SSE
|               |-- Makefile
|               `-- Output
|                   `-- sse.expandfft.ll
|-- TEST.aa.Makefile
|-- TEST.aa.report
|-- TEST.buildrepo.Makefile
|-- TEST.example.Makefile
|-- TEST.jit.Makefile
|-- TEST.jit.report
|-- TEST.nightly.Makefile
|-- TEST.nightly.report
|-- TEST.typesafe.Makefile
`-- TEST.vtl.Makefile

19 directories, 47 files


-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/d701ecb6/attachment.html 

From ww345ww at gmail.com  Wed Jan 12 09:24:06 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Wed, 12 Jan 2011 23:24:06 +0800
Subject: [LLVMdev] About adding a pass into llvm, cont
Message-ID: <AANLkTi=Q9r2DZpOWqDmJVHGrhzUe83kzPWrUHZ6kE6cM@mail.gmail.com>

Hi,

Thanks for your last reply.
Could I understand the way to adding a pass (built into the llvm rather than
dynamic loadable) includes:
1. Declaring a creator function for this pass
2. Implementing the creator function for this pass
3. Instantiating this pass and get a object of it
3. Register this pass into the PassRegistry

Then, for a built-into bytecode pass,
         task 1(declaration of the creator) should be done in Scalar.h;
         task 2(implementation of the creator) should be done the related
mypass.cpp file;
         task 3(instantiation of the pass class) should be done in
LinkAllPasses.h;
         task 4(registration of the pass into the PassRegistry) should be
done by INITIALIZE_PASS
class LiveVariables : public MachineFunctionPass is a case of point.

For a built-into codegen/MachineCode pass,
         task 1 should be done in Passes.h;
         task 2 should be done in the related mypass.cpp file;
         task 3 should be done in LLVMTargetMachine.cpp
         task 4 should be done by INITIALIZE_PASS
 class IntervalAnalylsis: public MachineFunctionPass is a case in point.

I have implemented a new mypass (just for analysis, rather than
transformation) as a subclass of MchineFunctionPass, and finished task 1, 2,
4. But I don't know how to finish task 3, since I failed to make clear how
the class IntervalAnalysis did task 3. So I need your help.

-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/da9d72fc/attachment.html 

From ghoang84 at gmail.com  Wed Jan 12 09:49:37 2011
From: ghoang84 at gmail.com (Giang Hoang)
Date: Wed, 12 Jan 2011 09:49:37 -0600
Subject: [LLVMdev] Adding a new instruction to Alpha ISA
Message-ID: <AANLkTin_8dm3csmmybO1ddv2PMG1DUK1UpBWoF5625xF@mail.gmail.com>

Hi,

I want to add an extra instruction to the Alpha ISA.  This is not a new
operation; it is just an addition with a lower latency, let's call it
fast-add.  Could you give me advice on what's an easy and clean approach to
this?  I am thinking of adding an extra instruction to the LLVM IR to
represent this fast-add operation (I want to make the decision of using
either the normal addition or fast addition during loop unroll pass, which
happens before code generation; so I think I need an extra IR instruction).
 The LLVM documentation warns against adding new IR instruction unless it is
absolutely necessary, so I would like to ask to make sure.

Thank you very much.

Giang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/6d491223/attachment.html 

From hkultala at iki.fi  Wed Jan 12 10:24:58 2011
From: hkultala at iki.fi (Heikki Kultala)
Date: Wed, 12 Jan 2011 18:24:58 +0200
Subject: [LLVMdev] opt, loopidiom pass and compiling system libraries
Message-ID: <09B3E55E-A306-4B9A-A2CD-F952C7BE5E75@iki.fi>

It seems LoopIdiomRecognizer pass recognizes one loop inside memSet as memset and replaces it with memset intrinsic, which might then be converted into memset call, resulting in infinite recursion.

There is parameter -fno-builtins to prevent this, BUT when executing opt as "standalone", this parameter cannot be given to it, with default optimizations it executes the LoopIdiomRecognizer, which causes this problem.

So it would seem opt would need either of the following parameters:

-fno-builtins (do all the same things -fno-builtins does when given to clang)
-disable-loop-idiom (disables loop idiom pass, runs all other default passes)




From wubousc at gmail.com  Wed Jan 12 10:46:31 2011
From: wubousc at gmail.com (Bob WM)
Date: Wed, 12 Jan 2011 08:46:31 -0800 (PST)
Subject: [LLVMdev] build a function type with char parameter
In-Reply-To: <AANLkTi=kwNT_F+zEaDVpZQKhVk9scUXMEakVnq5Qa08O@mail.gmail.com>
References: <30650603.post@talk.nabble.com>
	<AANLkTi=kwNT_F+zEaDVpZQKhVk9scUXMEakVnq5Qa08O@mail.gmail.com>
Message-ID: <30654341.post@talk.nabble.com>


How should I create the parameter and pass it to CallInst::Create then?

Thanks,
Bo


Anton Korobeynikov-2 wrote:
> 
>> I can use Integer::Type.get() to set the type of a parameter to integer.
>> My
>> question is how I can do this for char *?
> It depends on your target, but usually char is just i8, thus char* is i8*
> 
> -- 
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 

-- 
View this message in context: http://old.nabble.com/build-a-function-type-with-char-parameter-tp30650603p30654341.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From clattner at apple.com  Wed Jan 12 13:03:26 2011
From: clattner at apple.com (Chris Lattner)
Date: Wed, 12 Jan 2011 11:03:26 -0800
Subject: [LLVMdev] About test suits
In-Reply-To: <AANLkTinpp4qGSv6nyvL74pnwnh0xFGAvi+eak_T=Q=_7@mail.gmail.com>
References: <AANLkTinpp4qGSv6nyvL74pnwnh0xFGAvi+eak_T=Q=_7@mail.gmail.com>
Message-ID: <00405EB0-E1B4-4670-95E7-96FC2CBDE19C@apple.com>


On Jan 12, 2011, at 5:29 AM, Qingan Li wrote:

> I have built and configured the test suits as told at http://llvm.org/docs/TestingGuide.html#testsuite. 
> The llvm is built with configuration: 

This looks like your llvm-gcc is not generating proper .ll files.  Please make sure that "llvm-gcc -v" includes "(LLVM build)".

-Chris

> 
> SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime  --disable-optimized --enable-debug-symbols --enable-assertions
> 
> This configuration is used again in the re-configure process. However, after the re-configure process,  the following "make" failed:
> qali at qali MultiSource]$ make
> make[1]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/MultiSource/Applications'
> make[2]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/MultiSource/Applications/Burg'
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as Output/be.ll -o Output/be.bc
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as: Output/be.ll:1:2: error: expected top-level entity
> 	.file	"/home/qali/Src/llvm-2.8/projects/test-suite/MultiSource/Applications/Burg/be.c"
> 	^
> make[2]: *** [Output/be.bc] Error 1
> make[2]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/MultiSource/Applications/Burg'
> make[1]: *** [Burg/.makeall] Error 2
> make[1]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/MultiSource/Applications'
> make: *** [Applications/.makeall] Error 2
> [qali at qali MultiSource]$ tree
> .
> |-- Applications
> |   |-- Burg
> |   |   |-- Makefile
> |   |   `-- Output
> |   |       `-- be.ll
> |   `-- Makefile
> |-- Makefile
> `-- Makefile.multisrc
> 
> 3 directories, 5 files
> [qali at qali MultiSource]$ cd ..
> [qali at qali test-suite]$ tree
> .
> |-- config.log
> |-- config.status
> |-- External
> |   |-- Makefile
> |   |-- Makefile.external
> |   |-- Povray
> |   |   `-- Makefile
> |   |-- skidmarks10
> |   |   `-- Makefile
> |   `-- SPEC
> |       |-- CFP2000
> |       |   `-- Makefile
> |       |-- CFP2006
> |       |   `-- Makefile
> |       |-- CFP95
> |       |   `-- Makefile
> |       |-- CINT2000
> |       |   `-- Makefile
> |       |-- CINT2006
> |       |   `-- Makefile
> |       |-- CINT95
> |       |   `-- Makefile
> |       |-- Makefile
> |       |-- Makefile.spec
> |       |-- Makefile.spec2000
> |       |-- Makefile.spec2006
> |       |-- Makefile.spec95
> |       `-- Makefile.spec.config
> |-- Makefile
> |-- Makefile.common
> |-- Makefile.config
> |-- Makefile.f2c
> |-- Makefile.nagfortran
> |-- Makefile.programs
> |-- Makefile.tests
> |-- mklib
> |-- MultiSource
> |   |-- Applications
> |   |   |-- Burg
> |   |   |   |-- Makefile
> |   |   |   `-- Output
> |   |   |       `-- be.ll
> |   |   `-- Makefile
> |   |-- Makefile
> |   `-- Makefile.multisrc
> |-- SingleSource
> |   |-- Makefile
> |   |-- Makefile.singlesrc
> |   `-- UnitTests
> |       |-- Makefile
> |       `-- Vector
> |           |-- Makefile
> |           `-- SSE
> |               |-- Makefile
> |               `-- Output
> |                   `-- sse.expandfft.ll
> |-- TEST.aa.Makefile
> |-- TEST.aa.report
> |-- TEST.buildrepo.Makefile
> |-- TEST.example.Makefile
> |-- TEST.jit.Makefile
> |-- TEST.jit.report
> |-- TEST.nightly.Makefile
> |-- TEST.nightly.report
> |-- TEST.typesafe.Makefile
> `-- TEST.vtl.Makefile
> 
> 19 directories, 47 files
> 
> 
> -- 
> Best regards,
> 
> Li Qingan
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/4e85a9cd/attachment.html 

From douglasdocouto at gmail.com  Wed Jan 12 13:31:07 2011
From: douglasdocouto at gmail.com (Douglas do Couto Teixeira)
Date: Wed, 12 Jan 2011 17:31:07 -0200
Subject: [LLVMdev] Question about nsw and nuw flags
Message-ID: <AANLkTi=4E_bqVP9zs2-OoJiLdzMhnSpQ46_aw03VFp7W@mail.gmail.com>

Hi everybody,

I saw that there are some instructions in the programs in which the flag nsw
or nuw is placed. I wonder what rules does LLVM follows to put these flags
in some instructions.


Best,

Douglas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/e696af22/attachment.html 

From clattner at apple.com  Wed Jan 12 13:34:13 2011
From: clattner at apple.com (Chris Lattner)
Date: Wed, 12 Jan 2011 11:34:13 -0800
Subject: [LLVMdev] Question about nsw and nuw flags
In-Reply-To: <AANLkTi=4E_bqVP9zs2-OoJiLdzMhnSpQ46_aw03VFp7W@mail.gmail.com>
References: <AANLkTi=4E_bqVP9zs2-OoJiLdzMhnSpQ46_aw03VFp7W@mail.gmail.com>
Message-ID: <214F047A-741E-4F00-9575-ADE997B6D627@apple.com>


On Jan 12, 2011, at 11:31 AM, Douglas do Couto Teixeira wrote:

> Hi everybody,
> 
> I saw that there are some instructions in the programs in which the flag nsw or nuw is placed. I wonder what rules does LLVM follows to put these flags in some instructions.

Hi Douglas,

The canonical reference for these types of questions is the IR description, here: http://llvm.org/docs/LangRef.html

-Chris

From alex.cossette at gmail.com  Wed Jan 12 14:42:05 2011
From: alex.cossette at gmail.com (Alexandre Cossette)
Date: Wed, 12 Jan 2011 15:42:05 -0500
Subject: [LLVMdev] Extending LLVM for high-level types
Message-ID: <79261AB7-3203-4267-8CC0-EE2B11024E2F@gmail.com>

Hi all,

I'm designing a programming language named C? (or C3). I'm already using LLVM as a back-end for my prototype compiler and it's wonderful to use. Thanks for such a great system!

I now have more ambitious goals and I would like to use the LLVM IR as my internal C? IR. C? is designed to support what I call "value-oriented programming" and it fits naturally with the design of LLVM. The idea is to apply SSA-based optimizations on user-defined types.

I would like to know if you think this plan makes sense:
- Add a new derived type that is uniqued by name for C? types
- Add new intrinsic functions for C? expressions with special semantics
- Emit this "extended LLVM" from my abstract syntax tree
- Run the mem2reg pass as is for SSA construction
- Run optimization passes that can run as is with the new type (like GVN?)
- Run a new pass that lowers the extended LLVM to normal LLVM
- Run (or rerun) normal LLVM optimization passes
- Emit native code using normal LLVM
- Profit!

Alex



From atsezeriakob at gmail.com  Wed Jan 12 14:45:00 2011
From: atsezeriakob at gmail.com (Atse Zeriakob)
Date: Wed, 12 Jan 2011 21:45:00 +0100
Subject: [LLVMdev] Assembly Printer
Message-ID: <AANLkTinHdq=ykOugGMdjXhZJH2jgz2OaZ1=W88mL+y+Y@mail.gmail.com>

I am using LLVM 2.8 on Ubuntu 10.10.



I change name of instruction on XXXInstrInfo.td ( Sparc, X86 and XCore).  I
looked into XXXGenAsmWriter.inc and I have seen the new instruction name.
But when I run llc for the three targets it prints out the old instruction
name.



For example for XCore I change ?divs? to ?sdiv? like



def DIVS_l3r : FL3R<"divs", sdiv>;// divs



def DIVS_l3r : FL3R<"sdiv", sdiv>;//sdiv



If this is linkage problem how can I solve it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/90a2edf4/attachment.html 

From rob.nikander at gmail.com  Wed Jan 12 16:28:49 2011
From: rob.nikander at gmail.com (Rob Nikander)
Date: Wed, 12 Jan 2011 17:28:49 -0500
Subject: [LLVMdev] How to define a global variable?
Message-ID: <AANLkTimLmm67Wr8DWYr==hdM5e1=0s8OJp8d5z8m+wP8@mail.gmail.com>

Hi,

I'm trying to define a mutable variable, outside functions.  The code
below is trying to evaluate an expression much like "x = 1" at the
module level in Python.  It appears that when it tries to JIT the
function there is an error because there is no storage allocated for
'x'.   How do I do that?

thanks,
Rob

----- dumped IR -----
; ModuleID = 'repl-module'

%0 = type opaque

@x = external global %0*

define %0* @0() {
entry:
  store %0* inttoptr (i64 4316154480 to %0*), %0** @x
  ret %0* inttoptr (i64 4316154480 to %0*)
}
LLVM ERROR: Could not resolve external global address: x


----- C++ code -----
GlobalVariable *gvar = new GlobalVariable(*module, id_ty, false,
GlobalVariable::ExternalLinkage, 0, str.str());
Value *valv = gen_expr(val);
builder.CreateStore(valv, gvar, false);
...
engine->getPointerToFunction(thunk);

From rengolin at systemcall.org  Wed Jan 12 17:08:52 2011
From: rengolin at systemcall.org (Renato Golin)
Date: Wed, 12 Jan 2011 23:08:52 +0000
Subject: [LLVMdev] How to define a global variable?
In-Reply-To: <AANLkTimLmm67Wr8DWYr==hdM5e1=0s8OJp8d5z8m+wP8@mail.gmail.com>
References: <AANLkTimLmm67Wr8DWYr==hdM5e1=0s8OJp8d5z8m+wP8@mail.gmail.com>
Message-ID: <AANLkTikv_kDjbQzi2eePbGPM=ObS0sUOE2XA9viszokb@mail.gmail.com>

On 12 January 2011 22:28, Rob Nikander <rob.nikander at gmail.com> wrote:
> @x = external global %0*

Hi Rob,

Try removing the 'extern', as it implies the variable storage is
elsewhere (ie. another object file).

cheers,
--renato

From rob.nikander at gmail.com  Wed Jan 12 17:38:16 2011
From: rob.nikander at gmail.com (Rob Nikander)
Date: Wed, 12 Jan 2011 18:38:16 -0500
Subject: [LLVMdev] How to define a global variable?
In-Reply-To: <AANLkTikv_kDjbQzi2eePbGPM=ObS0sUOE2XA9viszokb@mail.gmail.com>
References: <AANLkTimLmm67Wr8DWYr==hdM5e1=0s8OJp8d5z8m+wP8@mail.gmail.com>
	<AANLkTikv_kDjbQzi2eePbGPM=ObS0sUOE2XA9viszokb@mail.gmail.com>
Message-ID: <AANLkTi=iJBqbJdC7FRJpTkLxYxHxE9PpeiFcgJcivTqm@mail.gmail.com>

On Wed, Jan 12, 2011 at 6:08 PM, Renato Golin <rengolin at systemcall.org> wrote:
> On 12 January 2011 22:28, Rob Nikander <rob.nikander at gmail.com> wrote:
>> @x = external global %0*
>
> Hi Rob,
>
> Try removing the 'extern', as it implies the variable storage is
> elsewhere (ie. another object file).
>

I have to pass something from the LinkageTypes enum to the
constructor.  I tried others, like GlobalVariable::InternalLinkage,
which dumps as "internal global" but the error was the same.

Rob

From rengolin at systemcall.org  Wed Jan 12 18:33:25 2011
From: rengolin at systemcall.org (Renato Golin)
Date: Thu, 13 Jan 2011 00:33:25 +0000
Subject: [LLVMdev] How to define a global variable?
In-Reply-To: <AANLkTi=iJBqbJdC7FRJpTkLxYxHxE9PpeiFcgJcivTqm@mail.gmail.com>
References: <AANLkTimLmm67Wr8DWYr==hdM5e1=0s8OJp8d5z8m+wP8@mail.gmail.com>
	<AANLkTikv_kDjbQzi2eePbGPM=ObS0sUOE2XA9viszokb@mail.gmail.com>
	<AANLkTi=iJBqbJdC7FRJpTkLxYxHxE9PpeiFcgJcivTqm@mail.gmail.com>
Message-ID: <AANLkTi=nyQopE_WUsFetA2PrX8JW3SdyBM0S5fbj7zfs@mail.gmail.com>

On 12 January 2011 23:38, Rob Nikander <rob.nikander at gmail.com> wrote:
> I have to pass something from the LinkageTypes enum to the
> constructor. ?I tried others, like GlobalVariable::InternalLinkage,
> which dumps as "internal global" but the error was the same.

To be honest, your IR is a bit odd. I'm not a JIT expert, but here are
a few things that will help you find your way through LLVM...

Is this the result of the compilation of a source file (by any
front-end), or is this code generated dynamically via the API?

Opaque types are not valid, you need to resolve it to a real (LLVM)
type before running/compiling. The inttoptr will not resolve it to a
pointer, so that IR is probably invalid anyway.

The internal global probably works in your case and unless you have
another extern variable, I don't know how you can get the "exact" same
error message with an internal global. (Again, I'm not a JIT expert,
that could happen somehow).

This could be perfectly legal in your case, but if I got it right,
you're setting a static address to a supposed pointer (i64
4316154480). That's generally wrong in all but the most simple cases
(deeply embedded systems with no memory management).

I don't know about the Python integration, but if your @x variable is
a Python variable, then extern global is probably what you're looking
for. However, due to the (possible) difference in memory layouts, I
don't think that's the best way to pass information up to the Python
layer. At least when using JNI to interface Java with C, that was a
clear dead end.

Maybe if you tell us a bit more about your project, expectations and
steps, we might be able to help you more than just guessing... ;)

cheers,
--renato


From wendling at apple.com  Wed Jan 12 18:53:23 2011
From: wendling at apple.com (Bill Wendling)
Date: Wed, 12 Jan 2011 16:53:23 -0800
Subject: [LLVMdev] Adding a new instruction to Alpha ISA
In-Reply-To: <AANLkTin_8dm3csmmybO1ddv2PMG1DUK1UpBWoF5625xF@mail.gmail.com>
References: <AANLkTin_8dm3csmmybO1ddv2PMG1DUK1UpBWoF5625xF@mail.gmail.com>
Message-ID: <9BBB1B6D-A3F9-46F2-991C-02DB5F22EF99@apple.com>

On Jan 12, 2011, at 7:49 AM, Giang Hoang wrote:

> Hi,
> 
> I want to add an extra instruction to the Alpha ISA.  This is not a new operation; it is just an addition with a lower latency, let's call it fast-add.  Could you give me advice on what's an easy and clean approach to this?  I am thinking of adding an extra instruction to the LLVM IR to represent this fast-add operation (I want to make the decision of using either the normal addition or fast addition during loop unroll pass, which happens before code generation; so I think I need an extra IR instruction).  The LLVM documentation warns against adding new IR instruction unless it is absolutely necessary, so I would like to ask to make sure.
> 
Hi Giang,

If you need to have special instructions like this, the best way is to create an intrinsic that represents the operation. For instance, LLVM has the "llvm.smul.with.overflow" intrinsic, which represents a normal (signed) multiply instruction, but is specially lowered to check for overflow.

-bw


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/a47a08f2/attachment.html 

From rob.nikander at gmail.com  Wed Jan 12 19:32:50 2011
From: rob.nikander at gmail.com (Rob Nikander)
Date: Wed, 12 Jan 2011 20:32:50 -0500
Subject: [LLVMdev] How to define a global variable?
In-Reply-To: <AANLkTi=nyQopE_WUsFetA2PrX8JW3SdyBM0S5fbj7zfs@mail.gmail.com>
References: <AANLkTimLmm67Wr8DWYr==hdM5e1=0s8OJp8d5z8m+wP8@mail.gmail.com>
	<AANLkTikv_kDjbQzi2eePbGPM=ObS0sUOE2XA9viszokb@mail.gmail.com>
	<AANLkTi=iJBqbJdC7FRJpTkLxYxHxE9PpeiFcgJcivTqm@mail.gmail.com>
	<AANLkTi=nyQopE_WUsFetA2PrX8JW3SdyBM0S5fbj7zfs@mail.gmail.com>
Message-ID: <AANLkTimhWREvUKdJWZatDN7HX0tFT_+PLp+m9yTwY1Sk@mail.gmail.com>

On Wed, Jan 12, 2011 at 7:33 PM, Renato Golin <rengolin at systemcall.org> wrote:
> On 12 January 2011 23:38, Rob Nikander <rob.nikander at gmail.com> wrote:
>> I have to pass something from the LinkageTypes enum to the
>> constructor. ?I tried others, like GlobalVariable::InternalLinkage,
>> which dumps as "internal global" but the error was the same.
>
> To be honest, your IR is a bit odd. I'm not a JIT expert, but here are
> a few things that will help you find your way through LLVM...
>
> Is this the result of the compilation of a source file (by any
> front-end), or is this code generated dynamically via the API?

Via the API.  More below...


> This could be perfectly legal in your case, but if I got it right,
> you're setting a static address to a supposed pointer (i64
> 4316154480). That's generally wrong in all but the most simple cases
> (deeply embedded systems with no memory management).
> ....
> I don't know about the Python integration, but if your @x variable is ...

I'm not doing anything with Python, but I mentioned it to illustrate
what kind of expression I was trying to compile.  I'm trying to create
a Lisp-like language.  I was following parts of the Kaleidoscope
language tutorial in the LLVM docs.  The expression for the program
above is actually (def x 1) in this language.  At the module level
(ie, not inside a function) this should create a module level "global"
variable called x and set it to 1.   These weird pointer casts are the
first, simplest expressions getting compiled.  Let's say the reader
(parser) sees "abc" and returns that immutable string object, which is
an expression.  It is a self-evaluating expression, so to JIT compile
it, I figured I'd just put it's address into the compiled code, as a
Constant.  (The object already exists in memory, because it was read.)
  This has been working okay; it JIT compiles and evaluates simple
literal expressions, like numbers, strings, quoted lists.

Right now, everything is an object, even simple things like an
integer.  This is for easy development in the beginning.  I'll use
types and/or immediate ints, etc, later.  So, for (def x 1) there is a
heap-allocated integer (actually NSNumber) and that's the pointer in
my IR shown before.  I want to set 'x' to that object.  The type of x
in Objective-C/C++ world is NSObject* or id.  I just tried i8* instead
of opaque*, so now it looks like...

> (def x 1)
; ModuleID = 'repl-module'

@x = common global i8*

define i8* @0() {
entry:
  store i8* inttoptr (i64 4316154320 to i8*), i8** @x
  ret i8* inttoptr (i64 4316154320 to i8*)
}

LLVM ERROR: Could not resolve external global address: x


That last line is printed when I try to get the JIT'd function with:

engine->getPointerToFunction(thunk);


thanks for the help,
Rob


From neal.wang at gmail.com  Wed Jan 12 23:38:54 2011
From: neal.wang at gmail.com (Neal  N. Wang)
Date: Wed, 12 Jan 2011 21:38:54 -0800
Subject: [LLVMdev] how to build llvm-g++
Message-ID: <AANLkTi=kFf+QL2nFq6zMYnEHOidvXWYufrJe_o7KUybQ@mail.gmail.com>

I build llvm-gcc-4.2-2.8.source, but it only gives me gcc not g++. Any
suggestion how to build g++ from the source?   Another question is I tried
to use clang to build llvm-2.8, but it fails. Which version of llvm can be
built by clang?

Thanks a lot,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110112/e2feace1/attachment.html 

From chenwj at iis.sinica.edu.tw  Wed Jan 12 23:50:02 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Thu, 13 Jan 2011 13:50:02 +0800
Subject: [LLVMdev] how to build llvm-g++
In-Reply-To: <AANLkTi=kFf+QL2nFq6zMYnEHOidvXWYufrJe_o7KUybQ@mail.gmail.com>
References: <AANLkTi=kFf+QL2nFq6zMYnEHOidvXWYufrJe_o7KUybQ@mail.gmail.com>
Message-ID: <20110113055002.GA71321@cs.nctu.edu.tw>

Hi, Neal

  Would you mind give us your configuration while building llvm-gcc? I
think llvm-gcc and llvm-g++ are built by default.

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667


From way_lzl at sina.com  Thu Jan 13 01:16:59 2011
From: way_lzl at sina.com (Zhanglin Liu)
Date: Thu, 13 Jan 2011 15:16:59 +0800 
Subject: [LLVMdev] Where is liveness analysis pass?
Message-ID: <20110113071659.6A6A0BDD04@mail2-95.sinamail.sina.com.cn>

Hello all

Currently I want to use the accurate liveness information when writing a *target independent* FunctionPass based on LLVM. The one I can find is LiveValues, a FunctionPass. But it doesn't use classic dataflow equation and can only provide approximate and conservative result. The another one is LiveVariables which use classic data flow equation, but it comes from Clang's analysis phase and only used in frontend.

My question is whether there is such a liveness analysis pass existed for FuntionPass?

Thanks for any suggestion. 
--------------------------------
--Zhanglin


From fvbommel at gmail.com  Thu Jan 13 01:34:32 2011
From: fvbommel at gmail.com (Frits van Bommel)
Date: Thu, 13 Jan 2011 08:34:32 +0100
Subject: [LLVMdev] How to define a global variable?
In-Reply-To: <AANLkTimLmm67Wr8DWYr==hdM5e1=0s8OJp8d5z8m+wP8@mail.gmail.com>
References: <AANLkTimLmm67Wr8DWYr==hdM5e1=0s8OJp8d5z8m+wP8@mail.gmail.com>
Message-ID: <AANLkTimBSgwKYn59a9X2dbhMF5R6cgLe2ZjHjQVbpnp4@mail.gmail.com>

On Wed, Jan 12, 2011 at 11:28 PM, Rob Nikander <rob.nikander at gmail.com> wrote:
> I'm trying to define a mutable variable, outside functions. ?The code
> below is trying to evaluate an expression much like "x = 1" at the
> module level in Python. ?It appears that when it tries to JIT the
> function there is an error because there is no storage allocated for
> 'x'. ? How do I do that?
>
> ----- dumped IR -----
> ; ModuleID = 'repl-module'
>
> %0 = type opaque
>
> @x = external global %0*

First, replace %0* with a concrete type (like the i8* in your later post).
Then give @x an initializer. 'undef' is good enough if you don't want
to assign an actual value yet. This should turn it into a definition
instead of a declaration.


From baldrick at free.fr  Thu Jan 13 01:59:36 2011
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 13 Jan 2011 08:59:36 +0100
Subject: [LLVMdev] how to build llvm-g++
In-Reply-To: <AANLkTi=kFf+QL2nFq6zMYnEHOidvXWYufrJe_o7KUybQ@mail.gmail.com>
References: <AANLkTi=kFf+QL2nFq6zMYnEHOidvXWYufrJe_o7KUybQ@mail.gmail.com>
Message-ID: <4D2EB0E8.1080905@free.fr>

Hi Neal,

> I build llvm-gcc-4.2-2.8.source, but it only gives me gcc not g++. Any
> suggestion how to build g++ from the source?

configure with --enable-languages=c,c++

From jaykang10 at imrc.kist.re.kr  Thu Jan 13 02:28:59 2011
From: jaykang10 at imrc.kist.re.kr (Jin Gu Kang)
Date: Thu, 13 Jan 2011 17:28:59 +0900
Subject: [LLVMdev] Where is liveness analysis pass?
In-Reply-To: <20110113071659.6A6A0BDD04@mail2-95.sinamail.sina.com.cn>
References: <20110113071659.6A6A0BDD04@mail2-95.sinamail.sina.com.cn>
Message-ID: <3E94D039A2B82544B3E7D48F924B0B25DFA3D87FD6@base.imrc.kist.re.kr>

Hi Zhanglin.

First I suggest to read http://llvm.org/docs/CodeGenerator.html#liveintervals. :)

I saw the basic processing order of Live interval in backend LLVM source code as following:
1. LiveVariables::runOnMachineFunction() "lib/CodeGen/LiveVariables.cpp"
--> This pass computes live variable information for each virtual register and register allocatable physical register in the function. (Target dependent)
2. SlotIndexes::runOnMachineFunction() "lib/CodeGen/SlotIndexes.cpp"
-->  This pass assigns indexes to each instruction and basic blocks
3. LiveIntervals::runOnMachineFunction() "lib/CodeGen/LiveIntervalAnalysis.cpp"
--> This pass computes live interval for live variables.
4. SimpleRegisterCoalescing::runOnMachineFunction "lib/CodeGen/SimpleRegisterCoalescing.cpp" 
-> After SimpleRegisterCoalescing, live intervals are merged.

As you know, liveness inforamtion in backend is target dependent.
If you want to use target independent liveness information, I suggest you to use live variable information for virtual register in "LiveVariables::runOnMachineFunction()" pass.

Best regards,
Jin-Gu Kang






________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Zhanglin Liu [way_lzl at sina.com]
Sent: Thursday, January 13, 2011 4:16 PM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Where is liveness analysis pass?

Hello all

Currently I want to use the accurate liveness information when writing a *target independent* FunctionPass based on LLVM. The one I can find is LiveValues, a FunctionPass. But it doesn't use classic dataflow equation and can only provide approximate and conservative result. The another one is LiveVariables which use classic data flow equation, but it comes from Clang's analysis phase and only used in frontend.

My question is whether there is such a liveness analysis pass existed for FuntionPass?

Thanks for any suggestion.
--------------------------------
--Zhanglin

From way_lzl at sina.com  Thu Jan 13 02:42:48 2011
From: way_lzl at sina.com (Zhanglin Liu)
Date: Thu, 13 Jan 2011 16:42:48 +0800 
Subject: [LLVMdev] Where is liveness analysis pass?
Message-ID: <20110113084248.8D0A2BDC9C@mail2-95.sinamail.sina.com.cn>

<style id="sinamailpaperfilter">.sinamailpaper-0{cursor:text;}.sinamailpaper-0 td,.sinamailpaper-0 textarea,.sinamailpaper-0 input,.sinamailpaper-0 br,.sinamailpaper-0 div,.sinamailpaper-0 span{font-size:14px;font-family:"????",Verdana,Arial,Helvetica,sans-serif;line-height:1.5;}.sinamailpaper-0 p{/**margin:0.2em auto;*/margin:0px;}.sinamailpaper-0 img{border:0;}.sinamailpaper-0 pre{white-space:normal;}.sinamailpaper-0 form{margin:0;}body{font-size:14px;}p{margin:0px;}</style>Jin-Gu<BR><BR>Thanks&nbsp;for&nbsp;your&nbsp;suggestion.&nbsp;Using&nbsp;the&nbsp;liveness&nbsp;information&nbsp;for&nbsp;virtual&nbsp;register&nbsp;is&nbsp;a&nbsp;good&nbsp;idea,&nbsp;but&nbsp;what&nbsp;I&nbsp;working&nbsp;on&nbsp;is&nbsp;a&nbsp;source-to-source&nbsp;converter,&nbsp;so&nbsp;I'd&nbsp;rather&nbsp;not&nbsp;to&nbsp;use&nbsp;any&nbsp;MachineFunctionPass.&nbsp;<BR><BR>Actually&nbsp;Google&nbsp;has&nbsp;told&nbsp;me&nbsp;a&nbsp;<BR><BR>------------------------------------------------<BR>--Zhanglin<BR>-----&nbsp;Original&nbsp;Message&nbsp;-----<BR>From:&nbsp;Jin&nbsp;Gu&nbsp;Kang&nbsp;&lt;jaykang10 at imrc.kist.re.kr&gt;<BR>To:&nbsp;Zhanglin&nbsp;Liu&nbsp;&lt;way_lzl at sina.com&gt;<BR>Subject:&nbsp;RE:&nbsp;[LLVMdev]&nbsp;Where&nbsp;is&nbsp;liveness&nbsp;analysis&nbsp;pass?<BR>Date:&nbsp;2011-1-13&nbsp;16:28:59<BR><BR>Hi&nbsp;Zhanglin.<BR><BR>First&nbsp;I&nbsp;suggest&nbsp;to&nbsp;read&nbsp;http://llvm.org/docs/CodeGenerator.html#liveintervals.&nbsp;:)<BR><BR>I&nbsp;saw&nbsp;the&nbsp;basic&nbsp;processing&nbsp;order&nbsp;of&nbsp;Live&nbsp;interval&nbsp;in&nbsp;backend&nbsp;LLVM&nbsp;source&nbsp;code&nbsp;as&nbsp;following:<BR>1.&nbsp;LiveVariables::runOnMachineFunction()&nbsp;"lib/CodeGen/LiveVariables.cpp"<BR>--&gt;&nbsp;This&nbsp;pass&nbsp;computes&nbsp;live&nbsp;variable&nbsp;information&nbsp;for&nbsp;each&nbsp;virtual&nbsp;register&nbsp;and&nbsp;register&nbsp;allocatable&nbsp;physical&nbsp;register&nbsp;in&nbsp;the&nbsp;function.&nbsp;(Target&nbsp;dependent)<BR>2.&nbsp;SlotIndexes::runOnMachineFunction()&nbsp;"lib/CodeGen/SlotIndexe
s.cpp"<BR>--&gt;&nbsp;This&nbsp;pass&nbsp;assigns&nbsp;indexes&nbsp;to&nbsp;each&nbsp;instruction&nbsp;and&nbsp;basic&nbsp;blocks<BR>3.&nbsp;LiveIntervals::runOnMachineFunction()&nbsp;"lib/CodeGen/LiveIntervalAnalysis.cpp"<BR>--&gt;&nbsp;This&nbsp;pass&nbsp;computes&nbsp;live&nbsp;interval&nbsp;for&nbsp;live&nbsp;variables.<BR>4.&nbsp;SimpleRegisterCoalescing::runOnMachineFunction&nbsp;"lib/CodeGen/SimpleRegisterCoalescing.cpp"&nbsp;<BR>-&gt;&nbsp;After&nbsp;SimpleRegisterCoalescing,&nbsp;live&nbsp;intervals&nbsp;are&nbsp;merged.<BR><BR>As&nbsp;you&nbsp;know,&nbsp;liveness&nbsp;inforamtion&nbsp;in&nbsp;backend&nbsp;is&nbsp;target&nbsp;dependent.<BR>If&nbsp;you&nbsp;want&nbsp;to&nbsp;use&nbsp;target&nbsp;independent&nbsp;liveness&nbsp;information,&nbsp;I&nbsp;suggest&nbsp;you&nbsp;to&nbsp;use&nbsp;live&nbsp;variable&nbsp;information&nbsp;for&nbsp;virtual&nbsp;register&nbsp;in&nbsp;"LiveVariables::runOnMachineFunction()"&nbsp;pass.<BR><BR>Best&nbsp;regards,<BR>Jin-Gu&nbsp;Kang<BR><BR><BR><BR><BR><BR><BR>________________________________________<BR>From:&nbsp;llvmdev-bounces at cs.uiuc.edu&nbsp;[llvmdev-bounces at cs.uiuc.edu]&nbsp;On&nbsp;Behalf&nbsp;Of&nbsp;Zhanglin&nbsp;Liu&nbsp;[way_lzl at sina.com]<BR>Sent:&nbsp;Thursday,&nbsp;January&nbsp;13,&nbsp;2011&nbsp;4:16&nbsp;PM<BR>To:&nbsp;llvmdev at cs.uiuc.edu<BR>Subject:&nbsp;[LLVMdev]&nbsp;Where&nbsp;is&nbsp;liveness&nbsp;analysis&nbsp;pass?<BR><BR>Hello&nbsp;all<BR><BR>Currently&nbsp;I&nbsp;want&nbsp;to&nbsp;use&nbsp;the&nbsp;accurate&nbsp;liveness&nbsp;information&nbsp;when&nbsp;writing&nbsp;a&nbsp;*target&nbsp;independent*&nbsp;FunctionPass&nbsp;based&nbsp;on&nbsp;LLVM.&nbsp;The&nbsp;one&nbsp;I&nbsp;can&nbsp;find&nbsp;is&nbsp;LiveValues,&nbsp;a&nbsp;FunctionPass.&nbsp;But&nbsp;it&nbsp;doesn't&nbsp;use&nbsp;classic&nbsp;dataflow&nbsp;equation&nbsp;and&nbsp;can&nbsp;only&nbsp;provide&nbsp;approximate&nbsp;and&nbsp;conservative&nbsp;result.&nbsp;The&nbsp;another&nbsp;one&nbsp;is&nbsp;LiveVariables&nbsp;which&nbsp;use&nbsp;classic&nbsp;data&nbsp;flow&nbsp;equation,&nbsp;but&nbs
p;it&nbsp;comes&nbsp;from&nbsp;Clang's&nbsp;analysis&nbsp;phase&nbsp;and&nbsp;only&nbsp;used&nbsp;in&nbsp;frontend.<BR><BR>My&nbsp;question&nbsp;is&nbsp;whether&nbsp;there&nbsp;is&nbsp;such&nbsp;a&nbsp;liveness&nbsp;analysis&nbsp;pass&nbsp;existed&nbsp;for&nbsp;FuntionPass?<BR><BR>Thanks&nbsp;for&nbsp;any&nbsp;suggestion.<BR>--------------------------------<BR>--Zhanglin 


From nicholas at mxc.ca  Thu Jan 13 02:46:14 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Thu, 13 Jan 2011 00:46:14 -0800
Subject: [LLVMdev] Extending LLVM for high-level types
In-Reply-To: <79261AB7-3203-4267-8CC0-EE2B11024E2F@gmail.com>
References: <79261AB7-3203-4267-8CC0-EE2B11024E2F@gmail.com>
Message-ID: <4D2EBBD6.40102@mxc.ca>

Alexandre Cossette wrote:
> Hi all,
>
> I'm designing a programming language named C? (or C3). I'm already using LLVM as a back-end for my prototype compiler and it's wonderful to use. Thanks for such a great system!
>
> I now have more ambitious goals and I would like to use the LLVM IR as my internal C? IR.

Absolutely not.

In short, LLVM is its own language. You don't need to extend LLVM IR to 
support your programming language any more than you need to extend x86 
processors to support it.

There's the burden of having that support. For starters LLVM's types are 
purely based on the storage that they back. Most languages use type to 
provide static program safety, or possibly semantics (ie., + means 
string concat on a string but addition on integers). LLVM doesn't do 
that. Further our types are uniqued such that any two types with the 
same in-memory representation have the same LLVM type; we don't discard 
names, but we don't preserve a distinction because there isn't any 
distinction to preserve. That in turn allows us to do fast structural 
comparisons using a pointer comparison.

Then we'd have to extend core passes like mem2reg, gvn, and all of their 
dependencies. These are performance critical pieces of kit, and we 
categorically reject any attempt to push in pieces of infrastructure 
that won't be needed by all users. Put another way, if I want to use 
LLVM for C code on a cell phone, I shouldn't need to pay the 
memory/execution-time price for your LLVM changes to support C?.

Finally, you haven't detailed what benefit you expect out of your 
proposal. Why can't you just lower to the existing IR and get the same 
optimizations out of it? What optimizations aren't possible and why? Can 
we tackle those issues instead? We've gotten very far by designing 
extensions to LLVM which are language-agnostic and can be used by any 
client. For example, if your language has alias analysis optimizations 
that rely on high-level type information, LLVM has a TBAA (type based 
aliasing analysis) design that you could employ to give LLVM the 
additional information it needs to optimize with.

Sorry to sound so negative, but I'm confident that LLVM can provide you 
with the same generated code quality in the same execution time, only 
through a different design than you propose. If you can show us missed 
optimizations (or bad compile time problems) when using the naive 
approach of lowering your high-level types to llvm's low-level types, 
please let us know so we can solve them case-by-case!

Nick

C? is designed to support what I call "value-oriented programming" and 
it fits naturally with the design of LLVM. The idea is to apply 
SSA-based optimizations on user-defined types.
>
> I would like to know if you think this plan makes sense:
> - Add a new derived type that is uniqued by name for C? types
> - Add new intrinsic functions for C? expressions with special semantics
> - Emit this "extended LLVM" from my abstract syntax tree
> - Run the mem2reg pass as is for SSA construction
> - Run optimization passes that can run as is with the new type (like GVN?)
> - Run a new pass that lowers the extended LLVM to normal LLVM
> - Run (or rerun) normal LLVM optimization passes
> - Emit native code using normal LLVM
> - Profit!
>
> Alex
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From way_lzl at sina.com  Thu Jan 13 02:55:15 2011
From: way_lzl at sina.com (Zhanglin Liu)
Date: Thu, 13 Jan 2011 16:55:15 +0800 
Subject: [LLVMdev] Where is liveness analysis pass?
Message-ID: <20110113085516.08957BDD09@mail2-95.sinamail.sina.com.cn>

Jin-Gu

Thanks for your suggestion. Using liveness information for virtual register is a good idea, but what I am working on is a source-to-source compiler, so I prefer to use FunctionPass instead of MachineFunctionPass.

Interestingly I found a FunctionPass example for classic liveness data flow equation.
http://cs.pub.ro/~cpl/wiki/images/1/15/Hello.txt


------------------------------------------------
--Zhanglin
----- Original Message -----
From: Jin Gu Kang <jaykang10 at imrc.kist.re.kr>
To: Zhanglin Liu <way_lzl at sina.com>
Subject: RE: [LLVMdev] Where is liveness analysis pass?
Date: 2011-1-13 16:28:59

Hi Zhanglin.

First I suggest to read http://llvm.org/docs/CodeGenerator.html#liveintervals. :)

I saw the basic processing order of Live interval in backend LLVM source code as following:
1. LiveVariables::runOnMachineFunction() "lib/CodeGen/LiveVariables.cpp"
--> This pass computes live variable information for each virtual register and register allocatable physical register in the function. (Target dependent)
2. SlotIndexes::runOnMachineFunction() "lib/CodeGen/SlotIndexes.cpp"
--> This pass assigns indexes to each instruction and basic blocks
3. LiveIntervals::runOnMachineFunction() "lib/CodeGen/LiveIntervalAnalysis.cpp"
--> This pass computes live interval for live variables.
4. SimpleRegisterCoalescing::runOnMachineFunction "lib/CodeGen/SimpleRegisterCoalescing.cpp" 
-> After SimpleRegisterCoalescing, live intervals are merged.

As you know, liveness inforamtion in backend is target dependent.
If you want to use target independent liveness information, I suggest you to use live variable information for virtual register in "LiveVariables::runOnMachineFunction()" pass.

Best regards,
Jin-Gu Kang


From ww345ww at gmail.com  Thu Jan 13 05:03:37 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Thu, 13 Jan 2011 19:03:37 +0800
Subject: [LLVMdev] About test suits
Message-ID: <AANLkTimQ2K1Gy6xciLg2Ef7P2wiyda8cEjEVQKR+3L_Y@mail.gmail.com>

Hi sir,
I have built the test suits in following steps:
0. $cd LLVM_GCC_DIR;            $gunzip --stdout llvm-gcc-4.2-*version*-*
platform*.tar.gz | tar -xvf -
1. $cd SRC_DIR/llvm-2.8/projects
2. $svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
3.$cd OBJ_DIR; 4. $SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime
 --disable-optimized --enable-debug-symbols --enable-assertions
--with-llvmgccdir=LLVM_GCC_DIR
5. $make.
6. $cd OBJ_DIR/projects/test_suits;             $make

Then the following error ocurred.
[qali at qali test-suite]$ make
make[1]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource'
make[2]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
make[3]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
make[4]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
/home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as
Output/sse.expandfft.ll -o Output/sse.expandfft.bc
/home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as:
Output/sse.expandfft.ll:1:2: error: expected top-level entity
.file
"/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c"
^
make[4]: *** [Output/sse.expandfft.bc] Error 1
make[4]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
make[3]: *** [all] Error 1
make[3]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
make[2]: *** [all] Error 1
make[2]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
make[1]: *** [UnitTests/.makeall] Error 2
make[1]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource'
make: *** [SingleSource/.makeall] Error 2

As told by Chris Lattner*, *I tested my llvm-gcc like this:
[qali at qali test-suite]$ llvm-gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/nicholas/2.8-final/llvmgcc42-2.8.src/configure
--prefix=/home/nicholas/2.8-final/Phase2/Release/llvmgcc42-2.8.install
--program-prefix=llvm-
--enable-llvm=/home/nicholas/2.8-final/Phase2/Release/llvmCore-2.8.obj
--disable-multilib --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2.8)

I also tried reconfigure llvm from OBJ_DIR, by re-execute step 4 above. But,
it did not work.

I used 'tree' in the SingleSource directory:
[qali at qali SingleSource]$ tree
.
|-- Makefile
|-- Makefile.singlesrc
`-- UnitTests
    |-- Makefile
    `-- Vector
        |-- Makefile
        `-- SSE
            |-- Makefile
            `-- Output
                `-- sse.expandfft.ll

4 directories, 6 files


I need help to build the test suits .



-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110113/eb8a2b7d/attachment-0001.html 

From rob.nikander at gmail.com  Thu Jan 13 07:36:36 2011
From: rob.nikander at gmail.com (Rob Nikander)
Date: Thu, 13 Jan 2011 08:36:36 -0500
Subject: [LLVMdev] How to define a global variable?
In-Reply-To: <AANLkTimBSgwKYn59a9X2dbhMF5R6cgLe2ZjHjQVbpnp4@mail.gmail.com>
References: <AANLkTimLmm67Wr8DWYr==hdM5e1=0s8OJp8d5z8m+wP8@mail.gmail.com>
	<AANLkTimBSgwKYn59a9X2dbhMF5R6cgLe2ZjHjQVbpnp4@mail.gmail.com>
Message-ID: <AANLkTik6fBiNn9uabA3f1+_55xVS17w0Be3UiOwCteDB@mail.gmail.com>

On Thu, Jan 13, 2011 at 2:34 AM, Frits van Bommel <fvbommel at gmail.com> wrote:
> On Wed, Jan 12, 2011 at 11:28 PM, Rob Nikander <rob.nikander at gmail.com> wrote:
>
> First, replace %0* with a concrete type (like the i8* in your later post).
> Then give @x an initializer. 'undef' is good enough if you don't want
> to assign an actual value yet. This should turn it into a definition
> instead of a declaration.

Thanks, the initializer did it.  Using opaque* works, at least in this
case; but I've replaced it with i8*.

Rob

From atsezeriakob at gmail.com  Thu Jan 13 08:58:24 2011
From: atsezeriakob at gmail.com (Atse Zeriakob)
Date: Thu, 13 Jan 2011 15:58:24 +0100
Subject: [LLVMdev] llc linkage problem
Message-ID: <AANLkTi=ymmdWej-igqV6fckHvugtQaZCbvvHc3KG1gQk@mail.gmail.com>

I am using LLVM 2.8 on Ubuntu 10.10. (new to both)



I change name of instruction on XXXInstrInfo.td ( Sparc, X86 and XCore).  I
looked into XXXGenAsmWriter.inc and I have seen the new instruction name.
But when I run llc for the three targets it prints out the old instruction
name.



For example for XCore I change ?divs? to ?sdiv? like



>From =>    def DIVS_l3r : FL3R<"divs", sdiv>;// divs



To =>      def DIVS_l3r : FL3R<"sdiv", sdiv>;//sdiv



But I can see the effect of my change when I run



llc test1.bc ?march=xcore ?o asmXcore.s



If this is linkage problem how can I solve it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110113/5a9ea3a5/attachment.html 

From bnwest at rice.edu  Thu Jan 13 09:51:26 2011
From: bnwest at rice.edu (Brian West)
Date: Thu, 13 Jan 2011 15:51:26 +0000 (UTC)
Subject: [LLVMdev] Question about nsw and nuw flags
References: <AANLkTi=4E_bqVP9zs2-OoJiLdzMhnSpQ46_aw03VFp7W@mail.gmail.com>
Message-ID: <loom.20110113T165004-265@post.gmane.org>

Douglas do Couto Teixeira <douglasdocouto <at> gmail.com> writes:
> Hi everybody,I saw that there are some instructions in the programs in which
the flag nsw or nuw is placed. I wonder what rules does LLVM follows to put
these flags in some instructions.Best,Douglas

Language requirements appears to drive their placement.  In C, "signed int" 
overflow produces a trap value and undefined behavior.  Thus, C "signed int" 
operations do not wrap on overflow and get tagged with "nsw" in the LLVM IR.

Brian West




From anton at korobeynikov.info  Thu Jan 13 10:09:56 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Thu, 13 Jan 2011 19:09:56 +0300
Subject: [LLVMdev] llc linkage problem
In-Reply-To: <AANLkTi=ymmdWej-igqV6fckHvugtQaZCbvvHc3KG1gQk@mail.gmail.com>
References: <AANLkTi=ymmdWej-igqV6fckHvugtQaZCbvvHc3KG1gQk@mail.gmail.com>
Message-ID: <AANLkTi=tpxyjycivoLgHPKxn6qFr1tpcYmtBLH0HOYR1@mail.gmail.com>

> llc test1.bc ?march=xcore ?o asmXcore.s
> If this is linkage problem how can I solve it?
If you see the correct result, what's the problem then?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From rengolin at systemcall.org  Thu Jan 13 10:59:16 2011
From: rengolin at systemcall.org (Renato Golin)
Date: Thu, 13 Jan 2011 16:59:16 +0000
Subject: [LLVMdev] llc linkage problem
In-Reply-To: <AANLkTi=ymmdWej-igqV6fckHvugtQaZCbvvHc3KG1gQk@mail.gmail.com>
References: <AANLkTi=ymmdWej-igqV6fckHvugtQaZCbvvHc3KG1gQk@mail.gmail.com>
Message-ID: <AANLkTin7-bcTdm-dzkaYs8LbDJVDF3M_ohjNZEPFyjPc@mail.gmail.com>

On 13 January 2011 14:58, Atse Zeriakob <atsezeriakob at gmail.com> wrote:
> But when I run llc for the three targets it prints out the old instruction
> name.

What is the llc command line when it doesn't work?

--renato

From kledzik at apple.com  Thu Jan 13 13:07:52 2011
From: kledzik at apple.com (Nick Kledzik)
Date: Thu, 13 Jan 2011 11:07:52 -0800
Subject: [LLVMdev] CMake and Xcode
Message-ID: <F576DB2F-0CAA-4872-9B9B-9B686F29AF5B@apple.com>

I've been using make to build llvm but use Xcode for most other projects I work on.  I decided to try running cmake to build an xcode project for llvm.  The results were disappointing.  

The generated xcode project does not encode that executables link with static libraries.  Instead, the static libraries are snuck in under "Other linker flags", then some pre- and post- scripts on every target are run which cause xcode to re-check mod times on files and forces a re-link.  This is painfully slow.  What should be a two second: recompile file, update static library, re-link executable turns into a 15 second running of dozens of shells scripts that touch and copy files.  

I tried making a simple cmake project with a static library and a main executable, and saw the same crazy xcode project generated.  

Are there cmake settings to correct this?  Is there some reason the xcode projects are made like this?  Or is is just that the cmake maintainers have not had the time to invest in generated proper xcode projects?

-Nick



From ofv at wanadoo.es  Thu Jan 13 13:29:01 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Thu, 13 Jan 2011 20:29:01 +0100
Subject: [LLVMdev] CMake and Xcode
References: <F576DB2F-0CAA-4872-9B9B-9B686F29AF5B@apple.com>
Message-ID: <87lj2oeh6q.fsf@wanadoo.es>

Nick Kledzik <kledzik at apple.com> writes:

> I've been using make to build llvm but use Xcode for most other
> projects I work on.  I decided to try running cmake to build an xcode
> project for llvm.  The results were disappointing.

Sorry to hear this.

> The generated xcode project does not encode that executables link with
> static libraries.  Instead, the static libraries are snuck in under
> "Other linker flags", then some pre- and post- scripts on every target
> are run which cause xcode to re-check mod times on files and forces a
> re-link.  This is painfully slow.  What should be a two second:
> recompile file, update static library, re-link executable turns into a
> 15 second running of dozens of shells scripts that touch and copy
> files.
>
> I tried making a simple cmake project with a static library and a main
> executable, and saw the same crazy xcode project generated.
>
> Are there cmake settings to correct this?  Is there some reason the
> xcode projects are made like this?  Or is is just that the cmake
> maintainers have not had the time to invest in generated proper xcode
> projects?

I have no access to an OS/X machine so there is little I can do about
this issues. However, your description indicates that those are generic
cmake issues and not restricted to LLVM. I suggest that you re-post your
message to the cmake mailing list:

http://www.cmake.org/cmake/help/mailing.html

(posting through gmane works fine.) The cmake guys are quite friendly
and eager to help.


From samuraileumas at yahoo.com  Thu Jan 13 13:33:00 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Thu, 13 Jan 2011 11:33:00 -0800 (PST)
Subject: [LLVMdev] CMake and Xcode
In-Reply-To: <F576DB2F-0CAA-4872-9B9B-9B686F29AF5B@apple.com>
References: <F576DB2F-0CAA-4872-9B9B-9B686F29AF5B@apple.com>
Message-ID: <898491.78153.qm@web62006.mail.re1.yahoo.com>

Hi Nick,

The CMake devlopers at KitWare work mainly on high-end parallel processing 
supercomputers.  Macs aren't their highest priority usually since their machines 
run primarily Linux and Unix.  If you want to streamline the XCode code 
generator, I'm afraid you'll have to get on the CMake mailing list and talk to 
the developers yourself.

Sorry I couldn't be more help,

--Sam


----- Original Message ----
> From: Nick Kledzik <kledzik at apple.com>
> To: LLVMdev Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Thu, January 13, 2011 1:07:52 PM
> Subject: [LLVMdev] CMake and Xcode
> 
> I've been using make to build llvm but use Xcode for most other projects I work  
>on.  I decided to try running cmake to build an xcode project for  llvm.  The 
>results were disappointing.  
>
> 
> The generated xcode  project does not encode that executables link with static 
>libraries.   Instead, the static libraries are snuck in under "Other linker 
>flags", then some  pre- and post- scripts on every target are run which cause 
>xcode to re-check mod  times on files and forces a re-link.  This is painfully 
>slow.  What  should be a two second: recompile file, update static library, 
>re-link  executable turns into a 15 second running of dozens of shells scripts 
>that touch  and copy files.  
>
> 
> I tried making a simple cmake project with a  static library and a main 
>executable, and saw the same crazy xcode project  generated.  
>
> 
> Are there cmake settings to correct this?  Is  there some reason the xcode 
>projects are made like this?  Or is is just  that the cmake maintainers have not 
>had the time to invest in generated proper  xcode  projects?
> 
> -Nick
> 
> 
> _______________________________________________
> LLVM  Developers mailing list
> LLVMdev at cs.uiuc.edu           http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


      

From rengolin at systemcall.org  Thu Jan 13 13:44:06 2011
From: rengolin at systemcall.org (Renato Golin)
Date: Thu, 13 Jan 2011 19:44:06 +0000
Subject: [LLVMdev] llc linkage problem
In-Reply-To: <AANLkTino+3=yieTfryQzHkdN3JC15=37xsnxcPqup3VX@mail.gmail.com>
References: <AANLkTi=ymmdWej-igqV6fckHvugtQaZCbvvHc3KG1gQk@mail.gmail.com>
	<AANLkTin7-bcTdm-dzkaYs8LbDJVDF3M_ohjNZEPFyjPc@mail.gmail.com>
	<AANLkTino+3=yieTfryQzHkdN3JC15=37xsnxcPqup3VX@mail.gmail.com>
Message-ID: <AANLkTinSyCX5iR9shTyK_QgkHxkGsN_jhQorqBO11kjA@mail.gmail.com>

On 13 January 2011 19:20, Atse Zeriakob <atsezeriakob at gmail.com> wrote:
> For example in XCoreInstrInfo.td I change the name of one of the instruction
> let say "divs" to "newdivs",
>
> like
> def DIVS_l3r : FL3R<"newdivs", sdiv>;
>
> When I run llc with option -march=xcore, after I make the modification, it
> still outputs "divs", not "newdivs". I looked into XCoreGenAsmWriter.inc,
> and made sure that string AsmStrs includes "newdivs".

I don't know if the tablegen gets rebuilt when you re-compile llvm,
but it could also be that you are changing the wrong rule...

I'll leave the tablegen experts answer that... ;)

cheers,
--renato

From atsezeriakob at gmail.com  Thu Jan 13 14:32:32 2011
From: atsezeriakob at gmail.com (Atse Zeriakob)
Date: Thu, 13 Jan 2011 21:32:32 +0100
Subject: [LLVMdev] need help on llc option -march=?
Message-ID: <AANLkTi=+VJFFmF_JcZ55ijHQJseTFieRhHsWOaWPOFZZ@mail.gmail.com>

I am using LLVM 2.8 on Ubuntu 10.10. (new to both)



I change name of instruction on XXXInstrInfo.td ( Sparc, X86 and XCore).  I
looked into XXXGenAsmWriter.inc and I have seen the new instruction name.
But when I run llc for the three targets it prints out the old instruction
name.



For example in XCoreInstrInfo.td I change the name of one of the instruction
let say "divs" to "newdivs",



like

def DIVS_l3r : FL3R<"newdivs", sdiv>;



When I run llc with option -march=xcore, after I make the modification, it
still outputs "divs", not "newdivs". I looked into XCoreGenAsmWriter.inc,
and made sure that string AsmStrs includes "newdivs".







If this is linkage problem how can I solve it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110113/91503e71/attachment.html 

From clattner at apple.com  Thu Jan 13 15:13:08 2011
From: clattner at apple.com (Chris Lattner)
Date: Thu, 13 Jan 2011 13:13:08 -0800
Subject: [LLVMdev] About test suits
In-Reply-To: <AANLkTimQ2K1Gy6xciLg2Ef7P2wiyda8cEjEVQKR+3L_Y@mail.gmail.com>
References: <AANLkTimQ2K1Gy6xciLg2Ef7P2wiyda8cEjEVQKR+3L_Y@mail.gmail.com>
Message-ID: <39687AA7-F1DD-45D3-8B02-8251D20C6A96@apple.com>


On Jan 13, 2011, at 3:03 AM, Qingan Li wrote:

> Hi sir,
> I have built the test suits in following steps:
> 0. $cd LLVM_GCC_DIR;            $gunzip --stdout llvm-gcc-4.2-version-platform.tar.gz | tar -xvf -
> 1. $cd SRC_DIR/llvm-2.8/projects
> 2. $svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
> 3.$cd OBJ_DIR; 
> 4. $SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime  --disable-optimized --enable-debug-symbols --enable-assertions --with-llvmgccdir=LLVM_GCC_DIR
> 5. $make.
> 6. $cd OBJ_DIR/projects/test_suits;             $make
> 
> Then the following error ocurred. 
> [qali at qali test-suite]$ make
> make[1]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource'
> make[2]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
> make[3]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
> make[4]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as Output/sse.expandfft.ll -o Output/sse.expandfft.bc
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as: Output/sse.expandfft.ll:1:2: error: expected top-level entity
> 	.file	"/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c"
> 	^
> make[4]: *** [Output/sse.expandfft.bc] Error 1
> make[4]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
> make[3]: *** [all] Error 1
> make[3]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
> make[2]: *** [all] Error 1
> make[2]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
> make[1]: *** [UnitTests/.makeall] Error 2
> make[1]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource'
> make: *** [SingleSource/.makeall] Error 2

What does this print if you use "make VERBOSE=1"?

-Chris

> 
> As told by Chris Lattner, I tested my llvm-gcc like this:
> [qali at qali test-suite]$ llvm-gcc -v
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: /home/nicholas/2.8-final/llvmgcc42-2.8.src/configure --prefix=/home/nicholas/2.8-final/Phase2/Release/llvmgcc42-2.8.install --program-prefix=llvm- --enable-llvm=/home/nicholas/2.8-final/Phase2/Release/llvmCore-2.8.obj --disable-multilib --enable-languages=c,c++,fortran
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2.8)
> 
> I also tried reconfigure llvm from OBJ_DIR, by re-execute step 4 above. But, it did not work. 
> 
> I used 'tree' in the SingleSource directory:
> [qali at qali SingleSource]$ tree
> .
> |-- Makefile
> |-- Makefile.singlesrc
> `-- UnitTests
>     |-- Makefile
>     `-- Vector
>         |-- Makefile
>         `-- SSE
>             |-- Makefile
>             `-- Output
>                 `-- sse.expandfft.ll
> 
> 4 directories, 6 files
> 
> 
> I need help to build the test suits .
> 
> 
> 
> -- 
> Best regards,
> 
> Li Qingan
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110113/48bd2b05/attachment.html 

From samuraileumas at yahoo.com  Thu Jan 13 16:12:53 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Thu, 13 Jan 2011 14:12:53 -0800 (PST)
Subject: [LLVMdev] Circular Deps from CMake build using makefile
Message-ID: <820891.76867.qm@web62006.mail.re1.yahoo.com>

[ 73%] Regenerating 
/Users/samuraicrow/Documents/workspace/llvm-trunk-build/tools/llvm-config/LibDeps.txt.tmp

[ 73%] Updating 
/Users/samuraicrow/Documents/workspace/llvm-trunk-build/tools/llvm-config/LibDeps.txt
 if necessary...
[ 73%] Checking for cyclic dependencies between LLVM libraries.
find-cycles.pl: Circular dependency between *.a files:
find-cycles.pl:   libLLVMAsmPrinter.a libLLVMXCoreAsmPrinter.a
find-cycles.pl: Circular dependency between *.a files:
find-cycles.pl:   libLLVMSupport.a libLLVMSystem.a
make[2]: *** [tools/llvm-config/FinalLibDeps.txt] Error 2
make[1]: *** [tools/llvm-config/CMakeFiles/llvm-config.target.dir/all] Error 2
make: *** [all] Error 2

That is the error I get when building with make -j2 on my Mac Mini.  (It is a 
Core 2 Duo with 2 GB of RAM.)

I have been able to build LLVM with XCode projects created with CMake 2.8-3 
before but when building Clang also, the build scripts take up too much RAM. 
 (About 2.6 GB virtual memory not counting the usage by GCC to execute the 
build.)  I thought I'd try building with Make instead to alleviate some memory 
problems.  Is there something wrong with the bundled version of PERL that comes 
with MacOSX 10.6.6?  Will building from the configure script fix matters at all?

Thanks for answering my questions,

--Sam Crow


      

From alex.cossette at gmail.com  Thu Jan 13 16:30:35 2011
From: alex.cossette at gmail.com (Alexandre Cossette)
Date: Thu, 13 Jan 2011 17:30:35 -0500
Subject: [LLVMdev] Extending LLVM for high-level types
In-Reply-To: <4D2EBBD6.40102@mxc.ca>
References: <79261AB7-3203-4267-8CC0-EE2B11024E2F@gmail.com>
	<4D2EBBD6.40102@mxc.ca>
Message-ID: <20E37287-8F55-4DF3-8E8B-07A884508BE1@gmail.com>

Nick Lewycky wrote:
> Alexandre Cossette wrote:
>> Hi all,
>> 
>> I'm designing a programming language named C? (or C3). I'm already using LLVM as a back-end for my prototype compiler and it's wonderful to use. Thanks for such a great system!
>> 
>> I now have more ambitious goals and I would like to use the LLVM IR as my internal C? IR.
> 
> Absolutely not.
> 
> In short, LLVM is its own language. You don't need to extend LLVM IR to support your programming language any more than you need to extend x86 processors to support it.

I guess I did not express myself clearly. I know I can have my own IR and compile that to LLVM IR. I simply see an opportunity to externally extend the existing system for high-level optimizations instead of writing my own SSA form IR from scratch. I had no intention to change anything inside the LLVM code base! (Except bugs I might find.)

After further investigation, I see that the Type class hierarchy does not allow for external extension because of the TypeID enum. Maybe I could hack something using opaque types?

> There's the burden of having that support. For starters LLVM's types are purely based on the storage that they back. Most languages use type to provide static program safety, or possibly semantics (ie., + means string concat on a string but addition on integers). LLVM doesn't do that. Further our types are uniqued such that any two types with the same in-memory representation have the same LLVM type; we don't discard names, but we don't preserve a distinction because there isn't any distinction to preserve. That in turn allows us to do fast structural comparisons using a pointer comparison.

Some C? semantics would be handled as transformations inside my custom pass (most would be already handled by my front-end). Regarding the fact that types are "uniqued",  I want to note that opaque types are not. To what extent can I keep those around while executing passes?

> Then we'd have to extend core passes like mem2reg, gvn, and all of their dependencies. These are performance critical pieces of kit, and we categorically reject any attempt to push in pieces of infrastructure that won't be needed by all users. Put another way, if I want to use LLVM for C code on a cell phone, I shouldn't need to pay the memory/execution-time price for your LLVM changes to support C?.

As I understand it, mem2reg only relies on "alloca", "store" and "load" instructions. The algorithm is non-trivial (that's why I want to use it instead of coding my own) but does not seem to have complicated dependencies. Am I right?

> Finally, you haven't detailed what benefit you expect out of your proposal. Why can't you just lower to the existing IR and get the same optimizations out of it? What optimizations aren't possible and why? Can we tackle those issues instead? We've gotten very far by designing extensions to LLVM which are language-agnostic and can be used by any client. For example, if your language has alias analysis optimizations that rely on high-level type information, LLVM has a TBAA (type based aliasing analysis) design that you could employ to give LLVM the additional information it needs to optimize with.

One scenario that I have in mind is being able to do common subexpression elimination before doing what I call "object allocation" (in analogy to "register allocation"). The result is less temporary objects and therefore less constructor/destructor calls and better resource usage. Contrary to C++, the transformations are sound because all C? types are regular, by Alex Stepanov's definition of "regular types".

Thanks for pointing out TBAA. Comments in LLVM 2.8 says "This is a work-in-progress. It doesn't work yet, and the metadata format isn't stable." What's the current status?

> Sorry to sound so negative, but I'm confident that LLVM can provide you with the same generated code quality in the same execution time, only through a different design than you propose. If you can show us missed optimizations (or bad compile time problems) when using the naive approach of lowering your high-level types to llvm's low-level types, please let us know so we can solve them case-by-case!

It's all right. Don't worry, I don't want to turn LLVM inside out :)
That being said, I still believe there is a way I could use that nice mem2reg pass for my purpose...

Alex

From ofv at wanadoo.es  Thu Jan 13 16:49:56 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Thu, 13 Jan 2011 23:49:56 +0100
Subject: [LLVMdev] Circular Deps from CMake build using makefile
In-Reply-To: <820891.76867.qm@web62006.mail.re1.yahoo.com> (Samuel Crow's
	message of "Thu, 13 Jan 2011 14:12:53 -0800 (PST)")
References: <820891.76867.qm@web62006.mail.re1.yahoo.com>
Message-ID: <87d3o0e7vv.fsf@wanadoo.es>

Samuel Crow <samuraileumas at yahoo.com> writes:

> [ 73%] Regenerating 
> /Users/samuraicrow/Documents/workspace/llvm-trunk-build/tools/llvm-config/LibDeps.txt.tmp
>
> [ 73%] Updating 
> /Users/samuraicrow/Documents/workspace/llvm-trunk-build/tools/llvm-config/LibDeps.txt
>  if necessary...
> [ 73%] Checking for cyclic dependencies between LLVM libraries.
> find-cycles.pl: Circular dependency between *.a files:
> find-cycles.pl:   libLLVMAsmPrinter.a libLLVMXCoreAsmPrinter.a

Hmmm...

> find-cycles.pl: Circular dependency between *.a files:
> find-cycles.pl:   libLLVMSupport.a libLLVMSystem.a

This one is very odd.

> make[2]: *** [tools/llvm-config/FinalLibDeps.txt] Error 2
> make[1]: *** [tools/llvm-config/CMakeFiles/llvm-config.target.dir/all] Error 2
> make: *** [all] Error 2
>
> That is the error I get when building with make -j2 on my Mac Mini.  (It is a 
> Core 2 Duo with 2 GB of RAM.)

Cannot reproduce on Linux.

Please try this:

make clean
make -j2

If that fails,

make clean
make

> I have been able to build LLVM with XCode projects created with CMake 2.8-3 
> before but when building Clang also, the build scripts take up too much RAM. 
>  (About 2.6 GB virtual memory not counting the usage by GCC to execute the 
> build.)  I thought I'd try building with Make instead to alleviate some memory 
> problems.  Is there something wrong with the bundled version of PERL that comes 
> with MacOSX 10.6.6?  Will building from the configure script fix matters at all?

If the above fails, it would be helpful to know if configure&&make works
(on a new build directory).

From andrew at sidefx.com  Thu Jan 13 18:54:32 2011
From: andrew at sidefx.com (Andrew Clinton)
Date: Thu, 13 Jan 2011 19:54:32 -0500
Subject: [LLVMdev] Extending LLVM for high-level types
In-Reply-To: <4D2EBBD6.40102@mxc.ca>
References: <79261AB7-3203-4267-8CC0-EE2B11024E2F@gmail.com>
	<4D2EBBD6.40102@mxc.ca>
Message-ID: <4D2F9EC8.2090403@sidefx.com>

On 01/13/2011 03:46 AM, Nick Lewycky wrote:
> Absolutely not.
>
> In short, LLVM is its own language. You don't need to extend LLVM IR to
> support your programming language any more than you need to extend x86
> processors to support it.
>
> There's the burden of having that support. For starters LLVM's types are
> purely based on the storage that they back. Most languages use type to
> provide static program safety, or possibly semantics (ie., + means
> string concat on a string but addition on integers). LLVM doesn't do
> that. Further our types are uniqued such that any two types with the
> same in-memory representation have the same LLVM type; we don't discard
> names, but we don't preserve a distinction because there isn't any
> distinction to preserve. That in turn allows us to do fast structural
> comparisons using a pointer comparison.
>
> Then we'd have to extend core passes like mem2reg, gvn, and all of their
> dependencies. These are performance critical pieces of kit, and we
> categorically reject any attempt to push in pieces of infrastructure
> that won't be needed by all users. Put another way, if I want to use
> LLVM for C code on a cell phone, I shouldn't need to pay the
> memory/execution-time price for your LLVM changes to support C?.
>
> Finally, you haven't detailed what benefit you expect out of your
> proposal. Why can't you just lower to the existing IR and get the same
> optimizations out of it? What optimizations aren't possible and why? Can
> we tackle those issues instead? We've gotten very far by designing
> extensions to LLVM which are language-agnostic and can be used by any
> client. For example, if your language has alias analysis optimizations
> that rely on high-level type information, LLVM has a TBAA (type based
> aliasing analysis) design that you could employ to give LLVM the
> additional information it needs to optimize with.
>
> Sorry to sound so negative, but I'm confident that LLVM can provide you
> with the same generated code quality in the same execution time, only
> through a different design than you propose. If you can show us missed
> optimizations (or bad compile time problems) when using the naive
> approach of lowering your high-level types to llvm's low-level types,
> please let us know so we can solve them case-by-case!
>
> Nick


I think that what Alexandre wants to do is to leverage the power of the 
LLVM SSA transformation/optimization framework for types that might not 
be natively defined by LLVM.  This is something that I believe is 
already possible in LLVM (with the addition of some select user-defined 
passes and careful use of types), but it can be awkward to use due to 
the structure typing inherent in LLVM.  For example, I define one of the 
custom types in my language to i64, but this only makes sense as long as 
I can uniquely identify this type as i64 - that is I haven't overloaded 
i64 to mean anything else.  Other types could be introduced as other 
bit-width integers (i65), structure types, etc.  So it's possible, if 
not clean.

Actually, looking over the list of optimizations on LLVM IR I'm having 
trouble finding more than a handful that explicitly rely on the storage 
type of all data.  So it seems like a very valid use case to use LLVM 
for optimization with user-specific types within SSA form, before 
lowering the code (or translating back to source).

Andrew

From alex.cossette at gmail.com  Thu Jan 13 19:45:07 2011
From: alex.cossette at gmail.com (Alexandre Cossette)
Date: Thu, 13 Jan 2011 20:45:07 -0500
Subject: [LLVMdev] Extending LLVM for high-level types
In-Reply-To: <4D2F9EC8.2090403@sidefx.com>
References: <79261AB7-3203-4267-8CC0-EE2B11024E2F@gmail.com>
	<4D2EBBD6.40102@mxc.ca> <4D2F9EC8.2090403@sidefx.com>
Message-ID: <901AC864-25F3-46E9-918D-741BB02D83D5@gmail.com>

On 2011-01-13, at 7:54 PM, Andrew Clinton wrote:
> On 01/13/2011 03:46 AM, Nick Lewycky wrote:
>> In short, LLVM is its own language. You don't need to extend LLVM IR to
>> support your programming language any more than you need to extend x86
>> processors to support it.
> 
> I think that what Alexandre wants to do is to leverage the power of the 
> LLVM SSA transformation/optimization framework for types that might not 
> be natively defined by LLVM.
Yes, exactly!

> This is something that I believe is 
> already possible in LLVM (with the addition of some select user-defined 
> passes and careful use of types), but it can be awkward to use due to 
> the structure typing inherent in LLVM.  For example, I define one of the 
> custom types in my language to i64, but this only makes sense as long as 
> I can uniquely identify this type as i64 - that is I haven't overloaded 
> i64 to mean anything else.  Other types could be introduced as other 
> bit-width integers (i65), structure types, etc.  So it's possible, if 
> not clean.
Isn't it dangerous to use integer types like this? Optimization passes might introduce bitcasts or other instructions that assume integer semantics.

> Actually, looking over the list of optimizations on LLVM IR I'm having 
> trouble finding more than a handful that explicitly rely on the storage 
> type of all data.  So it seems like a very valid use case to use LLVM 
> for optimization with user-specific types within SSA form, before 
> lowering the code (or translating back to source).
I have a hard time making sure it's the case by just reading the passes source code. LLVM often assumes that its set of types is fixed and takes shortcuts.

Alex



From clattner at apple.com  Thu Jan 13 20:08:26 2011
From: clattner at apple.com (Chris Lattner)
Date: Thu, 13 Jan 2011 18:08:26 -0800
Subject: [LLVMdev] About test suits
In-Reply-To: <AANLkTinKFy2ficmcby6WqB_Zih_Huh7PUATvAGNmDZMq@mail.gmail.com>
References: <AANLkTimQ2K1Gy6xciLg2Ef7P2wiyda8cEjEVQKR+3L_Y@mail.gmail.com>
	<39687AA7-F1DD-45D3-8B02-8251D20C6A96@apple.com>
	<AANLkTinKFy2ficmcby6WqB_Zih_Huh7PUATvAGNmDZMq@mail.gmail.com>
Message-ID: <A1BF26E9-7400-4988-9874-A600AA42BEE8@apple.com>

Please email the list, not me directly.

Try doing a 'make clean' then a 'make VERBOSE=1' in the test-suite directory.

-Chris

On Jan 13, 2011, at 6:04 PM, Qingan Li wrote:

> Hi Chris,
> 
> [qali at qali SingleSource]$ llvm-gcc -v
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: /home/nicholas/2.8-final/llvmgcc42-2.8.src/configure --prefix=/home/nicholas/2.8-final/Phase2/Release/llvmgcc42-2.8.install --program-prefix=llvm- --enable-llvm=/home/nicholas/2.8-final/Phase2/Release/llvmCore-2.8.obj --disable-multilib --enable-languages=c,c++,fortran
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2.8)
> 
> [qali at qali SingleSource]$ make VERBOSE=1
> if [ ! -f UnitTests/Makefile ]; \
> 	then \
> 		/home/qali/Src/llvm-2.8/autoconf/mkinstalldirs UnitTests; \
> 		cp /home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Makefile UnitTests/Makefile; \
> 	fi; \
> 	make -C UnitTests all 
> make[1]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
> for dir in  Vector  SignlessTypes Threads; do \
> 		if [ ! -f $dir/Makefile ]; \
> 		then \
> 			/home/qali/Src/llvm-2.8/autoconf/mkinstalldirs $dir; \
> 			cp /home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/$dir/Makefile $dir/Makefile; \
> 		fi; \
> 		(make -C $dir all -w) || exit 1; \
> 	done
> make[2]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
> for dir in  SSE; do \
> 		if [ ! -f $dir/Makefile ]; \
> 		then \
> 			/home/qali/Src/llvm-2.8/autoconf/mkinstalldirs $dir; \
> 			cp /home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/$dir/Makefile $dir/Makefile; \
> 		fi; \
> 		(make -C $dir all -w) || exit 1; \
> 	done
> make[3]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as Output/sse.expandfft.ll -o Output/sse.expandfft.bc
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as: Output/sse.expandfft.ll:1:2: error: expected top-level entity
> 	.file	"/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c"
> 	^
> make[3]: *** [Output/sse.expandfft.bc] Error 1
> make[3]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
> make[2]: *** [all] Error 1
> make[2]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
> make[1]: *** [all] Error 1
> make[1]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
> make: *** [UnitTests/.makeall] Error 2
> 
> 
> 2011/1/14 Chris Lattner <clattner at apple.com>
> 
> On Jan 13, 2011, at 3:03 AM, Qingan Li wrote:
> 
>> Hi sir,
>> I have built the test suits in following steps:
>> 0. $cd LLVM_GCC_DIR;            $gunzip --stdout llvm-gcc-4.2-version-platform.tar.gz | tar -xvf -
>> 1. $cd SRC_DIR/llvm-2.8/projects
>> 2. $svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
>> 3.$cd OBJ_DIR; 
>> 4. $SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime  --disable-optimized --enable-debug-symbols --enable-assertions --with-llvmgccdir=LLVM_GCC_DIR
>> 5. $make.
>> 6. $cd OBJ_DIR/projects/test_suits;             $make
>> 
>> Then the following error ocurred. 
>> [qali at qali test-suite]$ make
>> make[1]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource'
>> make[2]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
>> make[3]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
>> make[4]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
>> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as Output/sse.expandfft.ll -o Output/sse.expandfft.bc
>> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as: Output/sse.expandfft.ll:1:2: error: expected top-level entity
>> 	.file	"/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c"
>> 	^
>> make[4]: *** [Output/sse.expandfft.bc] Error 1
>> make[4]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
>> make[3]: *** [all] Error 1
>> make[3]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
>> make[2]: *** [all] Error 1
>> make[2]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
>> make[1]: *** [UnitTests/.makeall] Error 2
>> make[1]: Leaving directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource'
>> make: *** [SingleSource/.makeall] Error 2
> 
> What does this print if you use "make VERBOSE=1"?
> 
> -Chris
> 
>> 
>> As told by Chris Lattner, I tested my llvm-gcc like this:
>> [qali at qali test-suite]$ llvm-gcc -v
>> Using built-in specs.
>> Target: x86_64-unknown-linux-gnu
>> Configured with: /home/nicholas/2.8-final/llvmgcc42-2.8.src/configure --prefix=/home/nicholas/2.8-final/Phase2/Release/llvmgcc42-2.8.install --program-prefix=llvm- --enable-llvm=/home/nicholas/2.8-final/Phase2/Release/llvmCore-2.8.obj --disable-multilib --enable-languages=c,c++,fortran
>> Thread model: posix
>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2.8)
>> 
>> I also tried reconfigure llvm from OBJ_DIR, by re-execute step 4 above. But, it did not work. 
>> 
>> I used 'tree' in the SingleSource directory:
>> [qali at qali SingleSource]$ tree
>> .
>> |-- Makefile
>> |-- Makefile.singlesrc
>> `-- UnitTests
>>     |-- Makefile
>>     `-- Vector
>>         |-- Makefile
>>         `-- SSE
>>             |-- Makefile
>>             `-- Output
>>                 `-- sse.expandfft.ll
>> 
>> 4 directories, 6 files
>> 
>> 
>> I need help to build the test suits .
>> 
>> 
>> 
>> -- 
>> Best regards,
>> 
>> Li Qingan
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> 
> 
> -- 
> Best regards,
> 
> Li Qingan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110113/4c874b43/attachment.html 

From ww345ww at gmail.com  Thu Jan 13 20:22:11 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Fri, 14 Jan 2011 10:22:11 +0800
Subject: [LLVMdev] About test suits Cont
Message-ID: <AANLkTi=w7pZPHL5SeyowJvLPzkD_0w=tEfSwXFVyRH0w@mail.gmail.com>

[qali at qali test-suite]$ make VERBOSE=1
if [ ! -f SingleSource/Makefile ]; \
then \
/home/qali/Src/llvm-2.8/autoconf/mkinstalldirs SingleSource; \
cp /home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/Makefile
SingleSource/Makefile; \
fi; \
make -C SingleSource all
make[1]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource'
if [ ! -f UnitTests/Makefile ]; \
then \
/home/qali/Src/llvm-2.8/autoconf/mkinstalldirs UnitTests; \
cp
/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Makefile
UnitTests/Makefile; \
fi; \
make -C UnitTests all -w
make[2]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
for dir in  Vector  SignlessTypes Threads; do \
if [ ! -f $dir/Makefile ]; \
then \
/home/qali/Src/llvm-2.8/autoconf/mkinstalldirs $dir; \
cp
/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/$dir/Makefile
$dir/Makefile; \
fi; \
(make -C $dir all -w) || exit 1; \
done
make[3]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
for dir in  SSE; do \
if [ ! -f $dir/Makefile ]; \
then \
/home/qali/Src/llvm-2.8/autoconf/mkinstalldirs $dir; \
cp
/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/$dir/Makefile
$dir/Makefile; \
fi; \
(make -C $dir all -w) || exit 1; \
done
make[4]: Entering directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
/home/qali/Src/llvm-2.8/autoconf/mkinstalldirs Output > /dev/null
/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-gcc
-I/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE
-I/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE
-I/home/qali/build/llvm-2.8-rev/include
-I/home/qali/Src/llvm-2.8/projects/test-suite/include -I../../../../include
-I/home/qali/Src/llvm-2.8/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
-DNDEBUG  -O3  -msse2 -m64 -fomit-frame-pointer -S
/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c
-o Output/sse.expandfft.ll
/home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as
Output/sse.expandfft.ll -o Output/sse.expandfft.bc
/home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as:
Output/sse.expandfft.ll:1:2: error: expected top-level entity
.file
"/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c"
^
make[4]: *** [Output/sse.expandfft.bc] Error 1
make[4]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
make[3]: *** [all] Error 1
make[3]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector'
make[2]: *** [all] Error 1
make[2]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests'
make[1]: *** [UnitTests/.makeall] Error 2
make[1]: Leaving directory
`/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource'
make: *** [SingleSource/.makeall] Error 2

-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/725eaab4/attachment.html 

From echristo at apple.com  Thu Jan 13 20:44:40 2011
From: echristo at apple.com (Eric Christopher)
Date: Thu, 13 Jan 2011 18:44:40 -0800
Subject: [LLVMdev] About test suits Cont
In-Reply-To: <AANLkTi=w7pZPHL5SeyowJvLPzkD_0w=tEfSwXFVyRH0w@mail.gmail.com>
References: <AANLkTi=w7pZPHL5SeyowJvLPzkD_0w=tEfSwXFVyRH0w@mail.gmail.com>
Message-ID: <F5E04DA8-7D30-4666-9187-AEA0BDF5D4BB@apple.com>


On Jan 13, 2011, at 6:22 PM, Qingan Li wrote:

> make[4]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
> /home/qali/Src/llvm-2.8/autoconf/mkinstalldirs Output > /dev/null
> /home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-gcc -I/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE -I/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE -I/home/qali/build/llvm-2.8-rev/include -I/home/qali/Src/llvm-2.8/projects/test-suite/include -I../../../../include -I/home/qali/Src/llvm-2.8/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -DNDEBUG  -O3  -msse2 -m64 -fomit-frame-pointer -S /home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c -o Output/sse.expandfft.ll 
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as Output/sse.expandfft.ll -o Output/sse.expandfft.bc
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as: Output/sse.expandfft.ll:1:2: error: expected top-level entity
> 	.file	"/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c"

Something is odd here. Can you do a grep in your top-level build directory for LLVMCC_EMITIR_FLAG?

It's obviously blank and it shouldn't be. You should take a look at the configure output and see what happened.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110113/c08798b1/attachment-0001.html 

From leafy7382 at gmail.com  Thu Jan 13 21:01:42 2011
From: leafy7382 at gmail.com (Chia-Wei Yeh)
Date: Fri, 14 Jan 2011 11:01:42 +0800
Subject: [LLVMdev] Building Boost library failed with Clang 2.9
Message-ID: <AANLkTim_zUPp8ZoY_X9NBJi6ZMRnQnqMRbnw4iw9+arP@mail.gmail.com>

I tried building boost 1.45 release with clang 2.9 following instructions
on

http://blog.llvm.org/2010/05/clang-builds-boost.html

but got the following result:

$ clang++ --version
clang version 2.9 (trunk 123420)
Target: x86_64-apple-darwin10
Thread model: posix

$ ./bjam toolset=clang

Building the Boost C++ Libraries.


Performing configuration checks

    - has_icu builds           : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam
    - ../config//has_gcc_visibility builds : yes
    - ../config//has_long_double_support builds : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.

Component configuration:

    - date_time                : building
    - filesystem               : building
    - graph                    : building
    - graph_parallel           : building
    - iostreams                : building
    - math                     : building
    - mpi                      : building
    - program_options          : building
    - python                   : building
    - random                   : building
    - regex                    : building
    - serialization            : building
    - signals                  : building
    - system                   : building
    - test                     : building
    - thread                   : building
    - wave                     : building

...patience...
...patience...
...patience...
...found 7481 targets...
...updating 6 targets...
clang-darwin.compile.c++
bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/threading-multi/mapped_file.o
In file included from libs/iostreams/src/mapped_file.cpp:18:
./boost/iostreams/device/mapped_file.hpp:416:5: error: call to member
function 'open' is ambiguous
    open(p);
    ^~~~
./boost/iostreams/device/mapped_file.hpp:395:26: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file_source::open(const basic_mapped_file_params<Path>& p)
                         ^
./boost/iostreams/device/mapped_file.hpp:410:26: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
void mapped_file_source::open(
                         ^
./boost/iostreams/device/mapped_file.hpp:450:5: error: call to member
function 'open' is ambiguous
    open(p);
    ^~~~
./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
    void open( const Path& path,
         ^
./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file::open(const basic_mapped_file_params<Path>& p)
                  ^
./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
template not viable: requires at least 2 arguments, but 1 was provided
void mapped_file::open(
                  ^
./boost/iostreams/device/mapped_file.hpp:462:5: error: call to member
function 'open' is ambiguous
    open(p);
    ^~~~
./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
    void open( const Path& path,
         ^
./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file::open(const basic_mapped_file_params<Path>& p)
                  ^
./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
template not viable: requires at least 2 arguments, but 1 was provided
void mapped_file::open(
                  ^
./boost/iostreams/device/mapped_file.hpp:492:18: error: call to member
function 'open' is ambiguous
    mapped_file::open(params);
    ~~~~~~~~~~~~~^~~~
./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
    void open( const Path& path,
         ^
./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file::open(const basic_mapped_file_params<Path>& p)
                  ^
./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
template not viable: requires at least 2 arguments, but 1 was provided
void mapped_file::open(
                  ^
./boost/iostreams/device/mapped_file.hpp:504:5: error: call to member
function 'open' is ambiguous
    open(p);
    ^~~~
./boost/iostreams/device/mapped_file.hpp:481:24: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file_sink::open(const basic_mapped_file_params<Path>& p)
                       ^
./boost/iostreams/device/mapped_file.hpp:496:24: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
void mapped_file_sink::open(
                       ^
5 errors generated.

    "clang++" -x c++ -O3 -O3 -finline-functions -Wno-inline -Wall
-DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1
-DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o
"bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/threading-multi/mapped_file.o"
"libs/iostreams/src/mapped_file.cpp"

...failed clang-darwin.compile.c++
bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/threading-multi/mapped_file.o...
...skipped <pstage/lib>libboost_iostreams.dylib for lack of
<pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/threading-multi>mapped_file.o...
clang-darwin.compile.c++
bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi/mapped_file.o
In file included from libs/iostreams/src/mapped_file.cpp:18:
./boost/iostreams/device/mapped_file.hpp:416:5: error: call to member
function 'open' is ambiguous
    open(p);
    ^~~~
./boost/iostreams/device/mapped_file.hpp:395:26: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file_source::open(const basic_mapped_file_params<Path>& p)
                         ^
./boost/iostreams/device/mapped_file.hpp:410:26: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
void mapped_file_source::open(
                         ^
./boost/iostreams/device/mapped_file.hpp:450:5: error: call to member
function 'open' is ambiguous
    open(p);
    ^~~~
./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
    void open( const Path& path,
         ^
./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file::open(const basic_mapped_file_params<Path>& p)
                  ^
./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
template not viable: requires at least 2 arguments, but 1 was provided
void mapped_file::open(
                  ^
./boost/iostreams/device/mapped_file.hpp:462:5: error: call to member
function 'open' is ambiguous
    open(p);
    ^~~~
./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
    void open( const Path& path,
         ^
./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file::open(const basic_mapped_file_params<Path>& p)
                  ^
./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
template not viable: requires at least 2 arguments, but 1 was provided
void mapped_file::open(
                  ^
./boost/iostreams/device/mapped_file.hpp:492:18: error: call to member
function 'open' is ambiguous
    mapped_file::open(params);
    ~~~~~~~~~~~~~^~~~
./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
    void open( const Path& path,
         ^
./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file::open(const basic_mapped_file_params<Path>& p)
                  ^
./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
template not viable: requires at least 2 arguments, but 1 was provided
void mapped_file::open(
                  ^
./boost/iostreams/device/mapped_file.hpp:504:5: error: call to member
function 'open' is ambiguous
    open(p);
    ^~~~
./boost/iostreams/device/mapped_file.hpp:481:24: note: candidate function
[with Path = boost::iostreams::detail::path]
void mapped_file_sink::open(const basic_mapped_file_params<Path>& p)
                       ^
./boost/iostreams/device/mapped_file.hpp:496:24: note: candidate function
[with Path =
boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
void mapped_file_sink::open(
                       ^
5 errors generated.

    "clang++" -x c++ -O3 -O3 -finline-functions -Wno-inline -Wall
-DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o
"bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi/mapped_file.o"
"libs/iostreams/src/mapped_file.cpp"

...failed clang-darwin.compile.c++
bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi/mapped_file.o...
...skipped
<pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>libboost_iostreams.a(clean)
for lack of
<pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>mapped_file.o...
...skipped
<pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>libboost_iostreams.a
for lack of
<pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>mapped_file.o...
...skipped <pstage/lib>libboost_iostreams.a for lack of
<pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>libboost_iostreams.a...
...failed updating 2 targets...
...skipped 4 targets...

Am I missing something here?

Cheers,

Chia-Wei


-- 
"If it looks like a duck, walks like a duck, and quacks like a duck, then to
the end user it's a duck, and end users have made it pretty clear they want
a duck; whether the duck drinks hot chocolate or coffee is irrelevant."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/620d238a/attachment.html 

From admin at thefireflyproject.us  Thu Jan 13 21:12:51 2011
From: admin at thefireflyproject.us (Bryce Lelbach)
Date: Thu, 13 Jan 2011 22:12:51 -0500
Subject: [LLVMdev] Building Boost library failed with Clang 2.9
In-Reply-To: <AANLkTim_zUPp8ZoY_X9NBJi6ZMRnQnqMRbnw4iw9+arP@mail.gmail.com>
References: <AANLkTim_zUPp8ZoY_X9NBJi6ZMRnQnqMRbnw4iw9+arP@mail.gmail.com>
Message-ID: <20110113221251.0a7a646c@Pegasus>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clang has a few outstanding regressions with Boost. On Linux it's a chore, on 
darwin, I'd advise using prebuilt binaries.

On Fri, 14 Jan 2011 11:01:42 +0800
Chia-Wei Yeh <leafy7382 at gmail.com> wrote:

> I tried building boost 1.45 release with clang 2.9 following instructions
> on
> 
> http://blog.llvm.org/2010/05/clang-builds-boost.html
> 
> but got the following result:
> 
> $ clang++ --version
> clang version 2.9 (trunk 123420)
> Target: x86_64-apple-darwin10
> Thread model: posix
> 
> $ ./bjam toolset=clang
> 
> Building the Boost C++ Libraries.
> 
> 
> Performing configuration checks
> 
>     - has_icu builds           : no
> warning: Graph library does not contain MPI-based parallel components.
> note: to enable them, add "using mpi ;" to your user-config.jam
>     - ../config//has_gcc_visibility builds : yes
>     - ../config//has_long_double_support builds : yes
> warning: skipping optional Message Passing Interface (MPI) library.
> note: to enable MPI support, add "using mpi ;" to user-config.jam.
> note: to suppress this message, pass "--without-mpi" to bjam.
> note: otherwise, you can safely ignore this message.
> 
> Component configuration:
> 
>     - date_time                : building
>     - filesystem               : building
>     - graph                    : building
>     - graph_parallel           : building
>     - iostreams                : building
>     - math                     : building
>     - mpi                      : building
>     - program_options          : building
>     - python                   : building
>     - random                   : building
>     - regex                    : building
>     - serialization            : building
>     - signals                  : building
>     - system                   : building
>     - test                     : building
>     - thread                   : building
>     - wave                     : building
> 
> ...patience...
> ...patience...
> ...patience...
> ...found 7481 targets...
> ...updating 6 targets...
> clang-darwin.compile.c++
> bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/threading-multi/mapped_file.o
> In file included from libs/iostreams/src/mapped_file.cpp:18:
> ./boost/iostreams/device/mapped_file.hpp:416:5: error: call to member
> function 'open' is ambiguous
>     open(p);
>     ^~~~
> ./boost/iostreams/device/mapped_file.hpp:395:26: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file_source::open(const basic_mapped_file_params<Path>& p)
>                          ^
> ./boost/iostreams/device/mapped_file.hpp:410:26: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
> void mapped_file_source::open(
>                          ^
> ./boost/iostreams/device/mapped_file.hpp:450:5: error: call to member
> function 'open' is ambiguous
>     open(p);
>     ^~~~
> ./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
>     void open( const Path& path,
>          ^
> ./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file::open(const basic_mapped_file_params<Path>& p)
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
> template not viable: requires at least 2 arguments, but 1 was provided
> void mapped_file::open(
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:462:5: error: call to member
> function 'open' is ambiguous
>     open(p);
>     ^~~~
> ./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
>     void open( const Path& path,
>          ^
> ./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file::open(const basic_mapped_file_params<Path>& p)
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
> template not viable: requires at least 2 arguments, but 1 was provided
> void mapped_file::open(
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:492:18: error: call to member
> function 'open' is ambiguous
>     mapped_file::open(params);
>     ~~~~~~~~~~~~~^~~~
> ./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
>     void open( const Path& path,
>          ^
> ./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file::open(const basic_mapped_file_params<Path>& p)
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
> template not viable: requires at least 2 arguments, but 1 was provided
> void mapped_file::open(
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:504:5: error: call to member
> function 'open' is ambiguous
>     open(p);
>     ^~~~
> ./boost/iostreams/device/mapped_file.hpp:481:24: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file_sink::open(const basic_mapped_file_params<Path>& p)
>                        ^
> ./boost/iostreams/device/mapped_file.hpp:496:24: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
> void mapped_file_sink::open(
>                        ^
> 5 errors generated.
> 
>     "clang++" -x c++ -O3 -O3 -finline-functions -Wno-inline -Wall
> -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1
> -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o
> "bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/threading-multi/mapped_file.o"
> "libs/iostreams/src/mapped_file.cpp"
> 
> ...failed clang-darwin.compile.c++
> bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/threading-multi/mapped_file.o...
> ...skipped <pstage/lib>libboost_iostreams.dylib for lack of
> <pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/threading-multi>mapped_file.o...
> clang-darwin.compile.c++
> bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi/mapped_file.o
> In file included from libs/iostreams/src/mapped_file.cpp:18:
> ./boost/iostreams/device/mapped_file.hpp:416:5: error: call to member
> function 'open' is ambiguous
>     open(p);
>     ^~~~
> ./boost/iostreams/device/mapped_file.hpp:395:26: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file_source::open(const basic_mapped_file_params<Path>& p)
>                          ^
> ./boost/iostreams/device/mapped_file.hpp:410:26: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
> void mapped_file_source::open(
>                          ^
> ./boost/iostreams/device/mapped_file.hpp:450:5: error: call to member
> function 'open' is ambiguous
>     open(p);
>     ^~~~
> ./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
>     void open( const Path& path,
>          ^
> ./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file::open(const basic_mapped_file_params<Path>& p)
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
> template not viable: requires at least 2 arguments, but 1 was provided
> void mapped_file::open(
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:462:5: error: call to member
> function 'open' is ambiguous
>     open(p);
>     ^~~~
> ./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
>     void open( const Path& path,
>          ^
> ./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file::open(const basic_mapped_file_params<Path>& p)
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
> template not viable: requires at least 2 arguments, but 1 was provided
> void mapped_file::open(
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:492:18: error: call to member
> function 'open' is ambiguous
>     mapped_file::open(params);
>     ~~~~~~~~~~~~~^~~~
> ./boost/iostreams/device/mapped_file.hpp:289:10: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
>     void open( const Path& path,
>          ^
> ./boost/iostreams/device/mapped_file.hpp:438:19: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file::open(const basic_mapped_file_params<Path>& p)
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:442:19: note: candidate function
> template not viable: requires at least 2 arguments, but 1 was provided
> void mapped_file::open(
>                   ^
> ./boost/iostreams/device/mapped_file.hpp:504:5: error: call to member
> function 'open' is ambiguous
>     open(p);
>     ^~~~
> ./boost/iostreams/device/mapped_file.hpp:481:24: note: candidate function
> [with Path = boost::iostreams::detail::path]
> void mapped_file_sink::open(const basic_mapped_file_params<Path>& p)
>                        ^
> ./boost/iostreams/device/mapped_file.hpp:496:24: note: candidate function
> [with Path =
> boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>]
> void mapped_file_sink::open(
>                        ^
> 5 errors generated.
> 
>     "clang++" -x c++ -O3 -O3 -finline-functions -Wno-inline -Wall
> -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o
> "bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi/mapped_file.o"
> "libs/iostreams/src/mapped_file.cpp"
> 
> ...failed clang-darwin.compile.c++
> bin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi/mapped_file.o...
> ...skipped
> <pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>libboost_iostreams.a(clean)
> for lack of
> <pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>mapped_file.o...
> ...skipped
> <pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>libboost_iostreams.a
> for lack of
> <pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>mapped_file.o...
> ...skipped <pstage/lib>libboost_iostreams.a for lack of
> <pbin.v2/libs/iostreams/build/clang-darwin-4.2.1/release/link-static/threading-multi>libboost_iostreams.a...
> ...failed updating 2 targets...
> ...skipped 4 targets...
> 
> Am I missing something here?
> 
> Cheers,
> 
> Chia-Wei
> 
> 



- -- 
Bryce Lelbach aka wash
boost-spirit.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk0vvzMACgkQ9cB/V3/s9EwyzQCgl0FKffB3212YmQ1xf//RYIhs
rdoAoKki1YpUMuIWlck7LsUPNoiXtYU/
=/CTv
-----END PGP SIGNATURE-----


From samuraileumas at yahoo.com  Thu Jan 13 21:45:37 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Thu, 13 Jan 2011 19:45:37 -0800 (PST)
Subject: [LLVMdev] Circular Deps from CMake build using makefile
In-Reply-To: <87d3o0e7vv.fsf@wanadoo.es>
References: <820891.76867.qm@web62006.mail.re1.yahoo.com>
	<87d3o0e7vv.fsf@wanadoo.es>
Message-ID: <835266.14025.qm@web62001.mail.re1.yahoo.com>

Hello ?scar,

The single-threaded build failed the same place as the double threaded build 
failed which is the same place I just indicated in my previous post.  The 
../llvm/configure script version failed with OCaml building with about 600 
assembler errors since I built it in AMD64 mode.  (Oops.)  Should I disable 
OCaml from the configure script and try again?

Assembler error, input left in file 
/var/folders/5x/5xY2twDzGEKM1pioemi4uE+++TM/-Tmp-/camlasma657d2.s
make[3]: *** 
[/Users/samuraicrow/Documents/workspace/trunk-build2/bindings/ocaml/llvm/Debug+Asserts/llvm.cmx]
 Error 2
make[2]: *** [all] Error 1
make[1]: *** [ocaml/.makeall] Error 2

Thanks for helping,

--Sam


----- Original Message ----
> From: ?scar Fuentes <ofv at wanadoo.es>
> To: Samuel Crow <samuraileumas at yahoo.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Thu, January 13, 2011 4:49:56 PM
> Subject: Re: Circular Deps from CMake build using makefile
> 
> Samuel Crow <samuraileumas at yahoo.com>  writes:
> 
> > [ 73%] Regenerating 
> >  
>/Users/samuraicrow/Documents/workspace/llvm-trunk-build/tools/llvm-config/LibDeps.txt.tmp
>
> >
> >  [ 73%] Updating 
> >  
>/Users/samuraicrow/Documents/workspace/llvm-trunk-build/tools/llvm-config/LibDeps.txt
>
> >   if necessary...
> > [ 73%] Checking for cyclic dependencies between LLVM  libraries.
> > find-cycles.pl: Circular dependency between *.a  files:
> > find-cycles.pl:   libLLVMAsmPrinter.a  libLLVMXCoreAsmPrinter.a
> 
> Hmmm...
> 
> > find-cycles.pl: Circular  dependency between *.a files:
> > find-cycles.pl:   libLLVMSupport.a  libLLVMSystem.a
> 
> This one is very odd.
> 
> > make[2]: ***  [tools/llvm-config/FinalLibDeps.txt] Error 2
> > make[1]: ***  [tools/llvm-config/CMakeFiles/llvm-config.target.dir/all] Error 
>2
> > make:  *** [all] Error 2
> >
> > That is the error I get when building with  make -j2 on my Mac Mini.  (It is 
>a 
>
> > Core 2 Duo with 2 GB of  RAM.)
> 
> Cannot reproduce on Linux.
> 
> Please try this:
> 
> make  clean
> make -j2
> 
> If that fails,
> 
> make clean
> make
> 
> > I  have been able to build LLVM with XCode projects created with CMake 2.8-3 

> > before but when building Clang also, the build scripts take up too much  RAM. 
>
> >  (About 2.6 GB virtual memory not counting the usage by GCC  to execute the 
> > build.)  I thought I'd try building with Make  instead to alleviate some 
>memory 
>
> > problems.  Is there something  wrong with the bundled version of PERL that 
>comes 
>
> > with MacOSX  10.6.6?  Will building from the configure script fix matters at  
>all?
> 
> If the above fails, it would be helpful to know if  configure&&make works
> (on a new build directory).
> 


      


From dron at osrc.info  Thu Jan 13 15:33:30 2011
From: dron at osrc.info (Andrey Valyaev)
Date: Fri, 14 Jan 2011 00:33:30 +0300
Subject: [LLVMdev] Designated Initializers work in clang++
Message-ID: <201101140033.30989.dron@osrc.info>

di.cpp:
------
#include <iostream>
using namespace std;

struct foo {
	int a;
	int b;
};

int main(int, char **)
{
	const foo f = { .a = 10, .b = 11 };
	cout << f.a << ' ' << f.b << endl;
	return 0;
}
-----

$ clang++ -Wall -Wextra -Weffc++ -o di di.cpp 
$ ./di
10 11

It is a standard C99!
Or am I wrong?

$ clang++ --version
clang version 2.8 (branches/release_28)
Target: i386-pc-linux-gnu
Thread model: posix

-- 
	http://mdf-i.blogspot.com
	Andrey Valyaev

From ww345ww at gmail.com  Thu Jan 13 21:35:13 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Fri, 14 Jan 2011 11:35:13 +0800
Subject: [LLVMdev] About test suits Cont
In-Reply-To: <F5E04DA8-7D30-4666-9187-AEA0BDF5D4BB@apple.com>
References: <AANLkTi=w7pZPHL5SeyowJvLPzkD_0w=tEfSwXFVyRH0w@mail.gmail.com>
	<F5E04DA8-7D30-4666-9187-AEA0BDF5D4BB@apple.com>
Message-ID: <AANLkTinEMBywoT7om95Ur0PVrwV3+Agi9h4aLCH-aQtn@mail.gmail.com>

[qali at qali llvm-2.8-rev]$ find . -exec grep -n "LLVMCC_EMITIR_FLAG" ./ {} \;
./projects/test-suite/Makefile.tests:47: -$(LCC) $(CPPFLAGS) $(CFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:51: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:55: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:59: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:63: -$(LCC) $(CPPFLAGS) $(CFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:67: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)

I attached the config.status, config.log file and the output file to console
named cfg.log in the email. There are errors in config.log, but I need your
help for clarifying it.


2011/1/14 Eric Christopher <echristo at apple.com>

>
> On Jan 13, 2011, at 6:22 PM, Qingan Li wrote:
>
> make[4]: Entering directory
> `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
> /home/qali/Src/llvm-2.8/autoconf/mkinstalldirs Output > /dev/null
> /home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-gcc
> -I/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE
> -I/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE
> -I/home/qali/build/llvm-2.8-rev/include
> -I/home/qali/Src/llvm-2.8/projects/test-suite/include -I../../../../include
> -I/home/qali/Src/llvm-2.8/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
> -DNDEBUG  -O3  -msse2 -m64 -fomit-frame-pointer -S
> /home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c
> -o Output/sse.expandfft.ll
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as
> Output/sse.expandfft.ll -o Output/sse.expandfft.bc
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as:
> Output/sse.expandfft.ll:1:2: error: expected top-level entity
> .file
> "/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c"
>
>
> Something is odd here. Can you do a grep in your top-level build directory
> for LLVMCC_EMITIR_FLAG?
>
> It's obviously blank and it shouldn't be. You should take a look at the
> configure output and see what happened.
>
> -eric
>



-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/dceef196/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: text/x-log
Size: 183151 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/dceef196/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.status
Type: application/octet-stream
Size: 47904 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/dceef196/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfg.log
Type: text/x-log
Size: 22775 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/dceef196/attachment-0003.bin 

From clattner at apple.com  Thu Jan 13 23:26:42 2011
From: clattner at apple.com (Chris Lattner)
Date: Thu, 13 Jan 2011 21:26:42 -0800
Subject: [LLVMdev] Designated Initializers work in clang++
In-Reply-To: <201101140033.30989.dron@osrc.info>
References: <201101140033.30989.dron@osrc.info>
Message-ID: <26BB8FA0-D968-4A6B-B9AE-087200FBD22B@apple.com>


On Jan 13, 2011, at 1:33 PM, Andrey Valyaev wrote:

> di.cpp:
> ------
> #include <iostream>
> using namespace std;
> 
> struct foo {
> 	int a;
> 	int b;
> };
> 
> int main(int, char **)
> {
> 	const foo f = { .a = 10, .b = 11 };
> 	cout << f.a << ' ' << f.b << endl;
> 	return 0;
> }
> -----
> 
> $ clang++ -Wall -Wextra -Weffc++ -o di di.cpp 
> $ ./di
> 10 11
> 
> It is a standard C99!
> Or am I wrong?

Hi Andrey,

I don't understand what you're asking here.  It might be best to post to cfe-dev to get clang-specific answer.

-Chris

> 
> $ clang++ --version
> clang version 2.8 (branches/release_28)
> Target: i386-pc-linux-gnu
> Thread model: posix
> 
> -- 
> 	http://mdf-i.blogspot.com
> 	Andrey Valyaev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From ofv at wanadoo.es  Fri Jan 14 07:27:18 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Fri, 14 Jan 2011 14:27:18 +0100
Subject: [LLVMdev] Circular Deps from CMake build using makefile
In-Reply-To: <835266.14025.qm@web62001.mail.re1.yahoo.com> (Samuel Crow's
	message of "Thu, 13 Jan 2011 19:45:37 -0800 (PST)")
References: <820891.76867.qm@web62006.mail.re1.yahoo.com>
	<87d3o0e7vv.fsf@wanadoo.es>
	<835266.14025.qm@web62001.mail.re1.yahoo.com>
Message-ID: <874o9behu1.fsf@wanadoo.es>

Samuel Crow <samuraileumas at yahoo.com> writes:

> The single-threaded build failed the same place as the double threaded build 
> failed which is the same place I just indicated in my previous post.  The 
> ../llvm/configure script version failed with OCaml building with about 600 
> assembler errors since I built it in AMD64 mode.  (Oops.)  Should I disable 
> OCaml from the configure script and try again?

Yes, please. (The cmake build ignores the OCaml bindings)

From ofv at wanadoo.es  Fri Jan 14 07:35:57 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Fri, 14 Jan 2011 14:35:57 +0100
Subject: [LLVMdev] Designated Initializers work in clang++
References: <201101140033.30989.dron@osrc.info>
	<26BB8FA0-D968-4A6B-B9AE-087200FBD22B@apple.com>
Message-ID: <87vd1rd2v6.fsf@wanadoo.es>

Chris Lattner <clattner at apple.com> writes:

> On Jan 13, 2011, at 1:33 PM, Andrey Valyaev wrote:
>
>> di.cpp:
>> ------
>> #include <iostream>
>> using namespace std;
>> 
>> struct foo {
>> 	int a;
>> 	int b;
>> };
>> 
>> int main(int, char **)
>> {
>> 	const foo f = { .a = 10, .b = 11 };
>> 	cout << f.a << ' ' << f.b << endl;
>> 	return 0;
>> }
>> -----
>> 
>> $ clang++ -Wall -Wextra -Weffc++ -o di di.cpp 
>> $ ./di
>> 10 11
>> 
>> It is a standard C99!
>> Or am I wrong?
>
> Hi Andrey,
>
> I don't understand what you're asking here.  It might be best to post
> to cfe-dev to get clang-specific answer.

I think he is surprised to see clang accepting C99-style struct
initializers on a C++ program.


From jkeenan at cpi-search.com  Fri Jan 14 11:17:30 2011
From: jkeenan at cpi-search.com (John Keenan)
Date: 14 Jan 2011 12:17:30 -0500
Subject: [LLVMdev] Compiler Centric Career Opportunities in finance
Message-ID: <1682845211.1295025450199.JavaMail.cfservice@SL5APP2>


Hi --

 

I'm working with a number of finance companies in New York City and Chicago which are looking to develop languages and platforms in order to process extremely large datasets.  As such, we are looking for people with experience and / or interest in programming language and compiler design -- hence my posting on the LLVM mailing list.

 

Goldman Sachs most famously developed Slang and SecDB more than 20 years ago -- Slang is essentially a scripting language based on Scheme (functional) which has added a number of object oriented features.  SecDB is columnar database similar to APL / K / Q.  http://bit.ly/eVJpQY

 

Obviously there have been some changes in computer science in the last 20 years!  As such, many of these groups are taking advantage of new(er) technologies including Map Reduce / Pig / MongoDB / Hadoop / Python / Haskell / OCaml / C++.

 

In order to best utilize these technologies and create new platforms, we are looking for people who have strong experience with compiler theory ? especially folks who are not tied to one framework.  We are also looking for folks with e
experience building compilers for functional, logical or dataflow languages.  Experience with LLVM or gnu is essential.  



 

I am recruiting for not just Goldman Sachs, but several other banks and hedge funds that are seeking to imitate Goldman's approach.  These clients are located both in Chicago and New York City.  The appeal of working with these groups is the opportunity to work in a research and development environment with extremely technical developers and excellent compensation.  You would not be anywhere close to screaming traders on the trading floor :)




 

If anyone would be interested in speaking in more detail with me -- feel free to reach out to me at my contact details below.  Also, feel free to forward my contact details to anyone who might be interested.



 

Thanks for letting me post this here. 



 

-------------------------------------
John Keenan
Technical Recruiter
Continuity Partners Inc.
245 5th Avenue 22nd Floor
New York, NY 10016
tel: 212-213-2220 x103
cell: 646-246-7070

www.cpi-search.com

http://www.linkedin.com/in/johnkeenan 
-------------------------------------



View our current job openings! 

http://www.cpi-search.com/openings.php

Check us out on Twitter!

www.twitter.com/ContinuityJobs



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/1b06b360/attachment.html 

From clattner at apple.com  Fri Jan 14 12:24:52 2011
From: clattner at apple.com (Chris Lattner)
Date: Fri, 14 Jan 2011 10:24:52 -0800
Subject: [LLVMdev] Compiler Centric Career Opportunities in finance
In-Reply-To: <1682845211.1295025450199.JavaMail.cfservice@SL5APP2>
References: <1682845211.1295025450199.JavaMail.cfservice@SL5APP2>
Message-ID: <AF02D098-9886-47D2-9480-A4BA9882D8C6@apple.com>


On Jan 14, 2011, at 9:17 AM, John Keenan wrote:

> Hi --
>  
> I'm working with a number of finance companies in New York City and Chicago which are looking to develop languages and platforms in order to process extremely large datasets.  As such, we are looking for people with experience and / or interest in programming language and compiler design -- hence my posting on the LLVM mailing list.

Hi John,

FYI, general compiler job postings are off-topic for this list.  However, if the job is specifically LLVM related, it is welcome, just make this clear in the post.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/9fc71511/attachment.html 

From czhao at eecg.toronto.edu  Fri Jan 14 10:06:27 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Fri, 14 Jan 2011 11:06:27 -0500
Subject: [LLVMdev] examine dominating relationships between basic blocks
Message-ID: <4D307483.70404@eecg.toronto.edu>

I am building code which needs to examine dominating relationships 
between Basic Blocks.
I searched the Programming Guide 
(http://llvm.org/docs/ProgrammersManual.html#common), it mentioned 
briefly that such details will be covered in the future.

So, I am tuning to the list and ask.

Say, I have BasicBlock * a, *b, and need to know whether a DOM b, (a 
DOMi b, a DOMp b, a PostDOM b), etc.
How can these be expressed?

Similar things,
how can I find all BasicBlocks that a dominates, (DOM, DOMp, PostDOM, ...)

Browsing the source code, I seem to find things like DominatorFrontier, 
DominatorTree, etc.
But I have no clue how they can be used.

Can somebody leverage some more details please.


Thank you

Chuck


From clattner at apple.com  Fri Jan 14 13:14:09 2011
From: clattner at apple.com (Chris Lattner)
Date: Fri, 14 Jan 2011 11:14:09 -0800
Subject: [LLVMdev] examine dominating relationships between basic blocks
In-Reply-To: <4D307483.70404@eecg.toronto.edu>
References: <4D307483.70404@eecg.toronto.edu>
Message-ID: <7E40BCB2-D2E4-41A2-AF3E-51F2A079D4ED@apple.com>


On Jan 14, 2011, at 8:06 AM, Chuck Zhao wrote:

> I am building code which needs to examine dominating relationships 
> between Basic Blocks.
> I searched the Programming Guide 
> (http://llvm.org/docs/ProgrammersManual.html#common), it mentioned 
> briefly that such details will be covered in the future.
> 
> So, I am tuning to the list and ask.
> 
> Say, I have BasicBlock * a, *b, and need to know whether a DOM b, (a 
> DOMi b, a DOMp b, a PostDOM b), etc.
> How can these be expressed?
> 
> Similar things,
> how can I find all BasicBlocks that a dominates, (DOM, DOMp, PostDOM, ...)
> 
> Browsing the source code, I seem to find things like DominatorFrontier, 
> DominatorTree, etc.
> But I have no clue how they can be used.

Hi Chuck,

You can get this by requiring the DominatorTree pass from your pass.  There are lots of examples of this in lib/Transforms/Scalar for example,

-Chris

From samuraileumas at yahoo.com  Fri Jan 14 14:33:21 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Fri, 14 Jan 2011 12:33:21 -0800 (PST)
Subject: [LLVMdev] Circular Deps from CMake build using makefile
In-Reply-To: <874o9behu1.fsf@wanadoo.es>
References: <820891.76867.qm@web62006.mail.re1.yahoo.com>
	<87d3o0e7vv.fsf@wanadoo.es>
	<835266.14025.qm@web62001.mail.re1.yahoo.com>
	<874o9behu1.fsf@wanadoo.es>
Message-ID: <19957.25947.qm@web62008.mail.re1.yahoo.com>

Hello ?scar,

This time the autotools version of LLVM trunk build with Clang trunk compiled in 
Debug+Asserts mode without complaint with --enable-bindings=none.  I suspect 
this makes something fishy looking with the CMake build.  Do you need logfiles 
from configure?

Thanks again,

--Sam


----- Original Message ----
> From: ?scar Fuentes <ofv at wanadoo.es>
> To: Samuel Crow <samuraileumas at yahoo.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Fri, January 14, 2011 7:27:18 AM
> Subject: Re: Circular Deps from CMake build using makefile
> 
> Samuel Crow <samuraileumas at yahoo.com>  writes:
> 
> > The single-threaded build failed the same place as the  double threaded build 
>
> > failed which is the same place I just indicated  in my previous post.  The 
> > ../llvm/configure script version failed  with OCaml building with about 600 
> > assembler errors since I built it in  AMD64 mode.  (Oops.)  Should I disable 

> > OCaml from the  configure script and try again?
> 
> Yes, please. (The cmake build ignores the  OCaml bindings)
> 


      


From ronaldoferraz at gmail.com  Fri Jan 14 15:19:47 2011
From: ronaldoferraz at gmail.com (Ronaldo Ferraz)
Date: Fri, 14 Jan 2011 19:19:47 -0200
Subject: [LLVMdev] Building the shared library on Mac OS X
Message-ID: <AANLkTi=KREruRw=2pnRd=ZwzKCLWJbnj554cROVEVsZd@mail.gmail.com>

Hi,

I'm new to LLVM and have been trying to build the shared library with
mixed success.

Using ./configure  --enable-shared compiles cleanly but as soon as I
try to load the library--for example, in Ruby using FFI--I get the
following error:

dyld: loaded: /Users/<user>/llvm/2.8/lib/libLLVM-2.8.dylib
dyld: lazy symbol binding failed: Symbol not
found:__ZN4llvm2cl6Option11addArgumentEv
  Referenced from: /Users/<user>/llvm/2.8/lib/libLLVM-2.8.dylib
  Expected in: flat namespace

dyld: Symbol not found: __ZN4llvm2cl6Option11addArgumentEv
  Referenced from: /Users/<user>/llvm/2.8/lib/libLLVM-2.8.dylib
  Expected in: flat namespace

Trace/BPT trap

So I applied the following change (after a conversation with a fellow
developer facing the same problems):

diff --git a/Makefile.rules b/Makefile.rules
index 9cff105..44d5b2d 100644
--- a/Makefile.rules
+++ b/Makefile.rules
@@ -497,7 +497,7 @@ ifeq ($(HOST_OS),Darwin)
   # Get "4" out of 10.4 for later pieces in the makefile.
   DARWIN_MAJVERS := $(shell echo $(DARWIN_VERSION)| sed -E
's/10.([0-9]).*/\1/')

-  SharedLinkOptions=-Wl,-flat_namespace -Wl,-undefined,suppress \
+  SharedLinkOptions=-Wl,-undefined,dynamic_lookup \
                     -dynamiclib
   ifneq ($(ARCH),ARM)
     SharedLinkOptions += -mmacosx-version-min=$(DARWIN_VERSION)

The options above use the default two-level namespace on OS X and
change name resolution to run time. The library now compiles cleanly
and loads properly.

Using those options doesn't seem to have any ill effect but I'm
wondering if there's a reason why the previous options were used,
especially since many dynamic libraries for Mac OS X are compiled with
the latter--the former actually seems to be a legacy from pre-10.3
days.

Any thoughts?

Best regards,

R.

From ofv at wanadoo.es  Fri Jan 14 16:39:57 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Fri, 14 Jan 2011 23:39:57 +0100
Subject: [LLVMdev] Circular Deps from CMake build using makefile
In-Reply-To: <19957.25947.qm@web62008.mail.re1.yahoo.com> (Samuel Crow's
	message of "Fri, 14 Jan 2011 12:33:21 -0800 (PST)")
References: <820891.76867.qm@web62006.mail.re1.yahoo.com>
	<87d3o0e7vv.fsf@wanadoo.es>
	<835266.14025.qm@web62001.mail.re1.yahoo.com>
	<874o9behu1.fsf@wanadoo.es>
	<19957.25947.qm@web62008.mail.re1.yahoo.com>
Message-ID: <87aaj3cdoi.fsf@wanadoo.es>

Samuel Crow <samuraileumas at yahoo.com> writes:

> This time the autotools version of LLVM trunk build with Clang trunk compiled in 
> Debug+Asserts mode without complaint with --enable-bindings=none.  I suspect 
> this makes something fishy looking with the CMake build.  Do you need logfiles 
> from configure?

I'm clueless about what's happening there. The cyclic dependency among
LLVMSupport and LLVMSystem makes no sense (the other cyclic dependency
is a different history) Others are using cmake on OS/X and didn't report
any problem. I'll like to help, but can't think of anything that could
be wrong on the cmake build (apart from compiler options: make VERBOSE=1
will show the full command lines and you can compare the invocations or
the compiler and linker for the cmake and the `configure' build.) Sorry.

From ofv at wanadoo.es  Fri Jan 14 18:20:23 2011
From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=)
Date: Sat, 15 Jan 2011 01:20:23 +0100
Subject: [LLVMdev] Circular Deps from CMake build using makefile
In-Reply-To: <460732.65959.qm@web62005.mail.re1.yahoo.com> (Samuel Crow's
	message of "Fri, 14 Jan 2011 15:55:19 -0800 (PST)")
References: <820891.76867.qm@web62006.mail.re1.yahoo.com>
	<87d3o0e7vv.fsf@wanadoo.es>
	<835266.14025.qm@web62001.mail.re1.yahoo.com>
	<874o9behu1.fsf@wanadoo.es>
	<19957.25947.qm@web62008.mail.re1.yahoo.com>
	<87aaj3cdoi.fsf@wanadoo.es>
	<460732.65959.qm@web62005.mail.re1.yahoo.com>
Message-ID: <871v4fc914.fsf@wanadoo.es>

Samuel Crow <samuraileumas at yahoo.com> writes:

> I have attached the logfiles here.

I think you didn't set CMAKE_BUILD_TYPE while configuring the cmake
build. On your build directory, please do:

make clean
cmake   -DCMAKE_BUILD_TYPE=Debug    path/to/your/llvm/source/root
make

If that doesn't work, show the exact command lines you used for invoking
cmake and the `configure' script.

From trevor at galois.com  Fri Jan 14 19:17:30 2011
From: trevor at galois.com (Trevor Elliott)
Date: Fri, 14 Jan 2011 17:17:30 -0800
Subject: [LLVMdev] LLVM GC
Message-ID: <4D30F5AA.1040106@galois.com>

Hi,

I've been implementing a compiler that targets LLVM, and was looking
into using the shadow-stack gc strategy.  Currently, I build the runtime
with clang (using -emit-llvm), and then link that with the LLVM bitcode
output from my compiler using llvm-ld.

This works fine without the gc strategy annotations and use of the
llvm.gcroot intrinsic, but adding them causes some odd behavior: the
resulting bitcode will generate a large stack trace from lli (appended
at the end of this message), and the resulting native assembly,
generated with llc, will never update my llvm_gc_root_chain global.

Interestingly, if I build my runtime with g++, or clang without
-emit-llvm, and link everything together after generating native
assembly from the output of my compiler, it works.  The stack roots get
registered, and the llvm_gc_root_chain global gets updated.

Is linking in the runtime as an LLVM bitcode object something that I
should expect to work, or does it make more sense to build the runtime
for the target, and not try to emit LLVM bitcode programs from my compiler?

Thanks!

--trevor


0  libLLVM-2.8.so  0x0000003cc36eee9f
1  libLLVM-2.8.so  0x0000003cc36ef99a
2  libpthread.so.0 0x0000003cc200f4a0
3  libLLVM-2.8.so  0x0000003cc33360dd
llvm::StructType::StructType(llvm::LLVMContext&, std::vector<llvm::Type
const*, std::allocator<llvm::Type const*> > const&, bool) + 237
4  libLLVM-2.8.so  0x0000003cc3337c95
llvm::StructType::get(llvm::LLVMContext&, std::vector<llvm::Type const*,
std::allocator<llvm::Type const*> > const&, bool) + 533
5  libLLVM-2.8.so  0x0000003cc3242d58
6  libLLVM-2.8.so  0x0000003cc318f09e
7  libLLVM-2.8.so  0x0000003cc3330628
llvm::FPPassManager::runOnFunction(llvm::Function&) + 424
8  libLLVM-2.8.so  0x0000003cc33307cb
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 91
9  libLLVM-2.8.so  0x0000003cc33309bd
llvm::FunctionPassManager::run(llvm::Function&) + 173
10 libLLVM-2.8.so  0x0000003cc33e8647
llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 39
11 libLLVM-2.8.so  0x0000003cc33e8a2f
llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard
const&) + 15
12 libLLVM-2.8.so  0x0000003cc33e8cde
llvm::JIT::getPointerToFunction(llvm::Function*) + 606
13 libLLVM-2.8.so  0x0000003cc33ea253
llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue,
std::allocator<llvm::GenericValue> > const&) + 67
14 libLLVM-2.8.so  0x0000003cc336ad4a
llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
std::vector<std::string, std::allocator<std::string> > const&, char
const* const*) + 1130
15 lli             0x0000000000404cd6 main + 2054
16 libc.so.6       0x0000003cc1c1ec5d __libc_start_main + 253
17 lli             0x0000000000403689
Stack dump:
0.	Program arguments: lli test.bc
1.	Running pass 'Lower Garbage Collection Instructions' on function '@main'
zsh: segmentation fault (core dumped)  ./test

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3612 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/c4bca221/attachment.bin 

From samuraileumas at yahoo.com  Fri Jan 14 19:33:59 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Fri, 14 Jan 2011 17:33:59 -0800 (PST)
Subject: [LLVMdev] Fw:  LLVM GC
In-Reply-To: <4D30F5AA.1040106@galois.com>
References: <4D30F5AA.1040106@galois.com>
Message-ID: <17226.12707.qm@web62004.mail.re1.yahoo.com>

Forgot to CC the list.


----- Forwarded Message ----
> From: Samuel Crow <samuraileumas at yahoo.com>
> To: Trevor Elliott <trevor at galois.com>
> Sent: Fri, January 14, 2011 7:33:15 PM
> Subject: Re: [LLVMdev] LLVM GC
> 
> Hi Trevor,
> 
> Are you linking with LibStdC++ or LibC++?  That is a  requirement for running 
> code that has been compiled from C++ to  bitcode.
> 
> Hope this helps,
> 
> --Sam Crow
> 
> 
> ----- Original  Message ----
> > From: Trevor Elliott <trevor at galois.com>
> > To: llvmdev at cs.uiuc.edu
> > Sent: Fri,  January 14, 2011 7:17:30 PM
> > Subject: [LLVMdev] LLVM GC
> > 
> >  Hi,
> > 
> > I've been implementing a compiler that targets LLVM, and  was  looking
> > into using the shadow-stack gc strategy.   Currently, I build the  runtime
> > with clang (using -emit-llvm), and  then link that with the LLVM  bitcode
> > output from my compiler using  llvm-ld.
> > 
> > This works fine without  the gc strategy  annotations and use of the
> > llvm.gcroot intrinsic, but adding  them  causes some odd behavior: the
> > resulting bitcode will generate a  large  stack trace from lli (appended
> > at the end of this message),  and the resulting  native assembly,
> > generated with llc, will never  update my llvm_gc_root_chain  global.
> > 
> > Interestingly, if I  build my runtime with g++, or clang  without
> > -emit-llvm, and link  everything together after generating  native
> > assembly from the  output of my compiler, it works.  The stack  roots get
> >  registered, and the llvm_gc_root_chain global gets  updated.
> > 
> > Is linking in the runtime as an LLVM bitcode object something   that I
> > should expect to work, or does it make more sense to build  the  runtime
> > for the target, and not try to emit LLVM bitcode  programs from my  
compiler?
> > 
> > Thanks!
> > 
> >  --trevor
> > 
> > 
> > 0  libLLVM-2.8.so    0x0000003cc36eee9f
> > 1  libLLVM-2.8.so   0x0000003cc36ef99a
> > 2  libpthread.so.0  0x0000003cc200f4a0
> >  3  libLLVM-2.8.so   0x0000003cc33360dd
> >  llvm::StructType::StructType(llvm::LLVMContext&,   std::vector<llvm::Type
> > const*, std::allocator<llvm::Type  const*>  > const&, bool) + 237
> > 4   libLLVM-2.8.so   0x0000003cc3337c95
> >  llvm::StructType::get(llvm::LLVMContext&,  std::vector<llvm::Type  const*,
> > std::allocator<llvm::Type const*>  > const&,  bool) + 533
> > 5  libLLVM-2.8.so   0x0000003cc3242d58
> >  6  libLLVM-2.8.so  0x0000003cc318f09e
> > 7    libLLVM-2.8.so   0x0000003cc3330628
> >  llvm::FPPassManager::runOnFunction(llvm::Function&) +  424
> >  8  libLLVM-2.8.so   0x0000003cc33307cb
> >  llvm::FunctionPassManagerImpl::run(llvm::Function&) +  91
> >  9  libLLVM-2.8.so   0x0000003cc33309bd
> >  llvm::FunctionPassManager::run(llvm::Function&) +  173
> > 10  libLLVM-2.8.so   0x0000003cc33e8647
> >  llvm::JIT::jitTheFunction(llvm::Function*,  llvm::MutexGuard const&) +  39
> > 11 libLLVM-2.8.so   0x0000003cc33e8a2f
> >  llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*,   llvm::MutexGuard
> > const&) + 15
> > 12 libLLVM-2.8.so    0x0000003cc33e8cde
> > llvm::JIT::getPointerToFunction(llvm::Function*)  +  606
> > 13 libLLVM-2.8.so   0x0000003cc33ea253
> >  llvm::JIT::runFunction(llvm::Function*,   std::vector<llvm::GenericValue,
> >  std::allocator<llvm::GenericValue>  > const&) + 67
> > 14  libLLVM-2.8.so   0x0000003cc336ad4a
> >  llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
> >  std::vector<std::string,  std::allocator<std::string> >  const&, char
> > const* const*) +  1130
> > 15 lli              0x0000000000404cd6 main  + 2054
> > 16 libc.so.6         0x0000003cc1c1ec5d __libc_start_main + 253
> > 17 lli               0x0000000000403689
> > Stack dump:
> >  0.     Program arguments: lli test.bc
> > 1.    Running  pass 'Lower  Garbage Collection Instructions' on function 
> '@main'
> > zsh: segmentation fault  (core dumped)   ./test
> > 
> > 
> 
> 
>       
> 


      

From samuraileumas at yahoo.com  Fri Jan 14 20:07:54 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Fri, 14 Jan 2011 18:07:54 -0800 (PST)
Subject: [LLVMdev] Circular Deps from CMake build using makefile
In-Reply-To: <871v4fc914.fsf@wanadoo.es>
References: <820891.76867.qm@web62006.mail.re1.yahoo.com>
	<87d3o0e7vv.fsf@wanadoo.es>
	<835266.14025.qm@web62001.mail.re1.yahoo.com>
	<874o9behu1.fsf@wanadoo.es>
	<19957.25947.qm@web62008.mail.re1.yahoo.com>
	<87aaj3cdoi.fsf@wanadoo.es>
	<460732.65959.qm@web62005.mail.re1.yahoo.com>
	<871v4fc914.fsf@wanadoo.es>
Message-ID: <197888.65195.qm@web62002.mail.re1.yahoo.com>

Sorry I wasted your time ?scar and the rest of the mailing list,

I discovered the problem:  I was building in one directory but generating the 
CMake build scripts in an identically named folder in the parent directory.  I 
was using stale build scripts.  That's why they looked the same each time 
despite my having regenerated the build-scripts with the CMake GUI.  Once I got 
the scripts generated in the right directory, they built 100% correctly.

My apologies,

--Sam Crow


----- Original Message ----
> From: ?scar Fuentes <ofv at wanadoo.es>
> To: Samuel Crow <samuraileumas at yahoo.com>
> Cc: ?scar Fuentes <ofv at wanadoo.es>; LLVM Developers Mailing List 
><llvmdev at cs.uiuc.edu>
> Sent: Fri, January 14, 2011 6:20:23 PM
> Subject: Re: Circular Deps from CMake build using makefile
> 
> Samuel Crow <samuraileumas at yahoo.com>  writes:
> 
> > I have attached the logfiles here.
> 
> I think you didn't  set CMAKE_BUILD_TYPE while configuring the cmake
> build. On your build  directory, please do:
> 
> make clean
> cmake    -DCMAKE_BUILD_TYPE=Debug     path/to/your/llvm/source/root
> make
> 
> If that doesn't work, show the  exact command lines you used for invoking
> cmake and the `configure'  script.
> 


      


From eblot.ml at gmail.com  Sat Jan 15 07:35:11 2011
From: eblot.ml at gmail.com (Emmanuel Blot)
Date: Sat, 15 Jan 2011 14:35:11 +0100
Subject: [LLVMdev] Cross-compiling the ARM toolchain
In-Reply-To: <AANLkTimH36_T8vVn3u_BJKgdx-0vqoGT2B8J_85Mg0Tn@mail.gmail.com>
References: <AANLkTinE23LDBLiqHhoSRJrFJ=YkqbV8-gh-M=tEKRen@mail.gmail.com>
	<AANLkTiko14MZeQOumUBf0kesy46cARF=G9DYm4uYGT0d@mail.gmail.com>
	<AANLkTindCxCc0L-zOfCc4yZ9xAp46UwiiW1r9XeZTJ4e@mail.gmail.com>
	<247D0B9D-18FC-437C-A373-2A83A6CC9366@apple.com>
	<AANLkTikjSnEoeaCVqt6CN07wtfVD+MK3hzofktwxi4K2@mail.gmail.com>
	<0E5541FA-FDB9-4885-859E-537A494D7E6D@apple.com>
	<AANLkTikA6s-HPoaByuUYFcywm9DrPHEguSVBxarhOAD3@mail.gmail.com>
	<AANLkTin5gOxOTsMFfUa9zCgha52A7EPj0BZe0kKoYBkj@mail.gmail.com>
	<AANLkTikfwS=D+ngnJSR1_NYAFDEv9WrB0jUvkcVN6W3+@mail.gmail.com>
	<AANLkTimH36_T8vVn3u_BJKgdx-0vqoGT2B8J_85Mg0Tn@mail.gmail.com>
Message-ID: <AANLkTim6CfTNsQSLbr_ZiVUuHns337-mK-0dwtBRcmWj@mail.gmail.com>

>> I'm used to build GCC (4.x) toolchains with newlib, but how can I do
>> the same with llvm-gcc ?
> Pretty much same way as with gcc. E.g. via --with-newlib, etc.

I successfully built llvm+clang, but it seems that the newlib library
files have neither been compiled nor installed.

With GCC (at the time 4.5.2), the build steps are straightforward:
newlib/ and libgloss/ directories should be copied/linked to the top
level directory of the GCC source directory, and the --with-newlib
option switch enabled as a 'configure' parameter.
The library gets built along with GCC, and installed into the GCC
destination folders (libc.a, libm.a, ... as well as the header files)

Is there some specific commands/option switches to build the newlib
library files with llvm+clang ?

Thanks,
Emmanuel

From anton at korobeynikov.info  Sat Jan 15 10:25:39 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Sat, 15 Jan 2011 19:25:39 +0300
Subject: [LLVMdev] Cross-compiling the ARM toolchain
In-Reply-To: <AANLkTim6CfTNsQSLbr_ZiVUuHns337-mK-0dwtBRcmWj@mail.gmail.com>
References: <AANLkTinE23LDBLiqHhoSRJrFJ=YkqbV8-gh-M=tEKRen@mail.gmail.com>
	<AANLkTiko14MZeQOumUBf0kesy46cARF=G9DYm4uYGT0d@mail.gmail.com>
	<AANLkTindCxCc0L-zOfCc4yZ9xAp46UwiiW1r9XeZTJ4e@mail.gmail.com>
	<247D0B9D-18FC-437C-A373-2A83A6CC9366@apple.com>
	<AANLkTikjSnEoeaCVqt6CN07wtfVD+MK3hzofktwxi4K2@mail.gmail.com>
	<0E5541FA-FDB9-4885-859E-537A494D7E6D@apple.com>
	<AANLkTikA6s-HPoaByuUYFcywm9DrPHEguSVBxarhOAD3@mail.gmail.com>
	<AANLkTin5gOxOTsMFfUa9zCgha52A7EPj0BZe0kKoYBkj@mail.gmail.com>
	<AANLkTikfwS=D+ngnJSR1_NYAFDEv9WrB0jUvkcVN6W3+@mail.gmail.com>
	<AANLkTimH36_T8vVn3u_BJKgdx-0vqoGT2B8J_85Mg0Tn@mail.gmail.com>
	<AANLkTim6CfTNsQSLbr_ZiVUuHns337-mK-0dwtBRcmWj@mail.gmail.com>
Message-ID: <AANLkTikAAB_QTQoio+-p20pe3bYfKnbE3c2wZHp_jCtL@mail.gmail.com>

> Is there some specific commands/option switches to build the newlib
> library files with llvm+clang ?
No.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From eblot.ml at gmail.com  Sat Jan 15 11:06:48 2011
From: eblot.ml at gmail.com (Emmanuel Blot)
Date: Sat, 15 Jan 2011 18:06:48 +0100
Subject: [LLVMdev] Cross-compiling the ARM toolchain
In-Reply-To: <AANLkTikAAB_QTQoio+-p20pe3bYfKnbE3c2wZHp_jCtL@mail.gmail.com>
References: <AANLkTinE23LDBLiqHhoSRJrFJ=YkqbV8-gh-M=tEKRen@mail.gmail.com>
	<AANLkTiko14MZeQOumUBf0kesy46cARF=G9DYm4uYGT0d@mail.gmail.com>
	<AANLkTindCxCc0L-zOfCc4yZ9xAp46UwiiW1r9XeZTJ4e@mail.gmail.com>
	<247D0B9D-18FC-437C-A373-2A83A6CC9366@apple.com>
	<AANLkTikjSnEoeaCVqt6CN07wtfVD+MK3hzofktwxi4K2@mail.gmail.com>
	<0E5541FA-FDB9-4885-859E-537A494D7E6D@apple.com>
	<AANLkTikA6s-HPoaByuUYFcywm9DrPHEguSVBxarhOAD3@mail.gmail.com>
	<AANLkTin5gOxOTsMFfUa9zCgha52A7EPj0BZe0kKoYBkj@mail.gmail.com>
	<AANLkTikfwS=D+ngnJSR1_NYAFDEv9WrB0jUvkcVN6W3+@mail.gmail.com>
	<AANLkTimH36_T8vVn3u_BJKgdx-0vqoGT2B8J_85Mg0Tn@mail.gmail.com>
	<AANLkTim6CfTNsQSLbr_ZiVUuHns337-mK-0dwtBRcmWj@mail.gmail.com>
	<AANLkTikAAB_QTQoio+-p20pe3bYfKnbE3c2wZHp_jCtL@mail.gmail.com>
Message-ID: <AANLkTimSOsvw+FjZO0vDTO4ofvWF4O7Bmpo_eF1igO5S@mail.gmail.com>

>> Is there some specific commands/option switches to build the newlib
>> library files with llvm+clang ?
> No.

Did anyone succeed in building such a toolchain (for arm-eabi)?

Are clang+llvm supposed to build libc/libm libraries, or should I
first build these libraries with a regular GCC and somehow copy them
into the clang+llvm destination folder?

Thanks,
Emmanuel.

From samuraileumas at yahoo.com  Fri Jan 14 17:55:19 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Fri, 14 Jan 2011 15:55:19 -0800 (PST)
Subject: [LLVMdev] Circular Deps from CMake build using makefile
In-Reply-To: <87aaj3cdoi.fsf@wanadoo.es>
References: <820891.76867.qm@web62006.mail.re1.yahoo.com>
	<87d3o0e7vv.fsf@wanadoo.es>
	<835266.14025.qm@web62001.mail.re1.yahoo.com>
	<874o9behu1.fsf@wanadoo.es>
	<19957.25947.qm@web62008.mail.re1.yahoo.com>
	<87aaj3cdoi.fsf@wanadoo.es>
Message-ID: <460732.65959.qm@web62005.mail.re1.yahoo.com>





----- Original Message ----
> From: ?scar Fuentes <ofv at wanadoo.es>
> To: Samuel Crow <samuraileumas at yahoo.com>
> Cc: ?scar Fuentes <ofv at wanadoo.es>; LLVM Developers Mailing List 
><llvmdev at cs.uiuc.edu>
> Sent: Fri, January 14, 2011 4:39:57 PM
> Subject: Re: Circular Deps from CMake build using makefile
> 
> Samuel Crow <samuraileumas at yahoo.com>  writes:
> 
> > This time the autotools version of LLVM trunk build with  Clang trunk 
>compiled in 
>
> > Debug+Asserts mode without complaint with  --enable-bindings=none.  I suspect 
>
> > this makes something fishy  looking with the CMake build.  Do you need 
>logfiles 
>
> > from  configure?
> 
> I'm clueless about what's happening there. The cyclic  dependency among
> LLVMSupport and LLVMSystem makes no sense (the other cyclic  dependency
> is a different history) Others are using cmake on OS/X and didn't  report
> any problem. I'll like to help, but can't think of anything that  could
> be wrong on the cmake build (apart from compiler options: make  VERBOSE=1
> will show the full command lines and you can compare the  invocations or
> the compiler and linker for the cmake and the `configure'  build.) Sorry.
> 

I have attached the logfiles here.

Thanks again for helping me,

--Sam


      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake.log
Type: application/octet-stream
Size: 932663 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/86f3a4c7/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: automake.log
Type: application/octet-stream
Size: 2247437 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110114/86f3a4c7/attachment-0003.obj 

From matthieu.monrocq at gmail.com  Sat Jan 15 10:31:38 2011
From: matthieu.monrocq at gmail.com (Matthieu Monrocq)
Date: Sat, 15 Jan 2011 17:31:38 +0100
Subject: [LLVMdev] Spell Correction Efficiency
In-Reply-To: <081AD223-B908-4757-973E-45A57CEDD942@apple.com>
References: <AANLkTiknm=CyuXLvKAVjFvV0NJoXrKWc=Rk0qp4KM63d@mail.gmail.com>
	<FB64592C-3944-46D8-AADE-4A4F88327D71@apple.com>
	<AANLkTiknnn7=6rabMg88kvvzyDEJyaE_YPQo7zwqpuAG@mail.gmail.com>
	<081AD223-B908-4757-973E-45A57CEDD942@apple.com>
Message-ID: <AANLkTik5QJD5tO+EikEo83obpjebU68hTHj57iX+2wby@mail.gmail.com>

Hello Doug,

*putting llvmdev in copy since they are concerned too*

I've finally got around to finish a working implementation of the typical
Levenshtein Distance with the diagonal optimization.

I've tested it against the original llvm implementation and checked it on a
set of ~18k by randomly generating a variation of each word and checking
that both implementations would return the same result... took me some time
to patch the diagonal version, but they now do.

I have left the older method in place, especially because I saw that it was
used in FileCheck and was a bit wary of any side-effect I might introduce
there.

I have thus created a new method: unsigned
StringRef::levenshtein_distance(StringRef other, unsigned maxEditDistance)
and replace the two uses of edit_distance in Sema\SemaLookup.cpp with it.

I have ditched the "AllowReplace" argument since it further complicated the
logic of an already ~150 lines method for no obvious gain (as far as I could
see) and I have also explicited the computations a bit by using named
temporaries.

Unfortunately I have only a Windows machine at hand for the moment and the
tests don't work that well... so I'd appreciate if anyone could check my
changes.

I have done two separate patches: one for llvm (stringref-path.diff) and one
for clang (sema-patch.diff), the llvm patch should be applied first of
course.

Since it is my first time proposing a patch, I hope I have done things right
:)

Regards,
Matthieu.


2010/12/1 Douglas Gregor <dgregor at apple.com>

>
> On Nov 21, 2010, at 11:58 AM, Matthieu Monrocq wrote:
>
> Hi Doug,
>
> 2010/11/9 Douglas Gregor <dgregor at apple.com>
>
>> Hi Matthieu,
>>
>> On Nov 8, 2010, at 3:05 PM, Matthieu Monrocq wrote:
>>
>> Hi Doug,
>>
>> We had a discussion a month ago I think about the Spell Correction
>> algorithm which was used in CLang, notably for auto-completion, based on the
>> Levenstein distance.
>>
>> It turns out I just came upon this link today:
>> http://nlp.stanford.edu/IR-book/html/htmledition/k-gram-indexes-for-spelling-correction-1.html
>>
>> The idea is to use bigrams (2-letters parts of a word) to build an index
>> of the form (bigram > all words containing this bigram), then use this index
>> to retrieve all the words with enough bigrams in common with the word you
>> are currently trying to approximate.
>>
>> This drastically reduces the set of identifiers on which computing the
>> Levenstein distance, especially if we directly trim those which have a
>> length incompatible anyway from the beginning. Furthermore, the result may
>> be ordered by the number of common bigrams, and thus the Levenstein distance
>> may be computed first on the most promising candidates in order to have the
>> maximum edit distance drop quickly.
>>
>> I have implemented a quick algorithm in python (~70 lines, few comments
>> though), to test it out, and I find the results quite promising.
>>
>> I have used the following corpus: http://norvig.com/big.txt  (~6 MB)
>> which can be found on Peter Norvig's page:
>> http://norvig.com/spell-correct.html
>>
>> For example, looking for the word "neaer":
>>
>> Number of distinct Words from the corpus: 48911
>> Number of distinct Bigrams from the corpus: 1528
>> Number of results: [(1, 34), (2, 1133)]
>> Most promising results: (1, ['Kearney', 'NEAR', 'nearing', 'linear',
>> 'learner', 'uneasy', 'nearest', 'neat', 'lineage', 'leaned', 'Nearer',
>> 'Learned', 'Nearly', 'cleaner', 'cleaned', 'neatly', 'nearer', 'earned', 'n
>> eared', 'nearly', 'learned', 'nearby', 'Nearest', 'near', 'meanest',
>> 'earnest', 'Near', 'beneath', 'gleaned', 'Beneath', 'kneaded', 'weaned',
>> 'Freneau', 'guineas'])
>>
>> Or for the word "sppose":
>>
>> Number of distinct Words from the corpus: 48911
>> Number of distinct Bigrams from the corpus: 1528
>> Number of results: [(1, 14), (2, 136), (3, 991)]
>> Most promising results: (1, ['disposal', 'opposed', 'opposing', 'Oppose',
>> 'suppose', 'Dispose', 'dispose', 'apposed', 'disposed', 'oppose',
>> 'supposed', 'opposite', 'supposes', 'Suppose'])
>>
>>
>> Do you think the method worth investigating ?
>>
>>
>> Yes, I do. Typo correction performance is very important (and has
>> historically been very poor).
>>
>> Note that there are also more-efficient algorithms for computing the
>> Levenstein distance (e.g., d*min(m, n) rather than m*n). We should also
>> consider those.
>>
>> - Doug
>>
>
> The diagonal optimization you are talking about seems to bring a *2 to *3
> speed-up, which is quite nice, however the algorithm is tricky and I am not
> sure yet that I have the correct distance in every case. I am going to
> settle and implement some fuzzy testers this week to help find bugs in the
> various algorithms.
>
>
> Okay. Replacing our current implementation with one of the faster
> algorithms would be great, since that would not require any infrastructure
> changes at all. Just replace the existing StringRef::edit_distance and we're
> done.
>
> Anyway I've been exploring a few options regarding typo correction these
> past weeks and I now have a little ecosystem of various solutions, however I
> currently lack 3 things:
> - a real lexicon (mine is about ~18k words) --> I would appreciate if
> someone pointed me to a more representative lexicon, otherwise I may try and
> index a subset of the boost library and see what I can come up with
>
>
> I tend to use Cocoa.h on Mac OS, which is great for Objective-C. Boost is
> reasonable for C++ code.
>
> - a real benchmark: I have no idea how to "select" good (typo-ed) words for
> testing / benchmarking the typo correction algorithms. I have started by
> always using the same word (at a distance of 1) but it clearly isn't
> representative and my knowledge of statistics is rather lacking so if you
> have an approach to suggest...
>
>
> Random permutations of randomly-selected words from the lexicon would be
> fine, I think.
>
> - a good Trie implementation, or hints in how to implement one. A Trie
> seems to be the best index (quite compact yet ordered), however I only have
> a naive implementation at the moment.
>
> My best concurrent so far seems to be based on CS Language theory and
> involves extracting the set of words recognized by two automatons, one being
> the Trie, which recognize all the known words, and one being crafted for the
> word we are looking for, and recognize all words in a certain distance.
> However for maximal efficiency, this requires some structures to be
> precomputed, and this structure grows exponentially with the distance. It
> works for distance 1 to 3, is already 2.8MB for distance 4 (and takes about
> 70s to be computed on my machine, though I suppose it would be faster to
> deserialize a precomputed version), and I haven't dared trying further as it
> seems to be a geometrical serie with a factor of ~28 !
>
>
> The issue with using a trie is that you have to actually build the trie. It
> can't be something that is maintained online, because typo correction must
> be zero cost unless it is needed (since most compilation runs never need
> typo correction). Also, performance in the presence of precompiled headers
> is also important: we don't want to have to construct the trie when building
> the precompiled header, for example.
>
> Would it be considered a loss to limit ourselves to words within distance
> min(word.length()/4+1, 3) ?
>
>
> I could live with that. Clang already has limits on the maximum edit
> distance it will accept for a typo correction.
>
> It occured to me that one transformation (the transposition of adjacent
> characters) was quite a common typo. I have toyed with the
> Damereau-Levenshtein distance but this is quite harder to implement the
> optmizations with it. Without it a simple transposition costs 2
> transformations (one addition and one deletion) so in this case 3 is rather
> limiting, but still I don't know if looking much further is very
> interesting.
>
>
> Making transposition a 1-unit transformation would be an improvement. It
> can be added to the current implementation or come in with a new
> implementation.
>
> - Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110115/f304f400/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sema-patch.diff
Type: application/octet-stream
Size: 3422 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110115/f304f400/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stringref-patch.diff
Type: application/octet-stream
Size: 15364 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110115/f304f400/attachment-0001.obj 

From ww345ww at gmail.com  Sat Jan 15 21:15:26 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Sun, 16 Jan 2011 11:15:26 +0800
Subject: [LLVMdev] About register allocation
Message-ID: <AANLkTikAbaG0h_3Z1eOyXVAT-wzgMRKyuRE82zCK9=oE@mail.gmail.com>

I have tested the register allocation in llvm, using: $llc -debug test.bc
where, test.c is like:

        int a, b, c, d, x;
        a = 3;
        b = 5;
        d = 4;
        x = 100;
        if ( a > b )
        ......

 And I got the machine code before register allocation:

        MOV32mi <fi#2>, 1, %reg0, 0, %reg0, 3; mem:ST4[%a]
        MOV32mi <fi#3>, 1, %reg0, 0, %reg0, 5; mem:ST4[%b]
        MOV32mi <fi#5>, 1, %reg0, 0, %reg0, 4; mem:ST4[%d]
        MOV32mi <fi#6>, 1, %reg0, 0, %reg0, 100; mem:ST4[%x]
        %reg16384<def> = MOV32rm <fi#3>, 1, %reg0, 0, %reg0; mem:LD4[%b]
GR32:%reg16384
        CMP32mr <fi#2>, 1, %reg0, 0, %reg0, %reg16384<kill>,
%EFLAGS<imp-def>; mem:LD4[%a] GR32:%reg16384
        JLE_4 <BB#2>, %EFLAGS<imp-use,kill>

 The machine code after register allocation:

        MOV32mi <fi#2>, 1, %reg0, 0, %reg0, 3; mem:ST4[%a]
        MOV32mi <fi#3>, 1, %reg0, 0, %reg0, 5; mem:ST4[%b]
        MOV32mi <fi#5>, 1, %reg0, 0, %reg0, 4; mem:ST4[%d]
        MOV32mi <fi#6>, 1, %reg0, 0, %reg0, 100; mem:ST4[%x]
        %EAX<def> = MOV32rm <fi#3>, 1, %reg0, 0, %reg0;
mem:LD4[%b]Remembering SS#3 in physreg EAX
        CMP32mr <fi#2>, 1, %reg0, 0, %reg0, %EAX<kill>, %EFLAGS<imp-def>;
mem:LD4[%a]
        JLE_4 <BB#2>, %EFLAGS<imp-use,kill>

 It seems only variables named "reg<num>" are allocated into registers. My
problem is, why not allocate the local variables "a", "b", .etc into
registers instead of into stack frame? Is there any problem for allocating
"a" into register file rather than stack frame with offset of 2?



-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110116/6389cd9a/attachment.html 

From stoklund at 2pi.dk  Sat Jan 15 21:22:46 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Sat, 15 Jan 2011 19:22:46 -0800
Subject: [LLVMdev] About register allocation
In-Reply-To: <AANLkTikAbaG0h_3Z1eOyXVAT-wzgMRKyuRE82zCK9=oE@mail.gmail.com>
References: <AANLkTikAbaG0h_3Z1eOyXVAT-wzgMRKyuRE82zCK9=oE@mail.gmail.com>
Message-ID: <6FF950B6-42DF-43A9-9AA0-198498CADFBF@2pi.dk>


On Jan 15, 2011, at 7:15 PM, Qingan Li wrote:

> I have tested the register allocation in llvm, using: $llc -debug test.bc
> where, test.c is like:
> 
>         int a, b, c, d, x;
>         a = 3;
>         b = 5;
>         d = 4;
>         x = 100;
>         if ( a > b ) 
>         ......

>  It seems only variables named "reg<num>" are allocated into registers. My problem is, why not allocate the local variables "a", "b", .etc into registers instead of into stack frame? Is there any problem for allocating "a" into register file rather than stack frame with offset of 2? 

You need to optimize your bitcode first, llc doesn't do that.

Run the bitcode through "opt -O2", or create it with "llvm-gcc -O2 -emit-llvm".

/jakob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110115/2ec71e37/attachment.bin 

From ww345ww at gmail.com  Sat Jan 15 22:06:18 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Sun, 16 Jan 2011 12:06:18 +0800
Subject: [LLVMdev] About test suits Cont1
Message-ID: <AANLkTim+Jh+zp1jtXf-DiNHHrXnS-DBHBjoMzBbLSbXz@mail.gmail.com>

*[qali at qali llvm-2.8-rev]$ find . -exec grep -n "LLVMCC_EMITIR_FLAG" ./ {}
\;*
./projects/test-suite/Makefile.tests:47: -$(LCC) $(CPPFLAGS) $(CFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:51: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:55: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:59: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:63: -$(LCC) $(CPPFLAGS) $(CFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
./projects/test-suite/Makefile.tests:67: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
$(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)

*There are errors in config.log, but I need your help for clarifying them (I
selected the first four errors below): *
error 1:
configure:3475: gcc -E  conftest.c
conftest.c:9:28: error: ac_nonexistent.h: No such file or directory
configure:3481: $? = 1
configure: failed program was:
| #include <ac_nonexistent.h>

error 2:
configure:4171: gcc -c -g -O2  conftest.c >&5
conftest.c: In function 'main':
conftest.c:26: error: 'not' undeclared (first use in this function)
conftest.c:26: error: (Each undeclared identifier is reported only once
conftest.c:26: error: for each function it appears in.)
conftest.c:26: error: expected ';' before 'big'
configure:4177: $? = 1
configure: failed program was:
| #include <sys/types.h>
| #include <sys/param.h>
|
| int
| main ()
| {
| #if BYTE_ORDER != BIG_ENDIAN
|  not big endian
| #endif
|
|   ;
|   return 0;
| }

error 3:
configure:12186: gcc -c -g -O2  conftest.c >&5
conftest.c:104:16: error: dl.h: No such file or directory
configure:12192: $? = 1

error 4:
configure:12269: result: no
configure:12302: checking for dl.h
configure:12310: result: no
configure:12169: checking sys/dl.h usability
configure:12186: gcc -c -g -O2  conftest.c >&5
conftest.c:104:20: error: sys/dl.h: No such file or directory
configure:12192: $? = 1



2011/1/14 Eric Christopher <echristo at apple.com>

>
> On Jan 13, 2011, at 6:22 PM, Qingan Li wrote:
>
> make[4]: Entering directory
> `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE'
> /home/qali/Src/llvm-2.8/autoconf/mkinstalldirs Output > /dev/null
> /home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-gcc
> -I/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE
> -I/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE
> -I/home/qali/build/llvm-2.8-rev/include
> -I/home/qali/Src/llvm-2.8/projects/test-suite/include -I../../../../include
> -I/home/qali/Src/llvm-2.8/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
> -DNDEBUG  -O3  -msse2 -m64 -fomit-frame-pointer -S
> /home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c
> -o Output/sse.expandfft.ll
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as
> Output/sse.expandfft.ll -o Output/sse.expandfft.bc
> /home/qali/build/llvm-2.8-rev/Debug+Asserts/bin/llvm-as:
> Output/sse.expandfft.ll:1:2: error: expected top-level entity
> .file
> "/home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c"
>
>
> Something is odd here. Can you do a grep in your top-level build directory
> for LLVMCC_EMITIR_FLAG?
>
> It's obviously blank and it shouldn't be. You should take a look at the
> configure output and see what happened.
>
> -eric
>



-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110116/ff1a0e2a/attachment.html 

From trevor at galois.com  Mon Jan 17 00:51:04 2011
From: trevor at galois.com (Trevor Elliott)
Date: Sun, 16 Jan 2011 22:51:04 -0800
Subject: [LLVMdev] Fw:  LLVM GC
In-Reply-To: <17226.12707.qm@web62004.mail.re1.yahoo.com>
References: <4D30F5AA.1040106@galois.com>
	<17226.12707.qm@web62004.mail.re1.yahoo.com>
Message-ID: <4D33E6D8.2030300@galois.com>

Hi Sam,

I've not actually gotten to the linking process with my runtime, as I've
compiled it with clang -emit-llvm -c, and then archived it with llvm-ar
and llvm-ranlib.  I'm also not producing a GC plugin, as I'm using the
builtin "shadow-stack" strategy.

My current build process looks like this:

 1. build the compiler
 2. build the runtime using clang -emit-llvm -c
 3. generate an archive from the runtime .bc files using llvm-ar and
llvm-ranlib
 3. compile a program with the compiler, producing a .bc file
 4. link the program and runtime together using llvm-ld
 5. run the program with lli

This all works fine until step 5 when the stack trace gets generated.
The function that it complains about, @main, is the main function from
my runtime.  When disassembled with llvm-dis, it doesn't have a gc
attribute on the declaration.  Should it still be getting processed by
the "shadow-stack" strategy?

Thanks!

--trevor


On 01/14/2011 05:33 PM, Samuel Crow wrote:
> Forgot to CC the list.
> 
> 
> ----- Forwarded Message ----
>> From: Samuel Crow <samuraileumas at yahoo.com>
>> To: Trevor Elliott <trevor at galois.com>
>> Sent: Fri, January 14, 2011 7:33:15 PM
>> Subject: Re: [LLVMdev] LLVM GC
>>
>> Hi Trevor,
>>
>> Are you linking with LibStdC++ or LibC++?  That is a  requirement for running 
>> code that has been compiled from C++ to  bitcode.
>>
>> Hope this helps,
>>
>> --Sam Crow
>>
>>
>> ----- Original  Message ----
>>> From: Trevor Elliott <trevor at galois.com>
>>> To: llvmdev at cs.uiuc.edu
>>> Sent: Fri,  January 14, 2011 7:17:30 PM
>>> Subject: [LLVMdev] LLVM GC
>>>
>>>  Hi,
>>>
>>> I've been implementing a compiler that targets LLVM, and  was  looking
>>> into using the shadow-stack gc strategy.   Currently, I build the  runtime
>>> with clang (using -emit-llvm), and  then link that with the LLVM  bitcode
>>> output from my compiler using  llvm-ld.
>>>
>>> This works fine without  the gc strategy  annotations and use of the
>>> llvm.gcroot intrinsic, but adding  them  causes some odd behavior: the
>>> resulting bitcode will generate a  large  stack trace from lli (appended
>>> at the end of this message),  and the resulting  native assembly,
>>> generated with llc, will never  update my llvm_gc_root_chain  global.
>>>
>>> Interestingly, if I  build my runtime with g++, or clang  without
>>> -emit-llvm, and link  everything together after generating  native
>>> assembly from the  output of my compiler, it works.  The stack  roots get
>>>  registered, and the llvm_gc_root_chain global gets  updated.
>>>
>>> Is linking in the runtime as an LLVM bitcode object something   that I
>>> should expect to work, or does it make more sense to build  the  runtime
>>> for the target, and not try to emit LLVM bitcode  programs from my  
> compiler?
>>>
>>> Thanks!
>>>
>>>  --trevor
>>>
>>>
>>> 0  libLLVM-2.8.so    0x0000003cc36eee9f
>>> 1  libLLVM-2.8.so   0x0000003cc36ef99a
>>> 2  libpthread.so.0  0x0000003cc200f4a0
>>>  3  libLLVM-2.8.so   0x0000003cc33360dd
>>>  llvm::StructType::StructType(llvm::LLVMContext&,   std::vector<llvm::Type
>>> const*, std::allocator<llvm::Type  const*>  > const&, bool) + 237
>>> 4   libLLVM-2.8.so   0x0000003cc3337c95
>>>  llvm::StructType::get(llvm::LLVMContext&,  std::vector<llvm::Type  const*,
>>> std::allocator<llvm::Type const*>  > const&,  bool) + 533
>>> 5  libLLVM-2.8.so   0x0000003cc3242d58
>>>  6  libLLVM-2.8.so  0x0000003cc318f09e
>>> 7    libLLVM-2.8.so   0x0000003cc3330628
>>>  llvm::FPPassManager::runOnFunction(llvm::Function&) +  424
>>>  8  libLLVM-2.8.so   0x0000003cc33307cb
>>>  llvm::FunctionPassManagerImpl::run(llvm::Function&) +  91
>>>  9  libLLVM-2.8.so   0x0000003cc33309bd
>>>  llvm::FunctionPassManager::run(llvm::Function&) +  173
>>> 10  libLLVM-2.8.so   0x0000003cc33e8647
>>>  llvm::JIT::jitTheFunction(llvm::Function*,  llvm::MutexGuard const&) +  39
>>> 11 libLLVM-2.8.so   0x0000003cc33e8a2f
>>>  llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*,   llvm::MutexGuard
>>> const&) + 15
>>> 12 libLLVM-2.8.so    0x0000003cc33e8cde
>>> llvm::JIT::getPointerToFunction(llvm::Function*)  +  606
>>> 13 libLLVM-2.8.so   0x0000003cc33ea253
>>>  llvm::JIT::runFunction(llvm::Function*,   std::vector<llvm::GenericValue,
>>>  std::allocator<llvm::GenericValue>  > const&) + 67
>>> 14  libLLVM-2.8.so   0x0000003cc336ad4a
>>>  llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
>>>  std::vector<std::string,  std::allocator<std::string> >  const&, char
>>> const* const*) +  1130
>>> 15 lli              0x0000000000404cd6 main  + 2054
>>> 16 libc.so.6         0x0000003cc1c1ec5d __libc_start_main + 253
>>> 17 lli               0x0000000000403689
>>> Stack dump:
>>>  0.     Program arguments: lli test.bc
>>> 1.    Running  pass 'Lower  Garbage Collection Instructions' on function 
>> '@main'
>>> zsh: segmentation fault  (core dumped)   ./test
>>>
>>>
>>
>>
>>       
>>
> 
> 
>       
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3612 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110116/96773499/attachment.bin 

From abhirupju at gmail.com  Mon Jan 17 01:10:41 2011
From: abhirupju at gmail.com (Abhirup Ghosh)
Date: Mon, 17 Jan 2011 12:40:41 +0530
Subject: [LLVMdev] File reading in LLVM 2.8
Message-ID: <AANLkTi=xX0-xxLM-=ZUzN0vM+R5+_9rox7htna9GV-Zb@mail.gmail.com>

Hi,
     I am new to LLVM. I am trying to read a plain text file in a llvm
pass. But getting an error -

llvm[0]: Linking Release Loadable Module LLVMHello.so
/usr/bin/ld: /home/abhirup/llvm/llvm2.8_Install/llvm-2.8/lib/Transforms/Hello/Release/Hello.o:
relocation R_X86_64_PC32 against undefined symbol `(anonymous
namespace)::Hello::update_sec_read(char const*)' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

I have used simple ifstream code -

void update_sec_read (const char* Filename)
{
  std::ifstream In(Filename);
  if (!In.good()) {
    errs() << "couldn't load file '" << Filename << "'!\n";
    return;
  }
  while (In) {
  }
}


Can anyone please help me out?



- Abhirup Ghosh
M. Tech
Department of Computer Science & Engg.
IIT, Bombay,
Mumbai, India
email - abhirupju at gmail.com , abhirup at cse.iitb.ac.in

From baldrick at free.fr  Mon Jan 17 03:11:40 2011
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 17 Jan 2011 10:11:40 +0100
Subject: [LLVMdev] File reading in LLVM 2.8
In-Reply-To: <AANLkTi=xX0-xxLM-=ZUzN0vM+R5+_9rox7htna9GV-Zb@mail.gmail.com>
References: <AANLkTi=xX0-xxLM-=ZUzN0vM+R5+_9rox7htna9GV-Zb@mail.gmail.com>
Message-ID: <4D3407CC.8010102@free.fr>

Hi Abhirup,

`(anonymous
> namespace)::Hello::update_sec_read(char const*)' can not be used when
> making a shared object; recompile with -fPIC

did you compile it with -fPIC ?

Ciao, Duncan.

From rich at pennware.com  Mon Jan 17 04:30:12 2011
From: rich at pennware.com (Richard Pennington)
Date: Mon, 17 Jan 2011 04:30:12 -0600
Subject: [LLVMdev] clang/LLVM cross testing environment
Message-ID: <4D341A34.3000109@pennware.com>

Hi,

I've been working on combining LLVM, clang, the NetBSD standard C 
library, compiler-rt, QEMU, GDB, and GNU binutils as a cross compilation 
environment. My goal is to target small embedded systems, but I think 
that what I'm working on may be of interest to other LLVM/clang 
developers as I have been able to use the environment to fix several 
code generation issues in LLVM.

As of today, I can compile non-trivial programs for ARM, i386, Mips, 
Microblaze, PowerPC, PowerPC64, and X86_64. These programs can be run 
with the modified NetBSD C library under QEMU in Linux user space 
emulation mode on my X86_64 Linux box. If anyone is interested in trying 
it out it is at http://ellcc.org.

Some important notes:
* I have built this on a X86_64 Linux system only. Linux is required to 
get the QEMU Linux user mode support.
* The SVN checkout is huge, since it has everything mentioned above in it.
* This is a work in progress: There are things that don't work. Not for 
the faint of heart!
* It is fairly easy to build the complete package, see 
http://ellcc.org/installation.html and http://ellcc.org/targetsupport.html
* Not all of the NetBSD standard library has been ported. There are a 
lot of system calls, etc. that have not been tested. I've been adding 
things as needed, not in any systematic way.
* It is currently based on a fairly recent version of LLVM/clang: r122956.
* Processor support is currently limited to those that are supported by 
QEMU, just because I wanted to have a common run/debug environment.

Feel free to check it out.

-Rich


From trevor at galois.com  Mon Jan 17 14:46:37 2011
From: trevor at galois.com (Trevor Elliott)
Date: Mon, 17 Jan 2011 12:46:37 -0800
Subject: [LLVMdev] Fw:  LLVM GC
In-Reply-To: <4D33E6D8.2030300@galois.com>
References: <4D30F5AA.1040106@galois.com>	<17226.12707.qm@web62004.mail.re1.yahoo.com>
	<4D33E6D8.2030300@galois.com>
Message-ID: <4D34AAAD.6010909@galois.com>

I've figured out why the stack trace comes from @main, and not somewhere
within my compiler's output: the output from the compiler is getting
inlined in the @main function from the runtime, thus pushing its gc
"shadow-stack" attribute out.

--trevor

On 01/16/2011 10:51 PM, Trevor Elliott wrote:
> Hi Sam,
> 
> I've not actually gotten to the linking process with my runtime, as I've
> compiled it with clang -emit-llvm -c, and then archived it with llvm-ar
> and llvm-ranlib.  I'm also not producing a GC plugin, as I'm using the
> builtin "shadow-stack" strategy.
> 
> My current build process looks like this:
> 
>  1. build the compiler
>  2. build the runtime using clang -emit-llvm -c
>  3. generate an archive from the runtime .bc files using llvm-ar and
> llvm-ranlib
>  3. compile a program with the compiler, producing a .bc file
>  4. link the program and runtime together using llvm-ld
>  5. run the program with lli
> 
> This all works fine until step 5 when the stack trace gets generated.
> The function that it complains about, @main, is the main function from
> my runtime.  When disassembled with llvm-dis, it doesn't have a gc
> attribute on the declaration.  Should it still be getting processed by
> the "shadow-stack" strategy?
> 
> Thanks!
> 
> --trevor
> 
> 
> On 01/14/2011 05:33 PM, Samuel Crow wrote:
>> Forgot to CC the list.
>>
>>
>> ----- Forwarded Message ----
>>> From: Samuel Crow <samuraileumas at yahoo.com>
>>> To: Trevor Elliott <trevor at galois.com>
>>> Sent: Fri, January 14, 2011 7:33:15 PM
>>> Subject: Re: [LLVMdev] LLVM GC
>>>
>>> Hi Trevor,
>>>
>>> Are you linking with LibStdC++ or LibC++?  That is a  requirement for running 
>>> code that has been compiled from C++ to  bitcode.
>>>
>>> Hope this helps,
>>>
>>> --Sam Crow
>>>
>>>
>>> ----- Original  Message ----
>>>> From: Trevor Elliott <trevor at galois.com>
>>>> To: llvmdev at cs.uiuc.edu
>>>> Sent: Fri,  January 14, 2011 7:17:30 PM
>>>> Subject: [LLVMdev] LLVM GC
>>>>
>>>>  Hi,
>>>>
>>>> I've been implementing a compiler that targets LLVM, and  was  looking
>>>> into using the shadow-stack gc strategy.   Currently, I build the  runtime
>>>> with clang (using -emit-llvm), and  then link that with the LLVM  bitcode
>>>> output from my compiler using  llvm-ld.
>>>>
>>>> This works fine without  the gc strategy  annotations and use of the
>>>> llvm.gcroot intrinsic, but adding  them  causes some odd behavior: the
>>>> resulting bitcode will generate a  large  stack trace from lli (appended
>>>> at the end of this message),  and the resulting  native assembly,
>>>> generated with llc, will never  update my llvm_gc_root_chain  global.
>>>>
>>>> Interestingly, if I  build my runtime with g++, or clang  without
>>>> -emit-llvm, and link  everything together after generating  native
>>>> assembly from the  output of my compiler, it works.  The stack  roots get
>>>>  registered, and the llvm_gc_root_chain global gets  updated.
>>>>
>>>> Is linking in the runtime as an LLVM bitcode object something   that I
>>>> should expect to work, or does it make more sense to build  the  runtime
>>>> for the target, and not try to emit LLVM bitcode  programs from my  
>> compiler?
>>>>
>>>> Thanks!
>>>>
>>>>  --trevor
>>>>
>>>>
>>>> 0  libLLVM-2.8.so    0x0000003cc36eee9f
>>>> 1  libLLVM-2.8.so   0x0000003cc36ef99a
>>>> 2  libpthread.so.0  0x0000003cc200f4a0
>>>>  3  libLLVM-2.8.so   0x0000003cc33360dd
>>>>  llvm::StructType::StructType(llvm::LLVMContext&,   std::vector<llvm::Type
>>>> const*, std::allocator<llvm::Type  const*>  > const&, bool) + 237
>>>> 4   libLLVM-2.8.so   0x0000003cc3337c95
>>>>  llvm::StructType::get(llvm::LLVMContext&,  std::vector<llvm::Type  const*,
>>>> std::allocator<llvm::Type const*>  > const&,  bool) + 533
>>>> 5  libLLVM-2.8.so   0x0000003cc3242d58
>>>>  6  libLLVM-2.8.so  0x0000003cc318f09e
>>>> 7    libLLVM-2.8.so   0x0000003cc3330628
>>>>  llvm::FPPassManager::runOnFunction(llvm::Function&) +  424
>>>>  8  libLLVM-2.8.so   0x0000003cc33307cb
>>>>  llvm::FunctionPassManagerImpl::run(llvm::Function&) +  91
>>>>  9  libLLVM-2.8.so   0x0000003cc33309bd
>>>>  llvm::FunctionPassManager::run(llvm::Function&) +  173
>>>> 10  libLLVM-2.8.so   0x0000003cc33e8647
>>>>  llvm::JIT::jitTheFunction(llvm::Function*,  llvm::MutexGuard const&) +  39
>>>> 11 libLLVM-2.8.so   0x0000003cc33e8a2f
>>>>  llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*,   llvm::MutexGuard
>>>> const&) + 15
>>>> 12 libLLVM-2.8.so    0x0000003cc33e8cde
>>>> llvm::JIT::getPointerToFunction(llvm::Function*)  +  606
>>>> 13 libLLVM-2.8.so   0x0000003cc33ea253
>>>>  llvm::JIT::runFunction(llvm::Function*,   std::vector<llvm::GenericValue,
>>>>  std::allocator<llvm::GenericValue>  > const&) + 67
>>>> 14  libLLVM-2.8.so   0x0000003cc336ad4a
>>>>  llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
>>>>  std::vector<std::string,  std::allocator<std::string> >  const&, char
>>>> const* const*) +  1130
>>>> 15 lli              0x0000000000404cd6 main  + 2054
>>>> 16 libc.so.6         0x0000003cc1c1ec5d __libc_start_main + 253
>>>> 17 lli               0x0000000000403689
>>>> Stack dump:
>>>>  0.     Program arguments: lli test.bc
>>>> 1.    Running  pass 'Lower  Garbage Collection Instructions' on function 
>>> '@main'
>>>> zsh: segmentation fault  (core dumped)   ./test
>>>>
>>>>
>>>
>>>
>>>       
>>>
>>
>>
>>       
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3612 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110117/6dc2317d/attachment.bin 

From trevor at galois.com  Mon Jan 17 15:01:55 2011
From: trevor at galois.com (Trevor Elliott)
Date: Mon, 17 Jan 2011 13:01:55 -0800
Subject: [LLVMdev] Fw:  LLVM GC
In-Reply-To: <4D33E6D8.2030300@galois.com>
References: <4D30F5AA.1040106@galois.com>	<17226.12707.qm@web62004.mail.re1.yahoo.com>
	<4D33E6D8.2030300@galois.com>
Message-ID: <4D34AE43.8060701@galois.com>

Hi Everyone,

I've built a minimal test that exposes the problem that I'm encountering
[1].  The Makefile that it includes has two targets of interest,
test-llvm and test.

The test-llvm target will compile a c++ main using "clang -emit-llvm
-c", and link it with an llvm-assembly program that uses the
shadow-stack gc strategy.  The asm_main function will allocate 32 bytes
using malloc, and then register that as a gc root, using the llvm.gcroot
intrinsic.  It will then print the value of the llvm_gc_root_chain
global, and exit.

The test target will build the c++ main using "clang -c" producing
native code, then use llc and as to produce a native object from the
asm-main.bc bitcode file.  It then links everything together using clang
to produce a native executable called test.

The test-llvm target will produce the stack trace that I attached in a
previous message, while the test target produces a program that will
output a non-nil value for the llvm_gc_root_chain when run.
Disassembling test.bc using llvm-dis shows that everything has been
inlined into the @main function, though I'm not sure if this is actually
a problem.

Is there a reason that the test-llvm target isn't working?  I was under
the impression that the shadow-stack gc strategy was available when
using lli, though there certainly could be something wrong with the way
I'm putting all of the constituents together.

Thanks,

--trevor

[1] http://www.internetofdeath.com/~moltar/gc.tar.gz

On 01/16/2011 10:51 PM, Trevor Elliott wrote:
> Hi Sam,
> 
> I've not actually gotten to the linking process with my runtime, as I've
> compiled it with clang -emit-llvm -c, and then archived it with llvm-ar
> and llvm-ranlib.  I'm also not producing a GC plugin, as I'm using the
> builtin "shadow-stack" strategy.
> 
> My current build process looks like this:
> 
>  1. build the compiler
>  2. build the runtime using clang -emit-llvm -c
>  3. generate an archive from the runtime .bc files using llvm-ar and
> llvm-ranlib
>  3. compile a program with the compiler, producing a .bc file
>  4. link the program and runtime together using llvm-ld
>  5. run the program with lli
> 
> This all works fine until step 5 when the stack trace gets generated.
> The function that it complains about, @main, is the main function from
> my runtime.  When disassembled with llvm-dis, it doesn't have a gc
> attribute on the declaration.  Should it still be getting processed by
> the "shadow-stack" strategy?
> 
> Thanks!
> 
> --trevor
> 
> 
> On 01/14/2011 05:33 PM, Samuel Crow wrote:
>> Forgot to CC the list.
>>
>>
>> ----- Forwarded Message ----
>>> From: Samuel Crow <samuraileumas at yahoo.com>
>>> To: Trevor Elliott <trevor at galois.com>
>>> Sent: Fri, January 14, 2011 7:33:15 PM
>>> Subject: Re: [LLVMdev] LLVM GC
>>>
>>> Hi Trevor,
>>>
>>> Are you linking with LibStdC++ or LibC++?  That is a  requirement for running 
>>> code that has been compiled from C++ to  bitcode.
>>>
>>> Hope this helps,
>>>
>>> --Sam Crow
>>>
>>>
>>> ----- Original  Message ----
>>>> From: Trevor Elliott <trevor at galois.com>
>>>> To: llvmdev at cs.uiuc.edu
>>>> Sent: Fri,  January 14, 2011 7:17:30 PM
>>>> Subject: [LLVMdev] LLVM GC
>>>>
>>>>  Hi,
>>>>
>>>> I've been implementing a compiler that targets LLVM, and  was  looking
>>>> into using the shadow-stack gc strategy.   Currently, I build the  runtime
>>>> with clang (using -emit-llvm), and  then link that with the LLVM  bitcode
>>>> output from my compiler using  llvm-ld.
>>>>
>>>> This works fine without  the gc strategy  annotations and use of the
>>>> llvm.gcroot intrinsic, but adding  them  causes some odd behavior: the
>>>> resulting bitcode will generate a  large  stack trace from lli (appended
>>>> at the end of this message),  and the resulting  native assembly,
>>>> generated with llc, will never  update my llvm_gc_root_chain  global.
>>>>
>>>> Interestingly, if I  build my runtime with g++, or clang  without
>>>> -emit-llvm, and link  everything together after generating  native
>>>> assembly from the  output of my compiler, it works.  The stack  roots get
>>>>  registered, and the llvm_gc_root_chain global gets  updated.
>>>>
>>>> Is linking in the runtime as an LLVM bitcode object something   that I
>>>> should expect to work, or does it make more sense to build  the  runtime
>>>> for the target, and not try to emit LLVM bitcode  programs from my  
>> compiler?
>>>>
>>>> Thanks!
>>>>
>>>>  --trevor
>>>>
>>>>
>>>> 0  libLLVM-2.8.so    0x0000003cc36eee9f
>>>> 1  libLLVM-2.8.so   0x0000003cc36ef99a
>>>> 2  libpthread.so.0  0x0000003cc200f4a0
>>>>  3  libLLVM-2.8.so   0x0000003cc33360dd
>>>>  llvm::StructType::StructType(llvm::LLVMContext&,   std::vector<llvm::Type
>>>> const*, std::allocator<llvm::Type  const*>  > const&, bool) + 237
>>>> 4   libLLVM-2.8.so   0x0000003cc3337c95
>>>>  llvm::StructType::get(llvm::LLVMContext&,  std::vector<llvm::Type  const*,
>>>> std::allocator<llvm::Type const*>  > const&,  bool) + 533
>>>> 5  libLLVM-2.8.so   0x0000003cc3242d58
>>>>  6  libLLVM-2.8.so  0x0000003cc318f09e
>>>> 7    libLLVM-2.8.so   0x0000003cc3330628
>>>>  llvm::FPPassManager::runOnFunction(llvm::Function&) +  424
>>>>  8  libLLVM-2.8.so   0x0000003cc33307cb
>>>>  llvm::FunctionPassManagerImpl::run(llvm::Function&) +  91
>>>>  9  libLLVM-2.8.so   0x0000003cc33309bd
>>>>  llvm::FunctionPassManager::run(llvm::Function&) +  173
>>>> 10  libLLVM-2.8.so   0x0000003cc33e8647
>>>>  llvm::JIT::jitTheFunction(llvm::Function*,  llvm::MutexGuard const&) +  39
>>>> 11 libLLVM-2.8.so   0x0000003cc33e8a2f
>>>>  llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*,   llvm::MutexGuard
>>>> const&) + 15
>>>> 12 libLLVM-2.8.so    0x0000003cc33e8cde
>>>> llvm::JIT::getPointerToFunction(llvm::Function*)  +  606
>>>> 13 libLLVM-2.8.so   0x0000003cc33ea253
>>>>  llvm::JIT::runFunction(llvm::Function*,   std::vector<llvm::GenericValue,
>>>>  std::allocator<llvm::GenericValue>  > const&) + 67
>>>> 14  libLLVM-2.8.so   0x0000003cc336ad4a
>>>>  llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
>>>>  std::vector<std::string,  std::allocator<std::string> >  const&, char
>>>> const* const*) +  1130
>>>> 15 lli              0x0000000000404cd6 main  + 2054
>>>> 16 libc.so.6         0x0000003cc1c1ec5d __libc_start_main + 253
>>>> 17 lli               0x0000000000403689
>>>> Stack dump:
>>>>  0.     Program arguments: lli test.bc
>>>> 1.    Running  pass 'Lower  Garbage Collection Instructions' on function 
>>> '@main'
>>>> zsh: segmentation fault  (core dumped)   ./test
>>>>
>>>>
>>>
>>>
>>>       
>>>
>>
>>
>>       
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3612 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110117/62985a3b/attachment.bin 

From songlh at cs.wisc.edu  Mon Jan 17 16:37:51 2011
From: songlh at cs.wisc.edu (songlh at cs.wisc.edu)
Date: Mon, 17 Jan 2011 16:37:51 -0600
Subject: [LLVMdev] How to get the name and argument of a function
Message-ID: <89e0944507495fc8eb3f14dae3633306.squirrel@webmail.cs.wisc.edu>

Hi everyone:

   The code I am analyzing is :

   int main()
   {
       int i = 0;
       printf("hello world!");
       printf( "%d" , i );
   }



   I want to get each place where printf is called, and the argument used
during that call.

   so I write llvm pass code like:

   void Myfunction( Function & F){
       for( Function::iterator b = F.begin() , be = F.end() ;
        b != be; ++b){
           for(BasicBlock::iterator i = b.begin() , ie = b.end();
            i != ie; i ++){
               if( isa<CallInst>(&(*i)) || isa<InvokeInst>(&(*i))){
                   //how could I get the function name and argument
                   //used here
               }
           }

       }
   }


   How could I get the function name and the arguments when I know an
Instruction is a function call?

   thanks a lot!

   Best wishes!

                                                 Linhai Song


From echristo at apple.com  Mon Jan 17 16:48:44 2011
From: echristo at apple.com (Eric Christopher)
Date: Mon, 17 Jan 2011 14:48:44 -0800
Subject: [LLVMdev] About test suits Cont1
In-Reply-To: <AANLkTim+Jh+zp1jtXf-DiNHHrXnS-DBHBjoMzBbLSbXz@mail.gmail.com>
References: <AANLkTim+Jh+zp1jtXf-DiNHHrXnS-DBHBjoMzBbLSbXz@mail.gmail.com>
Message-ID: <CE34A964-A4B8-4151-B38D-72FE4ED972DB@apple.com>


On Jan 15, 2011, at 8:06 PM, Qingan Li wrote:

> [qali at qali llvm-2.8-rev]$ find . -exec grep -n "LLVMCC_EMITIR_FLAG" ./ {} \;
> ./projects/test-suite/Makefile.tests:47:	-$(LCC) $(CPPFLAGS) $(CFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:51:	-$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:55:	-$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:59:	-$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:63:	-$(LCC) $(CPPFLAGS) $(CFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:67:	-$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> 

I know this. The question I asked was to grep in your top level build directory. You a) searched all subdirectories, and b) in the source, not build directory.

> There are errors in config.log, but I need your help for clarifying them (I selected the first four errors below): 

These errors aren't even important. In order to figure out what your system has configure will attempt to compile a bunch of different programs.

You'll need to look for what is setting LLVMCC_EMITIR_FLAG and then debug from there.

-eric


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110117/9069b91e/attachment.html 

From nicholas at mxc.ca  Mon Jan 17 18:06:46 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 17 Jan 2011 16:06:46 -0800
Subject: [LLVMdev] How to get the name and argument of a function
In-Reply-To: <89e0944507495fc8eb3f14dae3633306.squirrel@webmail.cs.wisc.edu>
References: <89e0944507495fc8eb3f14dae3633306.squirrel@webmail.cs.wisc.edu>
Message-ID: <4D34D996.1030806@mxc.ca>

songlh at cs.wisc.edu wrote:
> Hi everyone:
>
>     The code I am analyzing is :
>
>     int main()
>     {
>         int i = 0;
>         printf("hello world!");
>         printf( "%d" , i );
>     }
>
>
>
>     I want to get each place where printf is called, and the argument used
> during that call.
>
>     so I write llvm pass code like:
>
>     void Myfunction( Function&  F){
>         for( Function::iterator b = F.begin() , be = F.end() ;
>          b != be; ++b){
>             for(BasicBlock::iterator i = b.begin() , ie = b.end();
>              i != ie; i ++){
>                 if( isa<CallInst>(&(*i)) || isa<InvokeInst>(&(*i))){
>                     //how could I get the function name and argument
>                     //used here
>                 }
>             }
>
>         }
>     }
>
>
>     How could I get the function name and the arguments when I know an
> Instruction is a function call?

There's a worked example at 
http://wiki.llvm.org/HowTo:_Find_all_call_sites_of_a_function .

With the CallInst/InvokeInst you can query getArgOperand() to get the 
arguments or getCallee() which return a Function -- or it might not. If 
the call is an indirect call (ie., function pointer) then you don't know 
what it's calling. Ignoring indirect calls, you can call getName() on a 
function to get its name.

Personally, I rely heavily on the doxygen to find my way around the API: 
http://llvm.org/doxygen/hierarchy.html . Look up "CallInst" for example. 
The getName() method isn't on Function, but all the way on the base 
class Value.

Nick

>
>     thanks a lot!
>
>     Best wishes!
>
>                                                   Linhai Song
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From rob.nikander at gmail.com  Mon Jan 17 19:01:09 2011
From: rob.nikander at gmail.com (Rob Nikander)
Date: Mon, 17 Jan 2011 20:01:09 -0500
Subject: [LLVMdev] compiling a call to function in compiler
Message-ID: <AANLkTi=Q2dJrBACY+HNVyGAbwsjZ7Hf-JBpxqn8KS1h4@mail.gmail.com>

Hi,

I'm trying to follow the advice from this message:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-October/017574.html,
to create a call instruction from a function pointer.  But I'm
getting...

   Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of
incompatible type!"),
   function cast, file /usr/local/include/llvm/Support/Casting.h, line 202.

Code snippets...

    id testfunc(id a, id b) { ... }
    ...
    FunctionType *fn_type = FunctionType::get(id_type, argtypes, false);	
    Value *fn = ConstantExpr::getIntToPtr(ConstantInt::get(int64_type,
reinterpret_cast<int64_t>(testfunc)), fn_type);
    return builder.CreateCall2(fn, arg0val, arg1val);   // <--
assertion fails here

What am I doing wrong?  I can paste more code if needed.

thanks,
Rob

From echristo at apple.com  Mon Jan 17 19:36:39 2011
From: echristo at apple.com (Eric Christopher)
Date: Mon, 17 Jan 2011 17:36:39 -0800
Subject: [LLVMdev] compiling a call to function in compiler
In-Reply-To: <AANLkTi=Q2dJrBACY+HNVyGAbwsjZ7Hf-JBpxqn8KS1h4@mail.gmail.com>
References: <AANLkTi=Q2dJrBACY+HNVyGAbwsjZ7Hf-JBpxqn8KS1h4@mail.gmail.com>
Message-ID: <164301D5-D783-4F08-B3C3-E8800A134B81@apple.com>


On Jan 17, 2011, at 5:01 PM, Rob Nikander wrote:

> Hi,
> 
> I'm trying to follow the advice from this message:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-October/017574.html,
> to create a call instruction from a function pointer.  But I'm
> getting...
> 
>   Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of
> incompatible type!"),
>   function cast, file /usr/local/include/llvm/Support/Casting.h, line 202.
> 
> Code snippets...
> 
>    id testfunc(id a, id b) { ... }
>    ...
>    FunctionType *fn_type = FunctionType::get(id_type, argtypes, false);	
>    Value *fn = ConstantExpr::getIntToPtr(ConstantInt::get(int64_type,
> reinterpret_cast<int64_t>(testfunc)), fn_type);
>    return builder.CreateCall2(fn, arg0val, arg1val);   // <--
> assertion fails here
> 
> What am I doing wrong?  I can paste more code if needed.

One of the types doesn't match the types of what you are trying to pass.

You should debug which one it is and why the types aren't matching what
you think they should be.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110117/aefb7e2e/attachment.html 

From rob.nikander at gmail.com  Mon Jan 17 20:03:59 2011
From: rob.nikander at gmail.com (Rob Nikander)
Date: Mon, 17 Jan 2011 21:03:59 -0500
Subject: [LLVMdev] compiling a call to function in compiler
In-Reply-To: <164301D5-D783-4F08-B3C3-E8800A134B81@apple.com>
References: <AANLkTi=Q2dJrBACY+HNVyGAbwsjZ7Hf-JBpxqn8KS1h4@mail.gmail.com>
	<164301D5-D783-4F08-B3C3-E8800A134B81@apple.com>
Message-ID: <AANLkTimvDpW9hO=0w7gq0NNrZMpN_Si-oUH=AAeB2H5e@mail.gmail.com>

On Mon, Jan 17, 2011 at 8:36 PM, Eric Christopher <echristo at apple.com> wrote:
>
> ???id testfunc(id a, id b) { ... }
> ???...
> ???FunctionType *fn_type = FunctionType::get(id_type, argtypes, false);
> ???Value *fn = ConstantExpr::getIntToPtr(ConstantInt::get(int64_type,
> reinterpret_cast<int64_t>(testfunc)), fn_type);
> ???return builder.CreateCall2(fn, arg0val, arg1val); ??// <--
> assertion fails here
>
> What am I doing wrong? ?I can paste more code if needed.
>
> One of the types doesn't match the types of what you are trying to pass.
> You should debug which one it is and why the types aren't matching what
> you think they should be.

Okay, found it.  My function was of type: "i8* (i8*, i8*)".  I thought
that was okay, but now I see it needed to be "i8* (i8*, i8*)*" -- ie,
a pointer to the former type.

Rob


From echristo at apple.com  Mon Jan 17 20:07:00 2011
From: echristo at apple.com (Eric Christopher)
Date: Mon, 17 Jan 2011 18:07:00 -0800
Subject: [LLVMdev] compiling a call to function in compiler
In-Reply-To: <AANLkTimvDpW9hO=0w7gq0NNrZMpN_Si-oUH=AAeB2H5e@mail.gmail.com>
References: <AANLkTi=Q2dJrBACY+HNVyGAbwsjZ7Hf-JBpxqn8KS1h4@mail.gmail.com>
	<164301D5-D783-4F08-B3C3-E8800A134B81@apple.com>
	<AANLkTimvDpW9hO=0w7gq0NNrZMpN_Si-oUH=AAeB2H5e@mail.gmail.com>
Message-ID: <D24BCDAA-208F-47D9-A0AC-A6DC15E1A877@apple.com>


On Jan 17, 2011, at 6:03 PM, Rob Nikander wrote:

> On Mon, Jan 17, 2011 at 8:36 PM, Eric Christopher <echristo at apple.com> wrote:
>> 
>>    id testfunc(id a, id b) { ... }
>>    ...
>>    FunctionType *fn_type = FunctionType::get(id_type, argtypes, false);
>>    Value *fn = ConstantExpr::getIntToPtr(ConstantInt::get(int64_type,
>> reinterpret_cast<int64_t>(testfunc)), fn_type);
>>    return builder.CreateCall2(fn, arg0val, arg1val);   // <--
>> assertion fails here
>> 
>> What am I doing wrong?  I can paste more code if needed.
>> 
>> One of the types doesn't match the types of what you are trying to pass.
>> You should debug which one it is and why the types aren't matching what
>> you think they should be.
> 
> Okay, found it.  My function was of type: "i8* (i8*, i8*)".  I thought
> that was okay, but now I see it needed to be "i8* (i8*, i8*)*" -- ie,
> a pointer to the former type.

Ah. excellent.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110117/3a1da53e/attachment.html 

From songlh at cs.wisc.edu  Mon Jan 17 20:53:46 2011
From: songlh at cs.wisc.edu (songlh at cs.wisc.edu)
Date: Mon, 17 Jan 2011 20:53:46 -0600
Subject: [LLVMdev] How to get the name and argument of a function
In-Reply-To: <4D34D996.1030806@mxc.ca>
References: <89e0944507495fc8eb3f14dae3633306.squirrel@webmail.cs.wisc.edu>
	<4D34D996.1030806@mxc.ca>
Message-ID: <7221226ddb884b77fdf4c4525421299c.squirrel@webmail.cs.wisc.edu>

Thanks a lot!

I can get the call place now. But still have problems in getting the
argument.

CallInst * pCall;

......

pCall->getArgOperand(0)->dump();

I can get "i8* getelementptr inbounds ([5 x i8]* @.str, i32 0, i32 0)"

I think this means that the variable is a global constant string. Do you
know how to get the name of this global string, and how to use the name to
get the string value?

Btw: when I use pCall->getArgOperand(0)->getName(), I can only get "".

thanks a lot!

Linhai

> songlh at cs.wisc.edu wrote:
>> Hi everyone:
>>
>>     The code I am analyzing is :
>>
>>     int main()
>>     {
>>         int i = 0;
>>         printf("hello world!");
>>         printf( "%d" , i );
>>     }
>>
>>
>>
>>     I want to get each place where printf is called, and the argument
>> used
>> during that call.
>>
>>     so I write llvm pass code like:
>>
>>     void Myfunction( Function&  F){
>>         for( Function::iterator b = F.begin() , be = F.end() ;
>>          b != be; ++b){
>>             for(BasicBlock::iterator i = b.begin() , ie = b.end();
>>              i != ie; i ++){
>>                 if( isa<CallInst>(&(*i)) || isa<InvokeInst>(&(*i))){
>>                     //how could I get the function name and argument
>>                     //used here
>>                 }
>>             }
>>
>>         }
>>     }
>>
>>
>>     How could I get the function name and the arguments when I know an
>> Instruction is a function call?
>
> There's a worked example at
> http://wiki.llvm.org/HowTo:_Find_all_call_sites_of_a_function .
>
> With the CallInst/InvokeInst you can query getArgOperand() to get the
> arguments or getCallee() which return a Function -- or it might not. If
> the call is an indirect call (ie., function pointer) then you don't know
> what it's calling. Ignoring indirect calls, you can call getName() on a
> function to get its name.
>
> Personally, I rely heavily on the doxygen to find my way around the API:
> http://llvm.org/doxygen/hierarchy.html . Look up "CallInst" for example.
> The getName() method isn't on Function, but all the way on the base
> class Value.
>
> Nick
>
>>
>>     thanks a lot!
>>
>>     Best wishes!
>>
>>                                                   Linhai Song
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>



From ww345ww at gmail.com  Mon Jan 17 21:38:22 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Tue, 18 Jan 2011 11:38:22 +0800
Subject: [LLVMdev] About test suits Cont1
In-Reply-To: <CE34A964-A4B8-4151-B38D-72FE4ED972DB@apple.com>
References: <AANLkTim+Jh+zp1jtXf-DiNHHrXnS-DBHBjoMzBbLSbXz@mail.gmail.com>
	<CE34A964-A4B8-4151-B38D-72FE4ED972DB@apple.com>
Message-ID: <AANLkTikSwsD02Fk77KamACGWZx-tTFgJ36iE7oBKRjAP@mail.gmail.com>

*1. I have searched the access/setting of LLVMCC_EMITIR_FLAG in the build
directory, recursively, and all the output is what I pasted in last email
(just the same to the that in source directory). Maybe the configure failed
to do it. My command list for building the test suit is as followings:*
*(1) cd ~/SRC_DIR/llvm/projects*
*(2) svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite*
*(3) cd LLVMGCC_DIR;       *
***(4) gunzip --stdout llvm-gcc-4.2-version-platform.tar.gz | tar -xvf -*
*(5) cd ~/OBJ_DIR/llvm; *
*(6) SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime
 --disable-optimized --enable-debug-symbols --enable-assertions *
  --with-llvmgccdir=LLVMGCC_DIR
(7) search LLVMCC_EMITIR_FLAG or "cd projects/test-suite" (both failed)

*2. Another question*
*In the steps above, I omitted the re-configure process in
http://llvm.org/docs/TestingGuide.html#testsuiterun **, since I thought I
have configured the $LLVM_GCC_DIR before building llvm.*

*As it failed, I did the following to reconfigure, but it failed again:*
(8) cd OBJ_DIR/llvm/
(9) *SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime
 --disable-optimized --enable-debug-symbols --enable-assertions *
  --with-llvmgccdir=LLVMGCC_DIR

I need your help, and thanks very much for your time.

2011/1/18 Eric Christopher <echristo at apple.com>

>
> On Jan 15, 2011, at 8:06 PM, Qingan Li wrote:
>
> [qali at qali llvm-2.8-rev]$ find . -exec grep -n "LLVMCC_EMITIR_FLAG" ./ {}
> \;
> ./projects/test-suite/Makefile.tests:47: -$(LCC) $(CPPFLAGS) $(CFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:51: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:55: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:59: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:63: -$(LCC) $(CPPFLAGS) $(CFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:67: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
>
>
> I know this. The question I asked was to grep in your top level build
> directory. You a) searched all subdirectories, and b) in the source, not
> build directory.
>
> There are errors in config.log, but I need your help for clarifying them (I
> selected the first four errors below):
>
>
> These errors aren't even important. In order to figure out what your system
> has configure will attempt to compile a bunch of different programs.
>
> You'll need to look for what is setting LLVMCC_EMITIR_FLAG and then debug
> from there.
>
> -eric
>
>
>


-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110118/9937acc3/attachment.html 

From ww345ww at gmail.com  Mon Jan 17 22:44:05 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Tue, 18 Jan 2011 12:44:05 +0800
Subject: [LLVMdev] adding a codegen pass into llvm
Message-ID: <AANLkTindp2=azG-k+fh=FODSgz37OFyYO58XbEXJJqgq@mail.gmail.com>

Thanks for your last reply.
Could I understand the way to adding a pass (built into the llvm rather than
dynamic loadable) includes:
1. Declaring a creator function for this pass
2. Implementing the creator function for this pass
3. Instantiating this pass and get a object of it
3. Register this pass into the PassRegistry

Then, for a built-into bytecode pass,
        task 1(declaration of the creator) should be done in Scalar.h;
        task 2(implementation of the creator) should be done the related
mypass.cpp file;
        task 3(instantiation of the pass class) should be done in
LinkAllPasses.h;
        task 4(registration of the pass into the PassRegistry) should be
done by INITIALIZE_PASS
class LiveVariables : public MachineFunctionPass is a case of point.

For a built-into codegen/MachineCode pass,
        task 1 should be done in Passes.h;
        task 2 should be done in the related mypass.cpp file;
        task 3 should be done in LLVMTargetMachine.cpp
        task 4 should be done by INITIALIZE_PASS
 class IntervalAnalylsis: public MachineFunctionPass is a case in point.

I have implemented a new mypass (just for analysis, rather than
transformation) as a subclass of MchineFunctionPass, and finished task 1, 2,
4. But I don't know how to finish task 3, since I failed to make clear how
the class IntervalAnalysis did task 3. So I need your help.

-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110118/a65fa139/attachment.html 

From nicholas at mxc.ca  Tue Jan 18 02:32:57 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 18 Jan 2011 00:32:57 -0800
Subject: [LLVMdev] induction variable computation not preserving scev
Message-ID: <AANLkTinqt1mBGv0aUjUkADOC6CEQsgXUH=iyvm-URMfB@mail.gmail.com>

Hi,

I tracked down a bug in indvars where we weren't updating SCEV properly. The
attached patch shows the fix to this bug with a testcase, but it also causes
five new test failures.

Would someone be willing to take a look at the failures and figure out why
we're getting worse output once this patch is applied? If I had to hazard a
guess, I'd say that indvars is probably emitting code that can't be analyzed
by SCEV as easily as the original.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110118/d41d3189/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: indvars.patch
Type: text/x-patch
Size: 2350 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110118/d41d3189/attachment.bin 

From jdkunk3 at gmail.com  Tue Jan 18 07:56:09 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Tue, 18 Jan 2011 08:56:09 -0500
Subject: [LLVMdev] adding a codegen pass into llvm
In-Reply-To: <AANLkTindp2=azG-k+fh=FODSgz37OFyYO58XbEXJJqgq@mail.gmail.com>
References: <AANLkTindp2=azG-k+fh=FODSgz37OFyYO58XbEXJJqgq@mail.gmail.com>
Message-ID: <AANLkTimJVozhq1Absk5RPa5hwYbUN9Rrbbh0R0nEXACR@mail.gmail.com>

I have created a few codegen passes, and there are quite a few steps to
them. Here is how I would sum up the steps.

1. In the cpp file, put the initilize pass macros:

INITIALIZE_PASS_BEGIN(MyPassName, "a-short-space-free-description",
  "A long description", true, true)
INITIALIZE_PASS_DEPENDENCY(MachineLoopInfo)
INITIALIZE_PASS_END(MyPassName, "a-short-space-free-description",
  "A long description", true, true)

2. Create the class with the pass dependencies noted in the constructor.

class MyPassName: public MachineFunctionPass {
public:
  static char ID;
  MyPassName() {
    llvm::initializeMachineLoopInfoPass(*PassRegistry::getPassRegistry());
  }
  virtual bool runOnMachineFunction(MachineFunction &mf);
  virtual void getAnalysisUsage(AnalysisUsage &AU) const;
  virtual void releaseMemory();
};
char CodegenPass ::ID = 0;

3. Create an initilization function for you pass in Passes.h, and please
note the concatenation of the pass name in the center of initialize and
Pass.
"void initializeMyPassNamePass(PassRegistry &Registry);"

4. If your class is not instantiated in a header, then place an "extern char
& MyPassNameID;" into passes.h so other passes can find it's dependencies.

5. I am not 100% sure this is necessary, but I do it anyway to be sure. In
CodeGen.cpp, place "initializeMyPassNamePass(Registry);" in the
"initializeCodeGen" function. It may be possible to use opt, but I have not
tired it.

6. The "LinkAllPasses.h" is more important if you are overriding the
Dag-Scheduler or Register allocator or some other important, ever present
pass. For a regular pass, other passes will call
the initializeMyPassNamePass, and other passes will use Analytical usage to
run it.

7. This is the hardest part. Find out where in this long chain of
CodeGen dependencies you can place your pass. If you want to do a pass
before register allocation, you may have to add some Analytical usage fields
to the first reg-alloc pass which is really SlotIndexes. Perhaps you can put
something in between other passes, but it's difficult. The dependencies are
such that I have found it difficult to place a simple analysis pass between
some steps.

- Writing a codegen pass by,
Jeff Kunkel

On Mon, Jan 17, 2011 at 11:44 PM, Qingan Li <ww345ww at gmail.com> wrote:

> Thanks for your last reply.
> Could I understand the way to adding a pass (built into the llvm rather
> than
> dynamic loadable) includes:
> 1. Declaring a creator function for this pass
> 2. Implementing the creator function for this pass
> 3. Instantiating this pass and get a object of it
> 3. Register this pass into the PassRegistry
>
> Then, for a built-into bytecode pass,
>         task 1(declaration of the creator) should be done in Scalar.h;
>         task 2(implementation of the creator) should be done the related
> mypass.cpp file;
>         task 3(instantiation of the pass class) should be done in
> LinkAllPasses.h;
>         task 4(registration of the pass into the PassRegistry) should be
> done by INITIALIZE_PASS
> class LiveVariables : public MachineFunctionPass is a case of point.
>
> For a built-into codegen/MachineCode pass,
>         task 1 should be done in Passes.h;
>         task 2 should be done in the related mypass.cpp file;
>         task 3 should be done in LLVMTargetMachine.cpp
>         task 4 should be done by INITIALIZE_PASS
>  class IntervalAnalylsis: public MachineFunctionPass is a case in point.
>
> I have implemented a new mypass (just for analysis, rather than
> transformation) as a subclass of MchineFunctionPass, and finished task 1,
> 2,
> 4. But I don't know how to finish task 3, since I failed to make clear how
> the class IntervalAnalysis did task 3. So I need your help.
>
> --
> Best regards,
>
> Li Qingan
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110118/352c16ef/attachment-0001.html 

From baldrick at free.fr  Tue Jan 18 08:47:06 2011
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 18 Jan 2011 15:47:06 +0100
Subject: [LLVMdev] File reading in LLVM 2.8
In-Reply-To: <AANLkTi=o1+oDDSFcVcoyvpUmFNOgcYvW83qKOLhtQU09@mail.gmail.com>
References: <AANLkTi=xX0-xxLM-=ZUzN0vM+R5+_9rox7htna9GV-Zb@mail.gmail.com>	<4D3407CC.8010102@free.fr>
	<AANLkTi=o1+oDDSFcVcoyvpUmFNOgcYvW83qKOLhtQU09@mail.gmail.com>
Message-ID: <4D35A7EA.8080305@free.fr>

Hi Abhirup, please reply to the mailing list and not just to me personally
(that way others can answer too, and the discussion is archived which helps
other people with the same problem).

> How to compile with -fPIC? I am new to llvm so can you please elaborate?

This has nothing to do with LLVM: -fPIC is a gcc option needed to build code
that is to be part of a dynamic library.  So just add it to the other options
you use when compiling your program.

Best wishes,

Duncan.

>
> Abhirup Ghosh
> M. Tech
> Department of Computer Science&  Engg.
> IIT, Bombay
> email - abhirupju at gmail.com , abhirup at cse.iitb.ac.in
>
>
>
> On Mon, Jan 17, 2011 at 2:41 PM, Duncan Sands<baldrick at free.fr>  wrote:
>> Hi Abhirup,
>>
>> `(anonymous
>>> namespace)::Hello::update_sec_read(char const*)' can not be used when
>>> making a shared object; recompile with -fPIC
>>
>> did you compile it with -fPIC ?
>>
>> Ciao, Duncan.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>


From kd at kendyck.com  Tue Jan 18 09:01:42 2011
From: kd at kendyck.com (Ken Dyck)
Date: Tue, 18 Jan 2011 10:01:42 -0500
Subject: [LLVMdev] Dwarf info for byref register variables
Message-ID: <AANLkTimQx2DHonuv+cwG5HUQLRVSi3OHC3_Bb8nroFzZ@mail.gmail.com>

Two functions in DwarfDebug, addBlockByrefAddress() and
addComplexAddress(), contain this snippet of code:

  // Decode the original location, and use that as the start of the byref
  // variable's location.
  const TargetRegisterInfo *RI = Asm->TM.getRegisterInfo();
  unsigned Reg = RI->getDwarfRegNum(Location.getReg(), false);
  DIEBlock *Block = new (DIEValueAllocator) DIEBlock();

  if (Location.isReg()) {
    if (Reg < 32)
      addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_reg0 + Reg);
    else {
      Reg = Reg - dwarf::DW_OP_reg0;
      addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_breg0 + Reg);
      addUInt(Block, 0, dwarf::DW_FORM_udata, Reg);
    }
  } else {
    if (Reg < 32)
      addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_breg0 + Reg);
    else {
      addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_bregx);
      addUInt(Block, 0, dwarf::DW_FORM_udata, Reg);
    }

    addUInt(Block, 0, dwarf::DW_FORM_sdata, Location.getOffset());
  }

What's going on in the 'else' block of the first nested 'if' (where
Location.isReg() && Reg >=32)? It looks wrong to me.

If you expand out the opcode parameter, you get:

  Opcode = DW_OP_breg0 + Reg
         = DW_OP_breg0 + (RegOriginal - DW_OP_reg0)
         = RegOriginal + (DW_OP_breg0 - DW_OP_reg0)
         = RegOriginal + (0x70 - 0x50)
         = RegOriginal + 0x20
         = RegOriginal + DW_OP_not

Since we know that RegOriginal >= 32, the opcode that gets generated
is one that has a value >= 0x40, which is DW_OP_lit16.

There is a very similar snippet in the addAddress() function. It uses
the DW_OP_regx opcode to encode the register number:

  // ...
  if (Location.isReg()) {
    if (Reg < 32) {
      addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_reg0 + Reg);
    } else {
      addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_regx);
      addUInt(Block, 0, dwarf::DW_FORM_udata, Reg);
    }
  } else {
  // ...

Should addBlockByrefAddress() and addComplexAddress() be doing the same?

-Ken

From dpatel at apple.com  Tue Jan 18 12:03:24 2011
From: dpatel at apple.com (Devang Patel)
Date: Tue, 18 Jan 2011 10:03:24 -0800
Subject: [LLVMdev] Dwarf info for byref register variables
In-Reply-To: <AANLkTimQx2DHonuv+cwG5HUQLRVSi3OHC3_Bb8nroFzZ@mail.gmail.com>
References: <AANLkTimQx2DHonuv+cwG5HUQLRVSi3OHC3_Bb8nroFzZ@mail.gmail.com>
Message-ID: <F9E845A1-2C06-4AF2-B7E2-9302AF2CE6ED@apple.com>


On Jan 18, 2011, at 7:01 AM, Ken Dyck wrote:

> Should addBlockByrefAddress() and addComplexAddress() be doing the same?

Yes. Can you prepare a patch ?
Thanks,
-
Devang

From king19880326 at gmail.com  Tue Jan 18 12:28:48 2011
From: king19880326 at gmail.com (Lu Mitnick)
Date: Wed, 19 Jan 2011 02:28:48 +0800
Subject: [LLVMdev] Question about porting LLVM - a single instruction op
 mnemonic with multiple operand forms
Message-ID: <AANLkTi=Dw2SPyMUGSH-ztNUfM+pReP0cr=zuUPFCGBr5@mail.gmail.com>

Hello all,

I am at the adding Instruction Set stage of adding new target support into
LLVM. There is a single instruction op mnemonic with multiple operand forms.
For example: Add R1, R2 & Add @R1, R2. I found that there is similar case in
x86 instruction set, such like ADD reg, reg & ADD mem, reg. However, the
solution of x86 is adding suffix of instruction and translating instruction
op mnemonic into ADDrr & ADDmr. I don't want to translate single instruction
op mnemonic with different operand forms into multiple op mnemonics. I am
wondering to know whether is another solution of this problem or not?? Which
target should I look for it??

thanks a lot

yi-hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110119/de8cd4b8/attachment.html 

From kd at kendyck.com  Tue Jan 18 12:47:43 2011
From: kd at kendyck.com (Ken Dyck)
Date: Tue, 18 Jan 2011 13:47:43 -0500
Subject: [LLVMdev] Dwarf info for byref register variables
In-Reply-To: <F9E845A1-2C06-4AF2-B7E2-9302AF2CE6ED@apple.com>
References: <AANLkTimQx2DHonuv+cwG5HUQLRVSi3OHC3_Bb8nroFzZ@mail.gmail.com>
	<F9E845A1-2C06-4AF2-B7E2-9302AF2CE6ED@apple.com>
Message-ID: <AANLkTi=q8bzAv6C_8EA0SfWLpX3+OprCqAYgrUc3UCNu@mail.gmail.com>

On Tue, Jan 18, 2011 at 1:03 PM, Devang Patel <dpatel at apple.com> wrote:
> On Jan 18, 2011, at 7:01 AM, Ken Dyck wrote:
>
>> Should addBlockByrefAddress() and addComplexAddress() be doing the same?
>
> Yes. Can you prepare a patch ?

Sure. Attached.

-Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DwarfDebug-byref.register.vars.diff
Type: text/x-patch
Size: 983 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110118/0b04a5f5/attachment.bin 

From Micah.Villmow at amd.com  Tue Jan 18 12:50:00 2011
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Tue, 18 Jan 2011 12:50:00 -0600
Subject: [LLVMdev] Question about porting LLVM - a single instruction op
 mnemonic with multiple operand forms
In-Reply-To: <AANLkTi=Dw2SPyMUGSH-ztNUfM+pReP0cr=zuUPFCGBr5@mail.gmail.com>
References: <AANLkTi=Dw2SPyMUGSH-ztNUfM+pReP0cr=zuUPFCGBr5@mail.gmail.com>
Message-ID: <D556DCBBC0EA924A9AC80003B621211205FBD28DA6@sausexmbp02.amd.com>

I have this same problem in our backend. I solve it by adding a pseudo instruction at instruction selection that transforms @R1 into R1, so only a single pattern is required. I then can propogate the pseudo instruction after instruction selection.

Micah

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lu Mitnick
Sent: Tuesday, January 18, 2011 10:29 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Question about porting LLVM - a single instruction op mnemonic with multiple operand forms

Hello all,

I am at the adding Instruction Set stage of adding new target support into LLVM. There is a single instruction op mnemonic with multiple operand forms. For example: Add R1, R2 & Add @R1, R2. I found that there is similar case in x86 instruction set, such like ADD reg, reg & ADD mem, reg. However, the solution of x86 is adding suffix of instruction and translating instruction op mnemonic into ADDrr & ADDmr. I don't want to translate single instruction op mnemonic with different operand forms into multiple op mnemonics. I am wondering to know whether is another solution of this problem or not?? Which target should I look for it??

thanks a lot

yi-hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110118/4adb591a/attachment.html 

From king19880326 at gmail.com  Tue Jan 18 13:48:06 2011
From: king19880326 at gmail.com (Lu Mitnick)
Date: Wed, 19 Jan 2011 03:48:06 +0800
Subject: [LLVMdev] Question about porting LLVM - a single instruction op
 mnemonic with multiple operand forms
In-Reply-To: <D556DCBBC0EA924A9AC80003B621211205FBD28DA6@sausexmbp02.amd.com>
References: <AANLkTi=Dw2SPyMUGSH-ztNUfM+pReP0cr=zuUPFCGBr5@mail.gmail.com>
	<D556DCBBC0EA924A9AC80003B621211205FBD28DA6@sausexmbp02.amd.com>
Message-ID: <AANLkTi=q0rHZ3ZFcjK1Ky6Qs6KPjo0eDNGKvhfQn-oY2@mail.gmail.com>

Hello Villmow,

Is it your backend EFI Byte Code Virtual Machine?? Would you mind to give me
an example about what pseudo instruction you add??

thanks a lot

yi-hong

2011/1/19 Villmow, Micah <Micah.Villmow at amd.com>

> I have this same problem in our backend. I solve it by adding a pseudo
> instruction at instruction selection that transforms @R1 into R1, so only a
> single pattern is required. I then can propogate the pseudo instruction
> after instruction selection.
>
>
>
> Micah
>
>
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On
> Behalf Of *Lu Mitnick
> *Sent:* Tuesday, January 18, 2011 10:29 AM
> *To:* llvmdev at cs.uiuc.edu
> *Subject:* [LLVMdev] Question about porting LLVM - a single instruction op
> mnemonic with multiple operand forms
>
>
>
> Hello all,
>
>
>
> I am at the adding Instruction Set stage of adding new target support into
> LLVM. There is a single instruction op mnemonic with multiple operand forms.
> For example: Add R1, R2 & Add @R1, R2. I found that there is similar case in
> x86 instruction set, such like ADD reg, reg & ADD mem, reg. However, the
> solution of x86 is adding suffix of instruction and translating instruction
> op mnemonic into ADDrr & ADDmr. I don't want to translate single instruction
> op mnemonic with different operand forms into multiple op mnemonics. I am
> wondering to know whether is another solution of this problem or not?? Which
> target should I look for it??
>
>
>
> thanks a lot
>
>
>
> yi-hong
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110119/0288d06c/attachment.html 

From Micah.Villmow at amd.com  Tue Jan 18 13:58:00 2011
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Tue, 18 Jan 2011 13:58:00 -0600
Subject: [LLVMdev] Question about porting LLVM - a single instruction op
 mnemonic with multiple operand forms
In-Reply-To: <AANLkTi=q0rHZ3ZFcjK1Ky6Qs6KPjo0eDNGKvhfQn-oY2@mail.gmail.com>
References: <AANLkTi=Dw2SPyMUGSH-ztNUfM+pReP0cr=zuUPFCGBr5@mail.gmail.com>
	<D556DCBBC0EA924A9AC80003B621211205FBD28DA6@sausexmbp02.amd.com>
	<AANLkTi=q0rHZ3ZFcjK1Ky6Qs6KPjo0eDNGKvhfQn-oY2@mail.gmail.com>
Message-ID: <D556DCBBC0EA924A9AC80003B621211205FBD28DC0@sausexmbp02.amd.com>

The backend is for AMDIL
I have a simple pattern that loads all immediate values to registers first and that way no instruction patterns need duplicate forms for both registers and immediates.

Micah

From: Lu Mitnick [mailto:king19880326 at gmail.com]
Sent: Tuesday, January 18, 2011 11:48 AM
To: Villmow, Micah
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Question about porting LLVM - a single instruction op mnemonic with multiple operand forms

Hello Villmow,

Is it your backend EFI Byte Code Virtual Machine?? Would you mind to give me an example about what pseudo instruction you add??

thanks a lot

yi-hong

2011/1/19 Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>>
I have this same problem in our backend. I solve it by adding a pseudo instruction at instruction selection that transforms @R1 into R1, so only a single pattern is required. I then can propogate the pseudo instruction after instruction selection.

Micah

From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu>] On Behalf Of Lu Mitnick
Sent: Tuesday, January 18, 2011 10:29 AM
To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: [LLVMdev] Question about porting LLVM - a single instruction op mnemonic with multiple operand forms

Hello all,

I am at the adding Instruction Set stage of adding new target support into LLVM. There is a single instruction op mnemonic with multiple operand forms. For example: Add R1, R2 & Add @R1, R2. I found that there is similar case in x86 instruction set, such like ADD reg, reg & ADD mem, reg. However, the solution of x86 is adding suffix of instruction and translating instruction op mnemonic into ADDrr & ADDmr. I don't want to translate single instruction op mnemonic with different operand forms into multiple op mnemonics. I am wondering to know whether is another solution of this problem or not?? Which target should I look for it??

thanks a lot

yi-hong

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110118/96f10efb/attachment.html 

From grosbach at apple.com  Tue Jan 18 15:32:08 2011
From: grosbach at apple.com (Jim Grosbach)
Date: Tue, 18 Jan 2011 13:32:08 -0800
Subject: [LLVMdev] Question about porting LLVM - a single instruction op
	mnemonic with multiple operand forms
In-Reply-To: <AANLkTi=Dw2SPyMUGSH-ztNUfM+pReP0cr=zuUPFCGBr5@mail.gmail.com>
References: <AANLkTi=Dw2SPyMUGSH-ztNUfM+pReP0cr=zuUPFCGBr5@mail.gmail.com>
Message-ID: <45455191-0F3E-4BE4-BFC6-8712EDC455F0@apple.com>

Hello,

Having separate instruction patterns, one per encoding, is the correct answer. They are not the same instruction, from LLVM's perspective, even though they share the same mnemonic. X86 is doing things the right way for this.

Consider that the instruction printing, instruction selection (isel pattern), and binary encoding will all need to do things differently depending on the types of the operands. Likewise, the scheduling itinerary will almost certainly be different (memory vs. register). That's best handled by having separate instruction definitions.

-Jim


On Jan 18, 2011, at 10:28 AM, Lu Mitnick wrote:

> Hello all,
> 
> I am at the adding Instruction Set stage of adding new target support into LLVM. There is a single instruction op mnemonic with multiple operand forms. For example: Add R1, R2 & Add @R1, R2. I found that there is similar case in x86 instruction set, such like ADD reg, reg & ADD mem, reg. However, the solution of x86 is adding suffix of instruction and translating instruction op mnemonic into ADDrr & ADDmr. I don't want to translate single instruction op mnemonic with different operand forms into multiple op mnemonics. I am wondering to know whether is another solution of this problem or not?? Which target should I look for it??
> 
> thanks a lot
> 
> yi-hong
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From grosbach at apple.com  Tue Jan 18 15:34:13 2011
From: grosbach at apple.com (Jim Grosbach)
Date: Tue, 18 Jan 2011 13:34:13 -0800
Subject: [LLVMdev] clang/LLVM cross testing environment
In-Reply-To: <4D341A34.3000109@pennware.com>
References: <4D341A34.3000109@pennware.com>
Message-ID: <3A98D054-41E5-48CF-BA83-F2CE8B7FDF1C@apple.com>

Very cool! Thanks for the update, Richard.

-Jim

On Jan 17, 2011, at 2:30 AM, Richard Pennington wrote:

> Hi,
> 
> I've been working on combining LLVM, clang, the NetBSD standard C 
> library, compiler-rt, QEMU, GDB, and GNU binutils as a cross compilation 
> environment. My goal is to target small embedded systems, but I think 
> that what I'm working on may be of interest to other LLVM/clang 
> developers as I have been able to use the environment to fix several 
> code generation issues in LLVM.
> 
> As of today, I can compile non-trivial programs for ARM, i386, Mips, 
> Microblaze, PowerPC, PowerPC64, and X86_64. These programs can be run 
> with the modified NetBSD C library under QEMU in Linux user space 
> emulation mode on my X86_64 Linux box. If anyone is interested in trying 
> it out it is at http://ellcc.org.
> 
> Some important notes:
> * I have built this on a X86_64 Linux system only. Linux is required to 
> get the QEMU Linux user mode support.
> * The SVN checkout is huge, since it has everything mentioned above in it.
> * This is a work in progress: There are things that don't work. Not for 
> the faint of heart!
> * It is fairly easy to build the complete package, see 
> http://ellcc.org/installation.html and http://ellcc.org/targetsupport.html
> * Not all of the NetBSD standard library has been ported. There are a 
> lot of system calls, etc. that have not been tested. I've been adding 
> things as needed, not in any systematic way.
> * It is currently based on a fairly recent version of LLVM/clang: r122956.
> * Processor support is currently limited to those that are supported by 
> QEMU, just because I wanted to have a common run/debug environment.
> 
> Feel free to check it out.
> 
> -Rich
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From echristo at apple.com  Tue Jan 18 18:06:05 2011
From: echristo at apple.com (Eric Christopher)
Date: Tue, 18 Jan 2011 16:06:05 -0800
Subject: [LLVMdev] About test suits Cont1
In-Reply-To: <AANLkTikSwsD02Fk77KamACGWZx-tTFgJ36iE7oBKRjAP@mail.gmail.com>
References: <AANLkTim+Jh+zp1jtXf-DiNHHrXnS-DBHBjoMzBbLSbXz@mail.gmail.com>
	<CE34A964-A4B8-4151-B38D-72FE4ED972DB@apple.com>
	<AANLkTikSwsD02Fk77KamACGWZx-tTFgJ36iE7oBKRjAP@mail.gmail.com>
Message-ID: <F15E6643-64AF-45D6-BD67-DBDBE838B1EC@apple.com>

I'm not quite sure what on earth you're doing.

Let's start from some questions:

a) llvm-gcc-4.2-version-platform.tar.gz

I don't know what this is. Does it contain binaries? I don't see you building llvm-gcc at any point, or installing binaries for it.

b) your commands have a lot of variables in them. Could you perhaps show the actual commands you're running, very simply? It's only about 10 lines.

Comments:

a) If you've got a failing configure then not re-running configure for subdirectories isn't likely to change anything is it?

b) In a grep of my llvm build directory I have:

[yendi:Data/builds/build-llvm] echristo% grep EMITIR *
Makefile.config:LLVMCC_EMITIR_FLAG = -emit-llvm
config.log:LLVMCC_EMITIR_FLAG='-emit-llvm'
config.status:s, at LLVMCC_EMITIR_FLAG@,|#_!!_#|-emit-llvm,g

If you've done your configure correctly you'll see something similar.

-eric

On Jan 17, 2011, at 7:38 PM, Qingan Li wrote:

> 1. I have searched the access/setting of LLVMCC_EMITIR_FLAG in the build directory, recursively, and all the output is what I pasted in last email (just the same to the that in source directory). Maybe the configure failed to do it. My command list for building the test suit is as followings:
> (1) cd ~/SRC_DIR/llvm/projects
> (2) svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
> (3) cd LLVMGCC_DIR;       
> (4) gunzip --stdout llvm-gcc-4.2-version-platform.tar.gz | tar -xvf -
> (5) cd ~/OBJ_DIR/llvm; 
> (6) SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime  --disable-optimized --enable-debug-symbols --enable-assertions   --with-llvmgccdir=LLVMGCC_DIR
> (7) search LLVMCC_EMITIR_FLAG or "cd projects/test-suite" (both failed)  
> 
> 2. Another question
> In the steps above, I omitted the re-configure process in http://llvm.org/docs/TestingGuide.html#testsuiterun , since I thought I have configured the $LLVM_GCC_DIR before building llvm. 
> 
> As it failed, I did the following to reconfigure, but it failed again:
> (8) cd OBJ_DIR/llvm/
> (9) SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime  --disable-optimized --enable-debug-symbols --enable-assertions   --with-llvmgccdir=LLVMGCC_DIR
> 
> I need your help, and thanks very much for your time.
> 
> 2011/1/18 Eric Christopher <echristo at apple.com>
> 
> On Jan 15, 2011, at 8:06 PM, Qingan Li wrote:
> 
>> [qali at qali llvm-2.8-rev]$ find . -exec grep -n "LLVMCC_EMITIR_FLAG" ./ {} \;
>> ./projects/test-suite/Makefile.tests:47:	-$(LCC) $(CPPFLAGS) $(CFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
>> ./projects/test-suite/Makefile.tests:51:	-$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
>> ./projects/test-suite/Makefile.tests:55:	-$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
>> ./projects/test-suite/Makefile.tests:59:	-$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
>> ./projects/test-suite/Makefile.tests:63:	-$(LCC) $(CPPFLAGS) $(CFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
>> ./projects/test-suite/Makefile.tests:67:	-$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
>> 
> 
> I know this. The question I asked was to grep in your top level build directory. You a) searched all subdirectories, and b) in the source, not build directory.
> 
>> There are errors in config.log, but I need your help for clarifying them (I selected the first four errors below): 
> 
> These errors aren't even important. In order to figure out what your system has configure will attempt to compile a bunch of different programs.
> 
> You'll need to look for what is setting LLVMCC_EMITIR_FLAG and then debug from there.
> 
> -eric
> 
> 
> 
> 
> 
> -- 
> Best regards,
> 
> Li Qingan
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110118/2ad6986b/attachment.html 

From ezengbin at gmail.com  Tue Jan 18 20:38:57 2011
From: ezengbin at gmail.com (Bin Zeng)
Date: Tue, 18 Jan 2011 21:38:57 -0500
Subject: [LLVMdev] Building 176.gcc
Message-ID: <4D364EC1.3010304@gmail.com>

Hi folks,

I have been stumped on a compilation problem when I tried to build 
176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel. 
First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since 
the default C standard of Clang is c99 while that of gcc is c89. It 
reported this error:
./c-gperf.h:14:1: error: unknown type name 'inline'
inline
^
./c-gperf.h:16:1: error: expected identifier or '('
static unsigned int
...

This is the part of the source code:
#ifdef __GNUC__
inline
#endif
static unsigned int
hash (str, len)
...
Definitely, the error existed because clang has different support for 
inline. Then I tried to compile with 'clang *.c -std=c99 -o gcc.clang' 
because c99 supports inline. It reported this error:
/tmp/cc-tJBugS.o: In function `stat':
toplev.c:(.text+0x0): multiple definition of `stat'
/tmp/cc-aQKHyN.o:getpwd.c:(.text+0x0): first defined here
/tmp/cc-tJBugS.o: In function `fstat':
toplev.c:(.text+0x30): multiple definition of `fstat'
/tmp/cc-aQKHyN.o:getpwd.c:(.text+0x30): first defined here
/tmp/cc-GZ5yz3.o: In function `init_lex':
c-lex.c:(.text+0x417): undefined reference to `is_reserved_word'
c-lex.c:(.text+0x463): undefined reference to `is_reserved_word'
c-lex.c:(.text+0x4a1): undefined reference to `is_reserved_word'
c-lex.c:(.text+0x4df): undefined reference to `is_reserved_word'
c-lex.c:(.text+0x51d): undefined reference to `is_reserved_word'

function stat and fstat are included from header files <sys/stat.h>. I 
suppose this has something to do with the c89 C preprocessor standard.

Also, I looked at the configuration files of SPEC CPU2000. There is no 
special command line options for building 176.gcc. The base tune command 
line is this: 'gcc -c  -O3 -fomit-frame-pointer   *.c'.   Is there any 
way to walk around this without changing the source code of 176.gcc? I 
do not intend to do change it since it is standard benchmark program. 
Definitely, someone has built SPEC CPU2000 with clang successfully 
before. Does anyone have any suggestion?

Thanks a lot!
Bin

From ww345ww at gmail.com  Tue Jan 18 21:06:41 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Wed, 19 Jan 2011 11:06:41 +0800
Subject: [LLVMdev] Fwd:  About test suits Cont1
In-Reply-To: <AANLkTinK-feeY3PoHi+XgGJTxXS+_ZG9Pz6dPtyxYSpP@mail.gmail.com>
References: <AANLkTim+Jh+zp1jtXf-DiNHHrXnS-DBHBjoMzBbLSbXz@mail.gmail.com>
	<CE34A964-A4B8-4151-B38D-72FE4ED972DB@apple.com>
	<AANLkTikSwsD02Fk77KamACGWZx-tTFgJ36iE7oBKRjAP@mail.gmail.com>
	<F15E6643-64AF-45D6-BD67-DBDBE838B1EC@apple.com>
	<AANLkTinK-feeY3PoHi+XgGJTxXS+_ZG9Pz6dPtyxYSpP@mail.gmail.com>
Message-ID: <AANLkTimYmh4oiUThXJ26_f6jpmkKtq8m3z3-SaTuJ=SM@mail.gmail.com>

---------- Forwarded message ----------
From: Qingan Li <ww345ww at gmail.com>
Date: 2011/1/19
Subject: Re: [LLVMdev] About test suits Cont1
To: Eric Christopher <echristo at apple.com>


*I am sorry for making you confused when I presented my problem.*
*1. My steps for the test suit building:*
(1) cd /home/qali/Src;  *           // This is my source directory for all
application programs*
(2) tar xzf llvm-2.8.tgz; *           // now, the top directory of source
tree is /home/qali/llvm-2.8*
(3) cd llvm-2.8/projects
(4) svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite* //
now I check out the test suite into /home/qali/llvm-2.8/projects*
(5) cd /home/qali/install;*        // This is my Install directory for all
applications*
(6) tar xjf llvm-gcc4.2-2.8-x86_64-linux.tar.bz2*      //Now, the binary
file for llvm-gcc is in /bin, since what I downloaded was the binary version
*
(7) cd /home/qali/Build;      mkdir llvm-2.8;   cd llvm-2.8*;         **//
Now, it is in my top directory for building llvm: /home/qali/Build/llvm-2.8*
(8) /home/qali/Src/llvm-2.8/configure --prefix=/home/qali/install/llvm-2.8
--enable-debug-runtime  --disable-optimized --enable-debug-symbols
--enable-assertions   --with-llvmgccdir=
/home/qali/install/llvm-gcc4.2-2.8-x86_64-linux
(9) make
(10) /home/qali/Src/llvm-2.8/configure --prefix=/home/qali/install/llvm-2.8
--enable-debug-runtime  --disable-optimized --enable-debug-symbols
--enable-assertions
--with-llvmgccdir=/home/qali/install/llvm-gcc4.2-2.8-x86_64-linux
         * // reconfigure process*
(11) grep EMITIR *
Here, I get no results. It seems LLVMCC_EMITIR_FLAG was not set during my
configuration.
My linux is Fedora Core 13, cpu is intel i3, and host gcc is 4.4.5.
*

2. After the reconfigure process, I have search LLVM in config.log, and all
the results are below:
[qali at qali llvm-2.8-ori]$ grep "^LLVM" config.log
LLVMCC1='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/cc1'
LLVMCC1PLUS='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/cc1plus'
LLVMCC_OPTION='llvm-gcc'
LLVMGCC='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-gcc'
LLVMGCCCOMMAND='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-gcc'
LLVMGCCDIR='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/..'
LLVMGCC_LANGS='c,c++,fortran'
LLVMGXX='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-g++'
LLVMGXXCOMMAND='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-g++'
LLVM_BINDIR='/home/qali/install/llvm-2.8-ori/bin'
LLVM_CONFIGTIME='Wed Jan 19 10:22:57 HKT 2011'
LLVM_COPYRIGHT='Copyright (c) 2003-2010 University of Illinois at
Urbana-Champaign.'
LLVM_CROSS_COMPILING='0'
LLVM_DATADIR='/home/qali/install/llvm-2.8-ori/share/llvm'
LLVM_DOCSDIR='/home/qali/install/llvm-2.8-ori/share/doc/llvm'
LLVM_ENUM_ASM_PARSERS='LLVM_ASM_PARSER(ARM) LLVM_ASM_PARSER(X86) '
LLVM_ENUM_ASM_PRINTERS='LLVM_ASM_PRINTER(MBlaze) LLVM_ASM_PRINTER(Blackfin)
LLVM_ASM_PRINTER(SystemZ) LLVM_ASM_PRINTER(MSP430) LLVM_ASM_PRINTER(XCore)
LLVM_ASM_PRINTER(PIC16) LLVM_ASM_PRINTER(CellSPU) LLVM_ASM_PRINTER(Mips)
LLVM_ASM_PRINTER(ARM) LLVM_ASM_PRINTER(Alpha) LLVM_ASM_PRINTER(PowerPC)
LLVM_ASM_PRINTER(Sparc) LLVM_ASM_PRINTER(X86) '
LLVM_ENUM_DISASSEMBLERS='LLVM_DISASSEMBLER(ARM) LLVM_DISASSEMBLER(X86) '
LLVM_ENUM_TARGETS='LLVM_TARGET(MBlaze) LLVM_TARGET(CppBackend)
LLVM_TARGET(CBackend) LLVM_TARGET(Blackfin) LLVM_TARGET(SystemZ)
LLVM_TARGET(MSP430) LLVM_TARGET(XCore) LLVM_TARGET(PIC16)
LLVM_TARGET(CellSPU) LLVM_TARGET(Mips) LLVM_TARGET(ARM) LLVM_TARGET(Alpha)
LLVM_TARGET(PowerPC) LLVM_TARGET(Sparc) LLVM_TARGET(X86) '
LLVM_ETCDIR='/home/qali/install/llvm-2.8-ori/etc/llvm'
LLVM_INCLUDEDIR='/home/qali/install/llvm-2.8-ori/include'
LLVM_INFODIR='/home/qali/install/llvm-2.8-ori/info'
LLVM_LIBDIR='/home/qali/install/llvm-2.8-ori/lib'
LLVM_MANDIR='/home/qali/install/llvm-2.8-ori/man'
LLVM_ON_UNIX='1'
LLVM_ON_WIN32='0'
LLVM_PREFIX='/home/qali/install/llvm-2.8-ori'
*

2011/1/19 Eric Christopher <echristo at apple.com>

I'm not quite sure what on earth you're doing.
>
> Let's start from some questions:
>
> a) llvm-gcc-4.2-version-platform.tar.gz
>
> I don't know what this is. Does it contain binaries? I don't see you
> building llvm-gcc at any point, or installing binaries for it.
>
> b) your commands have a lot of variables in them. Could you perhaps show
> the actual commands you're running, very simply? It's only about 10 lines.
>
> Comments:
>
> a) If you've got a failing configure then not re-running configure for
> subdirectories isn't likely to change anything is it?
>
> b) In a grep of my llvm build directory I have:
>
> [yendi:Data/builds/build-llvm] echristo% grep EMITIR *
> Makefile.config:LLVMCC_EMITIR_FLAG = -emit-llvm
> config.log:LLVMCC_EMITIR_FLAG='-emit-llvm'
> config.status:s, at LLVMCC_EMITIR_FLAG@,|#_!!_#|-emit-llvm,g
>
> If you've done your configure correctly you'll see something similar.
>
> -eric
>
> On Jan 17, 2011, at 7:38 PM, Qingan Li wrote:
>
> 1. I have searched the access/setting of LLVMCC_EMITIR_FLAG in the build
> directory, recursively, and all the output is what I pasted in last email
> (just the same to the that in source directory). Maybe the configure failed
> to do it. My command list for building the test suit is as followings:
> (1) cd ~/SRC_DIR/llvm/projects
> (2) svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
> (3) cd LLVMGCC_DIR;
> (4) gunzip --stdout llvm-gcc-4.2-version-platform.tar.gz | tar -xvf -
> (5) cd ~/OBJ_DIR/llvm;
> (6) SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime
>  --disable-optimized --enable-debug-symbols
> --enable-assertions   --with-llvmgccdir=LLVMGCC_DIR
> (7) search LLVMCC_EMITIR_FLAG or "cd projects/test-suite" (both failed)
>
> 2. Another question
> In the steps above, I omitted the re-configure process in
> http://llvm.org/docs/TestingGuide.html#testsuiterun , since I thought I
> have configured the $LLVM_GCC_DIR before building llvm.
>
> As it failed, I did the following to reconfigure, but it failed again:
> (8) cd OBJ_DIR/llvm/
> (9) SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime
>  --disable-optimized --enable-debug-symbols
> --enable-assertions   --with-llvmgccdir=LLVMGCC_DIR
>
> I need your help, and thanks very much for your time.
>
> 2011/1/18 Eric Christopher <echristo at apple.com>
>
> On Jan 15, 2011, at 8:06 PM, Qingan Li wrote:
>
> [qali at qali llvm-2.8-rev]$ find . -exec grep -n "LLVMCC_EMITIR_FLAG" ./ {}
> \;
> ./projects/test-suite/Makefile.tests:47: -$(LCC) $(CPPFLAGS) $(CFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:51: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:55: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:59: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:63: -$(LCC) $(CPPFLAGS) $(CFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
> ./projects/test-suite/Makefile.tests:67: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS)
> $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)
>
>
> I know this. The question I asked was to grep in your top level build
> directory. You a) searched all subdirectories, and b) in the source, not
> build directory.
>
> There are errors in config.log, but I need your help for clarifying them (I
> selected the first four errors below):
>
>
> These errors aren't even important. In order to figure out what your system
> has configure will attempt to compile a bunch of different programs.
>
> You'll need to look for what is setting LLVMCC_EMITIR_FLAG and then debug
> from there.
>
> -eric
>
>
>
>
>
> --
> Best regards,
>
> Li Qingan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>


-- 
Best regards,

Li Qingan




-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110119/e0cb333e/attachment.html 

From ww345ww at gmail.com  Tue Jan 18 21:08:40 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Wed, 19 Jan 2011 11:08:40 +0800
Subject: [LLVMdev] About test suits Cont2
Message-ID: <AANLkTikuoK7-0of33M+q7szx6Gtya3bB-myWTWQC9ErD@mail.gmail.com>

*I am sorry for making you confused when I presented my problem.*
*1. My steps for the test suit building:*
(1) cd /home/qali/Src;  *           // This is my source directory for all
application programs*
(2) tar xzf llvm-2.8.tgz; *           // now, the top directory of source
tree is /home/qali/llvm-2.8*
(3) cd llvm-2.8/projects
(4) svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite* //
now I check out the test suite into /home/qali/llvm-2.8/projects*
(5) cd /home/qali/install;*        // This is my Install directory for all
applications*
(6) tar xjf llvm-gcc4.2-2.8-x86_64-linux.tar.bz2*      //Now, the binary
file for llvm-gcc is in /bin, since what I downloaded was the binary version
*
(7) cd /home/qali/Build;      mkdir llvm-2.8;   cd llvm-2.8*;         **//
Now, it is in my top directory for building llvm: /home/qali/Build/llvm-2.8*
(8) /home/qali/Src/llvm-2.8/configure --prefix=/home/qali/install/llvm-2.8
--enable-debug-runtime  --disable-optimized --enable-debug-symbols
--enable-assertions   --with-llvmgccdir=
/home/qali/install/llvm-gcc4.2-2.8-x86_64-linux
(9) make
(10) /home/qali/Src/llvm-2.8/configure --prefix=/home/qali/install/llvm-2.8
--enable-debug-runtime  --disable-optimized --enable-debug-symbols
--enable-assertions
--with-llvmgccdir=/home/qali/install/llvm-gcc4.2-2.8-x86_64-linux
         * // reconfigure process*
(11) grep EMITIR *
Here, I get no results. It seems LLVMCC_EMITIR_FLAG was not set during my
configuration.
My linux is Fedora Core 13, cpu is intel i3, and host gcc is 4.4.5.
*

2. After the reconfigure process, I have search LLVM in config.log, and all
the results are below:
[qali at qali llvm-2.8-ori]$ grep "^LLVM" config.log
LLVMCC1='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/cc1'
LLVMCC1PLUS='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/cc1plus'
LLVMCC_OPTION='llvm-gcc'
LLVMGCC='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-gcc'
LLVMGCCCOMMAND='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-gcc'
LLVMGCCDIR='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/..'
LLVMGCC_LANGS='c,c++,fortran'
LLVMGXX='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-g++'
LLVMGXXCOMMAND='/home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-g++'
LLVM_BINDIR='/home/qali/install/llvm-2.8-ori/bin'
LLVM_CONFIGTIME='Wed Jan 19 10:22:57 HKT 2011'
LLVM_COPYRIGHT='Copyright (c) 2003-2010 University of Illinois at
Urbana-Champaign.'
LLVM_CROSS_COMPILING='0'
LLVM_DATADIR='/home/qali/install/llvm-2.8-ori/share/llvm'
LLVM_DOCSDIR='/home/qali/install/llvm-2.8-ori/share/doc/llvm'
LLVM_ENUM_ASM_PARSERS='LLVM_ASM_PARSER(ARM) LLVM_ASM_PARSER(X86) '
LLVM_ENUM_ASM_PRINTERS='LLVM_ASM_PRINTER(MBlaze) LLVM_ASM_PRINTER(Blackfin)
LLVM_ASM_PRINTER(SystemZ) LLVM_ASM_PRINTER(MSP430) LLVM_ASM_PRINTER(XCore)
LLVM_ASM_PRINTER(PIC16) LLVM_ASM_PRINTER(CellSPU) LLVM_ASM_PRINTER(Mips)
LLVM_ASM_PRINTER(ARM) LLVM_ASM_PRINTER(Alpha) LLVM_ASM_PRINTER(PowerPC)
LLVM_ASM_PRINTER(Sparc) LLVM_ASM_PRINTER(X86) '
LLVM_ENUM_DISASSEMBLERS='LLVM_DISASSEMBLER(ARM) LLVM_DISASSEMBLER(X86) '
LLVM_ENUM_TARGETS='LLVM_TARGET(MBlaze) LLVM_TARGET(CppBackend)
LLVM_TARGET(CBackend) LLVM_TARGET(Blackfin) LLVM_TARGET(SystemZ)
LLVM_TARGET(MSP430) LLVM_TARGET(XCore) LLVM_TARGET(PIC16)
LLVM_TARGET(CellSPU) LLVM_TARGET(Mips) LLVM_TARGET(ARM) LLVM_TARGET(Alpha)
LLVM_TARGET(PowerPC) LLVM_TARGET(Sparc) LLVM_TARGET(X86) '
LLVM_ETCDIR='/home/qali/install/llvm-2.8-ori/etc/llvm'
LLVM_INCLUDEDIR='/home/qali/install/llvm-2.8-ori/include'
LLVM_INFODIR='/home/qali/install/llvm-2.8-ori/info'
LLVM_LIBDIR='/home/qali/install/llvm-2.8-ori/lib'
LLVM_MANDIR='/home/qali/install/llvm-2.8-ori/man'
LLVM_ON_UNIX='1'
LLVM_ON_WIN32='0'
*

-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110119/7b2f4ec5/attachment-0001.html 

From echristo at apple.com  Tue Jan 18 21:58:58 2011
From: echristo at apple.com (Eric Christopher)
Date: Tue, 18 Jan 2011 19:58:58 -0800
Subject: [LLVMdev] Fwd:  About test suits Cont1
In-Reply-To: <AANLkTimYmh4oiUThXJ26_f6jpmkKtq8m3z3-SaTuJ=SM@mail.gmail.com>
References: <AANLkTim+Jh+zp1jtXf-DiNHHrXnS-DBHBjoMzBbLSbXz@mail.gmail.com>
	<CE34A964-A4B8-4151-B38D-72FE4ED972DB@apple.com>
	<AANLkTikSwsD02Fk77KamACGWZx-tTFgJ36iE7oBKRjAP@mail.gmail.com>
	<F15E6643-64AF-45D6-BD67-DBDBE838B1EC@apple.com>
	<AANLkTinK-feeY3PoHi+XgGJTxXS+_ZG9Pz6dPtyxYSpP@mail.gmail.com>
	<AANLkTimYmh4oiUThXJ26_f6jpmkKtq8m3z3-SaTuJ=SM@mail.gmail.com>
Message-ID: <57BDEC46-F491-4CE2-81DF-6EE6236BA2B7@apple.com>


On Jan 18, 2011, at 7:06 PM, Qingan Li wrote:

> (2) tar xzf llvm-2.8.tgz;            // now, the top directory of source tree is /home/qali/llvm-2.8
> (3) cd llvm-2.8/projects
> (4) svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite      // now I check out the test suite into /home/qali/llvm-2.8/projects
> (5) cd /home/qali/install;        // This is my Install directory for all applications
> (6) tar xjf llvm-gcc4.2-2.8-x86_64-linux.tar.bz2      //Now, the binary file for llvm-gcc is in /bin, since what I do

Aha. I figured it out, my apologies for not noticing this sooner.

The LLVM_EMITIR_FLAG variable was added after 2.8, so by checking out the testsuite into a newer source tree you're mixing and matching two versions that aren't compatible anymore.

You have two options:

a) check out llvm and the testsuite from svn
b) use the source and testsuite from the download

Thanks for the report and working with us nicely :)

Good luck!

-eric

From nicholas at mxc.ca  Tue Jan 18 22:02:00 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 18 Jan 2011 20:02:00 -0800
Subject: [LLVMdev] Building 176.gcc
In-Reply-To: <4D364EC1.3010304@gmail.com>
References: <4D364EC1.3010304@gmail.com>
Message-ID: <4D366238.7050400@mxc.ca>

On 01/18/2011 06:38 PM, Bin Zeng wrote:
> Hi folks,
>
> I have been stumped on a compilation problem when I tried to build
> 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel.
> First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since
> the default C standard of Clang is c99 while that of gcc is c89. It
> reported this error:
> ./c-gperf.h:14:1: error: unknown type name 'inline'
> inline
> ^
> ./c-gperf.h:16:1: error: expected identifier or '('
> static unsigned int
> ...
>
> This is the part of the source code:
> #ifdef __GNUC__
> inline
> #endif
> static unsigned int
> hash (str, len)
> ...
> Definitely, the error existed because clang has different support for
> inline. Then I tried to compile with 'clang *.c -std=c99 -o gcc.clang'
> because c99 supports inline. It reported this error:
> /tmp/cc-tJBugS.o: In function `stat':
> toplev.c:(.text+0x0): multiple definition of `stat'
> /tmp/cc-aQKHyN.o:getpwd.c:(.text+0x0): first defined here
> /tmp/cc-tJBugS.o: In function `fstat':
> toplev.c:(.text+0x30): multiple definition of `fstat'
> /tmp/cc-aQKHyN.o:getpwd.c:(.text+0x30): first defined here
> /tmp/cc-GZ5yz3.o: In function `init_lex':
> c-lex.c:(.text+0x417): undefined reference to `is_reserved_word'
> c-lex.c:(.text+0x463): undefined reference to `is_reserved_word'
> c-lex.c:(.text+0x4a1): undefined reference to `is_reserved_word'
> c-lex.c:(.text+0x4df): undefined reference to `is_reserved_word'
> c-lex.c:(.text+0x51d): undefined reference to `is_reserved_word'

Try -std=gnu89 instead of -std=c89. "inline" in C89 is a GNU extension, 
and -std=c89 runs with gnu extensions disabled but __GNUC__ is still 
defined.

Nick

> function stat and fstat are included from header files<sys/stat.h>. I
> suppose this has something to do with the c89 C preprocessor standard.
>
> Also, I looked at the configuration files of SPEC CPU2000. There is no
> special command line options for building 176.gcc. The base tune command
> line is this: 'gcc -c  -O3 -fomit-frame-pointer   *.c'.   Is there any
> way to walk around this without changing the source code of 176.gcc? I
> do not intend to do change it since it is standard benchmark program.
> Definitely, someone has built SPEC CPU2000 with clang successfully
> before. Does anyone have any suggestion?
>
> Thanks a lot!
> Bin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From raghu at cs.ucla.edu  Tue Jan 18 23:18:59 2011
From: raghu at cs.ucla.edu (Raghu Prabhakar)
Date: Tue, 18 Jan 2011 21:18:59 -0800 (PST)
Subject: [LLVMdev] Modifying the patterns/ instruction selection phase in
	LLVM 2.7
In-Reply-To: <58690641.42708.1295413442635.JavaMail.root@mail.cs.ucla.edu>
Message-ID: <1423349269.42770.1295414338973.JavaMail.root@mail.cs.ucla.edu>

Hello all,

I am trying to modify the Sparc backend to do something for my team's project, to do the following. 

Whenever the backend encounters a call to one particular type of function names (functions like p0(), p1()..etc), I want the backend to generate a "sethi %g0, <number>", and NOT a "call p0, call p1..." instruction. However, the backend should work as usual for any other function name.

Now I figured that there are two ways to do this : 
1) Modifying the "SparcISelLowering.cpp" to emit a special SDNode (with a special opcode that I have introduced into SPISD namespace) whenever it finds a "call @p0" in the LowerCall function. This node should have an entry in the "SparcInstrInfo.td" file.

2) No modifications to the Lowering phase. However, the pattern corresponding to the "sethi" instruction must be modified/new pattern added which corresponds to "call p0" kind of selectionDAG nodes.

In either case, I am a bit confused about how tblgen's pattern representation scheme works. One more issue is that the destination register of "sethi %g0, <NUM>" HAS to be %g0 (which makes it a no-op on an actual sparc machine..I'm using a simulator), and <NUM> depends on p0 and its operands. There are ways where the certain registers required can be hard-assigned during instruction selection itself, but I'm unsure as to how to do that. Am I looking at the right set of files? Is there a better way to accomplish what I'm trying to do?

I'm relatively new to LLVM, so I have some trouble freely navigating through the source in spite of being heavily documented.

Any suggestions is of great help.

Thanks.
Raghu.

From baldrick at free.fr  Wed Jan 19 01:39:16 2011
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 19 Jan 2011 08:39:16 +0100
Subject: [LLVMdev] need help on llc option -march=?
In-Reply-To: <AANLkTi=+VJFFmF_JcZ55ijHQJseTFieRhHsWOaWPOFZZ@mail.gmail.com>
References: <AANLkTi=+VJFFmF_JcZ55ijHQJseTFieRhHsWOaWPOFZZ@mail.gmail.com>
Message-ID: <4D369524.60907@free.fr>

Hi Atse,

> I change name of instruction on XXXInstrInfo.td ( Sparc, X86 and XCore).I looked
> into XXXGenAsmWriter.inc and I have seen the new instruction name. But when I
> run llc for the three targets it prints out the old instruction name.

are you sure you are running the new llc and not the old?

Ciao, Duncan.

From evzen.muller at arm.com  Wed Jan 19 03:46:22 2011
From: evzen.muller at arm.com (Evzen Muller)
Date: Wed, 19 Jan 2011 09:46:22 -0000
Subject: [LLVMdev] Building 176.gcc
In-Reply-To: <4D366238.7050400@mxc.ca>
References: <4D364EC1.3010304@gmail.com> <4D366238.7050400@mxc.ca>
Message-ID: <000401cbb7bd$bb6a5100$323ef300$@muller@arm.com>

SPECCPU2000 include a lot of GCC specific & non-standard code, fortunately
it is easy to
specify CPORTABILITY flags for individual tests in a config file.

For latest clang I had to use:

252.eon: -fpermissive
300.twolf: -std=gnu89 -Wreturn-type

Evzen

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Nick Lewycky
> Sent: 19 January 2011 04:02
> To: Bin Zeng
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Building 176.gcc
> 
> On 01/18/2011 06:38 PM, Bin Zeng wrote:
> > Hi folks,
> >
> > I have been stumped on a compilation problem when I tried to build
> > 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and
> intel.
> > First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since
> > the default C standard of Clang is c99 while that of gcc is c89. It
> > reported this error:
> > ./c-gperf.h:14:1: error: unknown type name 'inline'
> > inline
> > ^
> > ./c-gperf.h:16:1: error: expected identifier or '('
> > static unsigned int
> > ...
> >
> > This is the part of the source code:
> > #ifdef __GNUC__
> > inline
> > #endif
> > static unsigned int
> > hash (str, len)
> > ...
> > Definitely, the error existed because clang has different support for
> > inline. Then I tried to compile with 'clang *.c -std=c99 -o gcc.clang'
> > because c99 supports inline. It reported this error:
> > /tmp/cc-tJBugS.o: In function `stat':
> > toplev.c:(.text+0x0): multiple definition of `stat'
> > /tmp/cc-aQKHyN.o:getpwd.c:(.text+0x0): first defined here
> > /tmp/cc-tJBugS.o: In function `fstat':
> > toplev.c:(.text+0x30): multiple definition of `fstat'
> > /tmp/cc-aQKHyN.o:getpwd.c:(.text+0x30): first defined here
> > /tmp/cc-GZ5yz3.o: In function `init_lex':
> > c-lex.c:(.text+0x417): undefined reference to `is_reserved_word'
> > c-lex.c:(.text+0x463): undefined reference to `is_reserved_word'
> > c-lex.c:(.text+0x4a1): undefined reference to `is_reserved_word'
> > c-lex.c:(.text+0x4df): undefined reference to `is_reserved_word'
> > c-lex.c:(.text+0x51d): undefined reference to `is_reserved_word'
> 
> Try -std=gnu89 instead of -std=c89. "inline" in C89 is a GNU extension,
> and -std=c89 runs with gnu extensions disabled but __GNUC__ is still
> defined.
> 
> Nick
> 
> > function stat and fstat are included from header files<sys/stat.h>. I
> > suppose this has something to do with the c89 C preprocessor standard.
> >
> > Also, I looked at the configuration files of SPEC CPU2000. There is no
> > special command line options for building 176.gcc. The base tune
> command
> > line is this: 'gcc -c  -O3 -fomit-frame-pointer   *.c'.   Is there any
> > way to walk around this without changing the source code of 176.gcc? I
> > do not intend to do change it since it is standard benchmark program.
> > Definitely, someone has built SPEC CPU2000 with clang successfully
> > before. Does anyone have any suggestion?
> >
> > Thanks a lot!
> > Bin
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev






From jnspaulsson at hotmail.com  Wed Jan 19 08:26:05 2011
From: jnspaulsson at hotmail.com (Jonas Paulsson)
Date: Wed, 19 Jan 2011 15:26:05 +0100
Subject: [LLVMdev] tied registers
Message-ID: <SNT106-W624157F78CF6C5C5B8DDCB1F60@phx.gbl>


Hi,

I wonder if there is a simple way to define a 3-address instruction taking 4 operands, ie a 

32regA = MAC (32regB, 16regC, 16regD)  // widening mac instruction

Regs A and B should be handled like "src1 = dst", but this does not work, I get odd results.

I wonder also how to generally select instructions when the widths of the input operands differ like this.

Thanks,

Jonas

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110119/fdba4f10/attachment.html 

From czhao at eecg.toronto.edu  Wed Jan 19 10:24:48 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Wed, 19 Jan 2011 11:24:48 -0500
Subject: [LLVMdev] know if individual LLVM's Instruction has a result,
 and how to obtain it?
Message-ID: <4D371050.1080006@eecg.toronto.edu>

Most LLVM IR instructions have a result field, according to the Language 
Reference.

I want to know, for all LLVM Instructions, is there an easy and 
consistent way to know if the current Inst has a result field?
And if yes, what is the best way to obtain it?

E.g.:

   <result>  = add<ty>  <op1>,<op2>           /; yields {ty}:result

/

All ADD instruction will have a result field, regardless of whether its 
result is used.

I checked the source code for Instruction.h/.cpp, getOperand(int) is for 
obtaining the operands only. There is no dedicated method to obtain the 
result.
{I was expecting something like Instruction->getResult().}


Instruction * Inst;
...
Value * Res = Inst;

Is the above the right way to do the work?

For an other example:

  <result>  = [tail] call [cconv  <http://llvm.org/docs/LangRef.html#callingconv>] [ret attrs  <http://llvm.org/docs/LangRef.html#paramattrs>]<ty>  [<fnty>*]<fnptrval>(<function args>) [fn attrs  <http://llvm.org/docs/LangRef.html#fnattrs>]


According to the LLVM Language reference, CallInst should always have a 
result.
But for void bar(int) types, there will be no return. So the generated 
IR will be similar to:

   call void @bar(i32 %2) nounwind

instead of

   %3 = call void @bar(i32 %2) nounwind

How can I handle this or similar case?

Are there special handling for certain Instructions? (E.g. LoadInst, 
StoreInst, etc.)

Thank you very much

Chuck




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110119/e8e68530/attachment.html 

From baldrick at free.fr  Wed Jan 19 10:53:11 2011
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 19 Jan 2011 17:53:11 +0100
Subject: [LLVMdev] know if individual LLVM's Instruction has a result,
 and how to obtain it?
In-Reply-To: <4D371050.1080006@eecg.toronto.edu>
References: <4D371050.1080006@eecg.toronto.edu>
Message-ID: <4D3716F7.5060608@free.fr>

Hi Chuck,

> Most LLVM IR instructions have a result field, according to the Language Reference.
>
> I want to know, for all LLVM Instructions, is there an easy and consistent way
> to know if the current Inst has a result field?
> And if yes, what is the best way to obtain it?

the instruction is the result!  So everywhere you though you needed to use
Instruction->getResult(), just use Instruction.  Thus your question about
whether there is a result field doesn't make sense.  The closest thing is
probably: the instruction does not have void type.

Ciao, Duncan.

>
> E.g.:
>
>    <result>  = add<ty>  <op1>,<op2>           /; yields {ty}:result
>
> /
>
> All ADD instruction will have a result field, regardless of whether its result
> is used.
>
> I checked the source code for Instruction.h/.cpp, getOperand(int) is for
> obtaining the operands only. There is no dedicated method to obtain the result.
> {I was expecting something like Instruction->getResult().}
>
>
> Instruction * Inst;
> ...
> Value * Res = Inst;
>
> Is the above the right way to do the work?
>
> For an other example:
>
>   <result>  = [tail] call [cconv  <http://llvm.org/docs/LangRef.html#callingconv>] [ret attrs  <http://llvm.org/docs/LangRef.html#paramattrs>]<ty>  [<fnty>*]<fnptrval>(<function args>) [fn attrs  <http://llvm.org/docs/LangRef.html#fnattrs>]
>
>
> According to the LLVM Language reference, CallInst should always have a result.
> But for void bar(int) types, there will be no return. So the generated IR will
> be similar to:
>
>    call void @bar(i32 %2) nounwind
>
> instead of
>
>    %3 = call void @bar(i32 %2) nounwind
>
> How can I handle this or similar case?
>
> Are there special handling for certain Instructions? (E.g. LoadInst, StoreInst,
> etc.)
>
> Thank you very much
>
> Chuck
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From czhao at eecg.toronto.edu  Wed Jan 19 11:10:30 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Wed, 19 Jan 2011 12:10:30 -0500
Subject: [LLVMdev] know if individual LLVM's Instruction has a result,
 and how to obtain it?
In-Reply-To: <4D3716F7.5060608@free.fr>
References: <4D371050.1080006@eecg.toronto.edu> <4D3716F7.5060608@free.fr>
Message-ID: <4D371B06.6040702@eecg.toronto.edu>

Duncan,

I think your answer.
I think also makes sense for void return type function calls, as its 
result(s) will never be used.

Thank you again

Chuck

On 1/19/2011 11:53 AM, Duncan Sands wrote:
> Hi Chuck,
>
>> Most LLVM IR instructions have a result field, according to the Language Reference.
>>
>> I want to know, for all LLVM Instructions, is there an easy and consistent way
>> to know if the current Inst has a result field?
>> And if yes, what is the best way to obtain it?
> the instruction is the result!  So everywhere you though you needed to use
> Instruction->getResult(), just use Instruction.  Thus your question about
> whether there is a result field doesn't make sense.  The closest thing is
> probably: the instruction does not have void type.
>
> Ciao, Duncan.
>
>> E.g.:
>>
>>     <result>   = add<ty>   <op1>,<op2>            /; yields {ty}:result
>>
>> /
>>
>> All ADD instruction will have a result field, regardless of whether its result
>> is used.
>>
>> I checked the source code for Instruction.h/.cpp, getOperand(int) is for
>> obtaining the operands only. There is no dedicated method to obtain the result.
>> {I was expecting something like Instruction->getResult().}
>>
>>
>> Instruction * Inst;
>> ...
>> Value * Res = Inst;
>>
>> Is the above the right way to do the work?
>>
>> For an other example:
>>
>>    <result>   = [tail] call [cconv<http://llvm.org/docs/LangRef.html#callingconv>] [ret attrs<http://llvm.org/docs/LangRef.html#paramattrs>]<ty>   [<fnty>*]<fnptrval>(<function args>) [fn attrs<http://llvm.org/docs/LangRef.html#fnattrs>]
>>
>>
>> According to the LLVM Language reference, CallInst should always have a result.
>> But for void bar(int) types, there will be no return. So the generated IR will
>> be similar to:
>>
>>     call void @bar(i32 %2) nounwind
>>
>> instead of
>>
>>     %3 = call void @bar(i32 %2) nounwind
>>
>> How can I handle this or similar case?
>>
>> Are there special handling for certain Instructions? (E.g. LoadInst, StoreInst,
>> etc.)
>>
>> Thank you very much
>>
>> Chuck
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From czhao at eecg.toronto.edu  Wed Jan 19 11:11:27 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Wed, 19 Jan 2011 12:11:27 -0500
Subject: [LLVMdev] know if individual LLVM's Instruction has a result,
 and how to obtain it?
In-Reply-To: <4D3716F7.5060608@free.fr>
References: <4D371050.1080006@eecg.toronto.edu> <4D3716F7.5060608@free.fr>
Message-ID: <4D371B3F.9040006@eecg.toronto.edu>

Duncan,

Thank you for the answer.
I think it also makes sense for void return type function calls, as its 
result(s) will never be used.

Chuck

On 1/19/2011 11:53 AM, Duncan Sands wrote:
> Hi Chuck,
>
>> Most LLVM IR instructions have a result field, according to the Language Reference.
>>
>> I want to know, for all LLVM Instructions, is there an easy and consistent way
>> to know if the current Inst has a result field?
>> And if yes, what is the best way to obtain it?
> the instruction is the result!  So everywhere you though you needed to use
> Instruction->getResult(), just use Instruction.  Thus your question about
> whether there is a result field doesn't make sense.  The closest thing is
> probably: the instruction does not have void type.
>
> Ciao, Duncan.
>
>> E.g.:
>>
>>     <result>   = add<ty>   <op1>,<op2>            /; yields {ty}:result
>>
>> /
>>
>> All ADD instruction will have a result field, regardless of whether its result
>> is used.
>>
>> I checked the source code for Instruction.h/.cpp, getOperand(int) is for
>> obtaining the operands only. There is no dedicated method to obtain the result.
>> {I was expecting something like Instruction->getResult().}
>>
>>
>> Instruction * Inst;
>> ...
>> Value * Res = Inst;
>>
>> Is the above the right way to do the work?
>>
>> For an other example:
>>
>>    <result>   = [tail] call [cconv<http://llvm.org/docs/LangRef.html#callingconv>] [ret attrs<http://llvm.org/docs/LangRef.html#paramattrs>]<ty>   [<fnty>*]<fnptrval>(<function args>) [fn attrs<http://llvm.org/docs/LangRef.html#fnattrs>]
>>
>>
>> According to the LLVM Language reference, CallInst should always have a result.
>> But for void bar(int) types, there will be no return. So the generated IR will
>> be similar to:
>>
>>     call void @bar(i32 %2) nounwind
>>
>> instead of
>>
>>     %3 = call void @bar(i32 %2) nounwind
>>
>> How can I handle this or similar case?
>>
>> Are there special handling for certain Instructions? (E.g. LoadInst, StoreInst,
>> etc.)
>>
>> Thank you very much
>>
>> Chuck
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From trevor at galois.com  Wed Jan 19 11:34:55 2011
From: trevor at galois.com (Trevor Elliott)
Date: Wed, 19 Jan 2011 09:34:55 -0800
Subject: [LLVMdev] Shadow Stack
Message-ID: <4D3720BF.6050202@galois.com>

Hi Everyone,

I've managed to create a small example that reproduces the error that
I'm seeing when generating code, or running the interpreter:

-----------------------------------------------------------------------

@llvm_gc_root_chain = global i8* null

declare i8* @malloc(i32)
declare void @llvm.gcroot(i8**, i8*) nounwind

define i32 @main() gc "shadow-stack" {
  %value = call i8* @malloc(i32 32)
  %ptr   = alloca i8*
  store i8* %value, i8** %ptr
  call void @llvm.gcroot(i8** %ptr, i8* null)

  ret i32 0
}

-----------------------------------------------------------------------

I am building and running it with:

 $ llvm-as test.ll
 $ lli test.bc

And the resulting stack trace is:

-----------------------------------------------------------------------

0  libLLVM-2.8.so  0x0000003cc36eee9f
1  libLLVM-2.8.so  0x0000003cc36ef99a
2  libpthread.so.0 0x0000003cc200f4a0
3  libLLVM-2.8.so  0x0000003cc33360dd
llvm::StructType::StructType(llvm::LLVMContext&, std::vector<llvm::Type
const*, std::allocator<llvm::Type const*> > const&, bool) + 237
4  libLLVM-2.8.so  0x0000003cc3337c95
llvm::StructType::get(llvm::LLVMContext&, std::vector<llvm::Type const*,
std::allocator<llvm::Type const*> > const&, bool) + 533
5  libLLVM-2.8.so  0x0000003cc3242d58
6  libLLVM-2.8.so  0x0000003cc318f09e
7  libLLVM-2.8.so  0x0000003cc3330628
llvm::FPPassManager::runOnFunction(llvm::Function&) + 424
8  libLLVM-2.8.so  0x0000003cc33307cb
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 91
9  libLLVM-2.8.so  0x0000003cc33309bd
llvm::FunctionPassManager::run(llvm::Function&) + 173
10 libLLVM-2.8.so  0x0000003cc33e8647
llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 39
11 libLLVM-2.8.so  0x0000003cc33e8a2f
llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard
const&) + 15
12 libLLVM-2.8.so  0x0000003cc33e8cde
llvm::JIT::getPointerToFunction(llvm::Function*) + 606
13 libLLVM-2.8.so  0x0000003cc33ea253
llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue,
std::allocator<llvm::GenericValue> > const&) + 67
14 libLLVM-2.8.so  0x0000003cc336ad4a
llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
std::vector<std::string, std::allocator<std::string> > const&, char
const* const*) + 1130
15 lli             0x0000000000404cd6 main + 2054
16 libc.so.6       0x0000003cc1c1ec5d __libc_start_main + 253
17 lli             0x0000000000403689
Stack dump:
0.	Program arguments: lli test.bc
1.	Running pass 'Lower Garbage Collection Instructions' on function '@main'

-----------------------------------------------------------------------

A similar stack trace is generated when running llc instead.  Any ideas?

Thanks!

--trevor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3612 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110119/7df408a9/attachment.bin 

From andrew at sidefx.com  Wed Jan 19 11:45:38 2011
From: andrew at sidefx.com (Andrew Clinton)
Date: Wed, 19 Jan 2011 12:45:38 -0500
Subject: [LLVMdev] How to avoid register reuse in machine instructions?
Message-ID: <4D372342.8050105@sidefx.com>

Is there a way to force the register allocator to avoid reusing an 
operand register for a definition?  For example, the following machine 
instruction reuses a register for the first operand and definition:

%uI7<def> = eq at III %uI7<kill>, %uI4

I'd like:

%uI8<def> = eq at III %uI7<kill>, %uI4

I'm guessing that the right way to do this would be to kill the operand 
registers after the given machine instruction rather than before it, but 
I don't see a way to mark it this way.

Andrew

From anton at korobeynikov.info  Wed Jan 19 12:14:14 2011
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 19 Jan 2011 21:14:14 +0300
Subject: [LLVMdev] How to avoid register reuse in machine instructions?
In-Reply-To: <4D372342.8050105@sidefx.com>
References: <4D372342.8050105@sidefx.com>
Message-ID: <AANLkTin-R2kwdVa8ioc=kpZsTS0cd1e=6bBo7CiSHhwB@mail.gmail.com>

Hello,

> I'm guessing that the right way to do this would be to kill the operand
> registers after the given machine instruction rather than before it, but
> I don't see a way to mark it this way.
Right now the only way is to mark output reg as earlyclobber (see ARM
backend for examples).
Note that post-RA scheduler is not yet aware about earlyclobber
operands and thus can break the constraint.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From andrew at sidefx.com  Wed Jan 19 12:24:50 2011
From: andrew at sidefx.com (Andrew Clinton)
Date: Wed, 19 Jan 2011 13:24:50 -0500
Subject: [LLVMdev] How to avoid register reuse in machine instructions?
In-Reply-To: <AANLkTin-R2kwdVa8ioc=kpZsTS0cd1e=6bBo7CiSHhwB@mail.gmail.com>
References: <4D372342.8050105@sidefx.com>
	<AANLkTin-R2kwdVa8ioc=kpZsTS0cd1e=6bBo7CiSHhwB@mail.gmail.com>
Message-ID: <4D372C72.2020500@sidefx.com>

On 01/19/2011 01:14 PM, Anton Korobeynikov wrote:
> Right now the only way is to mark output reg as earlyclobber (see ARM
> backend for examples).
> Note that post-RA scheduler is not yet aware about earlyclobber
> operands and thus can break the constraint.
>

That solved it, thank you!

From king19880326 at gmail.com  Wed Jan 19 12:29:03 2011
From: king19880326 at gmail.com (Lu Mitnick)
Date: Thu, 20 Jan 2011 02:29:03 +0800
Subject: [LLVMdev] Question about porting LLVM - variable length lnstruction
Message-ID: <AANLkTimsqMVBiO4ESAjJ2tUygqHxGXj4c+7akDLZN19S@mail.gmail.com>

Hello all,

I am adding a new target into LLVM. However the instruction length of the
target I ported is variable. Each instruction is at least 1 + 1
bytes(required) and optional parts(There are many forms of optional part
suck like i16, i32, i64, i16 + i16, i16 + i32, i16 + i64, i32 + i32, i64 +
i64).  The form of optional part is determined by the required parts. In
other words, each instruction fetch have two phase: one for fetch the
required part and another for optional part. There is similar problem of X86
target but it is too complex to understand for me. I am wondering to know
whether there is another target with this problem and I should trace?? Or
how could I deal with this problem??

thanks a lot

yi-hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/3858c51a/attachment.html 

From jasonwkim at google.com  Wed Jan 19 12:41:31 2011
From: jasonwkim at google.com (Jason Kim)
Date: Wed, 19 Jan 2011 10:41:31 -0800
Subject: [LLVMdev] Possible issue with ARM/MC/MachO fixup
Message-ID: <AANLkTikRR-kJx_akMpxU6gsh6qvupVF=EL+P08=Dj1Xw@mail.gmail.com>

Hi everyone.

In ARMAsmBackend.cpp, in routine DarwinARMAsmBackend::ApplyFixup()
there is a curious call to getFixupKindNumBytes() - which can return
1,2, 3, or 4 depending upon the FixupKind

The code in ApplyFixup() seems to be lifted from the X86.

AFAIK, the initial Fixup.Offset() is always divisible by 4, at least
for ARM mode - i.e. it is always at the instruction boundary.

it looks like adjustFixupValue() is meant to create a mask that can be
bitwise OR'ed into the full instruction, which is 2 or 4 bytes
So what does it mean to patch 1 or 3 bytes starting from the
instruction boundary?

I don't know enough about Macho to tell whether this is a bug or not.
If it isn't, apologies for the noise.

-Jason

From songlh at cs.wisc.edu  Wed Jan 19 13:47:40 2011
From: songlh at cs.wisc.edu (songlh at cs.wisc.edu)
Date: Wed, 19 Jan 2011 13:47:40 -0600
Subject: [LLVMdev] How to get the name and argument of a function
In-Reply-To: <4D351751.1030607@illinois.edu>
References: <89e0944507495fc8eb3f14dae3633306.squirrel@webmail.cs.wisc.edu>
	<4D34D996.1030806@mxc.ca>
	<7221226ddb884b77fdf4c4525421299c.squirrel@webmail.cs.wisc.edu>
	<4D351751.1030607@illinois.edu>
Message-ID: <8285a75e191c231030f87197aee5ac54.squirrel@webmail.cs.wisc.edu>

Thanks a lot!

I finally fix my problem.

My code is like this:


//CallInst* pCall   pCall is a printf called in my situation
if( ConstantExpr * pCE = dyn_cast<ConstantExpr>( pCall->getArgOperand(0))){

  if( GlobalVariable * pGV = dyn_cast<GlobalVariable>( pCE->getOperand(0))){

    if( ConstantArray * pCA = dyn_cast<ConstantArray>(
                                  pGV->getInitializer()
                                  )){
        Err << pCA->getAsString() << "\n";
     }
  }

}

I find dump() method is very useful, since it can get me some indications
about which class document I need to check.

thanks a lot!

Linhai









> On 1/17/2011 8:53 PM, songlh at cs.wisc.edu wrote:
>> Thanks a lot!
>>
>> I can get the call place now. But still have problems in getting the
>> argument.
>>
>> CallInst * pCall;
>>
>> ......
>>
>> pCall->getArgOperand(0)->dump();
>>
>> I can get "i8* getelementptr inbounds ([5 x i8]* @.str, i32 0, i32 0)"
>
> In this particular case, the argument to the call is an LLVM GEP
> Constant Expression.  It's like a GEP instruction except that all of the
> GEP arguments are constant, so the result of the GEP is also a
> constant.  In general, the argument to printf can an LLVM Value *, and
> there are lots of sub-classes derived from Value.  For example, it could
> be a GEP ConstantExpr, a Cast ConstExpr, an Instruction, etc., etc.
>
> Look at the doxygen docs for the ConstantExpr class.  You can use that
> information to figure out how to write code that peers into the
> ConstExpr to see what global value it is indexing off of.
>
> -- John T.
>
> P.S.  I grew up in Wisconsin and like Badger Hockey at UW-Madison.  Go
> Bucky!
>
>> I think this means that the variable is a global constant string. Do you
>> know how to get the name of this global string, and how to use the name
>> to
>> get the string value?
>>
>> Btw: when I use pCall->getArgOperand(0)->getName(), I can only get "".
>>
>> thanks a lot!
>>
>> Linhai
>>
>>> songlh at cs.wisc.edu wrote:
>>>> Hi everyone:
>>>>
>>>>      The code I am analyzing is :
>>>>
>>>>      int main()
>>>>      {
>>>>          int i = 0;
>>>>          printf("hello world!");
>>>>          printf( "%d" , i );
>>>>      }
>>>>
>>>>
>>>>
>>>>      I want to get each place where printf is called, and the argument
>>>> used
>>>> during that call.
>>>>
>>>>      so I write llvm pass code like:
>>>>
>>>>      void Myfunction( Function&   F){
>>>>          for( Function::iterator b = F.begin() , be = F.end() ;
>>>>           b != be; ++b){
>>>>              for(BasicBlock::iterator i = b.begin() , ie = b.end();
>>>>               i != ie; i ++){
>>>>                  if( isa<CallInst>(&(*i)) || isa<InvokeInst>(&(*i))){
>>>>                      //how could I get the function name and argument
>>>>                      //used here
>>>>                  }
>>>>              }
>>>>
>>>>          }
>>>>      }
>>>>
>>>>
>>>>      How could I get the function name and the arguments when I know
>>>> an
>>>> Instruction is a function call?
>>> There's a worked example at
>>> http://wiki.llvm.org/HowTo:_Find_all_call_sites_of_a_function .
>>>
>>> With the CallInst/InvokeInst you can query getArgOperand() to get the
>>> arguments or getCallee() which return a Function -- or it might not. If
>>> the call is an indirect call (ie., function pointer) then you don't
>>> know
>>> what it's calling. Ignoring indirect calls, you can call getName() on a
>>> function to get its name.
>>>
>>> Personally, I rely heavily on the doxygen to find my way around the
>>> API:
>>> http://llvm.org/doxygen/hierarchy.html . Look up "CallInst" for
>>> example.
>>> The getName() method isn't on Function, but all the way on the base
>>> class Value.
>>>
>>> Nick
>>>
>>>>      thanks a lot!
>>>>
>>>>      Best wishes!
>>>>
>>>>                                                    Linhai Song
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From gohman at apple.com  Wed Jan 19 15:01:36 2011
From: gohman at apple.com (Dan Gohman)
Date: Wed, 19 Jan 2011 13:01:36 -0800
Subject: [LLVMdev] induction variable computation not preserving scev
In-Reply-To: <AANLkTinqt1mBGv0aUjUkADOC6CEQsgXUH=iyvm-URMfB@mail.gmail.com>
References: <AANLkTinqt1mBGv0aUjUkADOC6CEQsgXUH=iyvm-URMfB@mail.gmail.com>
Message-ID: <54760F69-501D-4077-B82D-DAD6E9CA928E@apple.com>


On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote:

> Hi,
> 
> I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test failures.

Indvars isn't restructuring the loop there, so it ideally shouldn't
need to call forgetLoop(). Offhand, is it possible that the problem
here is the same as the one in PR8037?

> 
> Would someone be willing to take a look at the failures and figure out why we're getting worse output once this patch is applied? If I had to hazard a guess, I'd say that indvars is probably emitting code that can't be analyzed by SCEV as easily as the original.

It's certainly plausible. It's easy to loose track of things like
overflow behavior when folding casts into arithmetic, for example.

Dan



From criswell at illinois.edu  Wed Jan 19 15:08:16 2011
From: criswell at illinois.edu (John Criswell)
Date: Wed, 19 Jan 2011 15:08:16 -0600
Subject: [LLVMdev] How to get the name and argument of a function
In-Reply-To: <8285a75e191c231030f87197aee5ac54.squirrel@webmail.cs.wisc.edu>
References: <89e0944507495fc8eb3f14dae3633306.squirrel@webmail.cs.wisc.edu>
	<4D34D996.1030806@mxc.ca>
	<7221226ddb884b77fdf4c4525421299c.squirrel@webmail.cs.wisc.edu>
	<4D351751.1030607@illinois.edu>
	<8285a75e191c231030f87197aee5ac54.squirrel@webmail.cs.wisc.edu>
Message-ID: <4D3752C0.40505@illinois.edu>

On 1/19/11 1:47 PM, songlh at cs.wisc.edu wrote:
> Thanks a lot!
>
> I finally fix my problem.
>
> My code is like this:
>
>
> //CallInst* pCall   pCall is a printf called in my situation
> if( ConstantExpr * pCE = dyn_cast<ConstantExpr>( pCall->getArgOperand(0))){
>
>    if( GlobalVariable * pGV = dyn_cast<GlobalVariable>( pCE->getOperand(0))){
>
>      if( ConstantArray * pCA = dyn_cast<ConstantArray>(
>                                    pGV->getInitializer()
>                                    )){
>          Err<<  pCA->getAsString()<<  "\n";
>       }
>    }
>
> }
>
> I find dump() method is very useful, since it can get me some indications
> about which class document I need to check.

I'm glad it works.  On a related note, I noticed that your original code 
iterates through all instructions within an LLVM Module looking for call 
instructions and then only processes those that call printf().

It would probably be more efficient to get a Function * to the printf 
function (Module::getFunction ()) and then iterate through its uses, 
checking each use to see if it is a direct call to printf().  That way, 
the run-time complexity is a linear function of the number of printf 
calls and not a linear function of the size of the program.

-- John T.

> thanks a lot!
>
> Linhai
>
>
>
>
>
>
>
>
>
>> On 1/17/2011 8:53 PM, songlh at cs.wisc.edu wrote:
>>> Thanks a lot!
>>>
>>> I can get the call place now. But still have problems in getting the
>>> argument.
>>>
>>> CallInst * pCall;
>>>
>>> ......
>>>
>>> pCall->getArgOperand(0)->dump();
>>>
>>> I can get "i8* getelementptr inbounds ([5 x i8]* @.str, i32 0, i32 0)"
>> In this particular case, the argument to the call is an LLVM GEP
>> Constant Expression.  It's like a GEP instruction except that all of the
>> GEP arguments are constant, so the result of the GEP is also a
>> constant.  In general, the argument to printf can an LLVM Value *, and
>> there are lots of sub-classes derived from Value.  For example, it could
>> be a GEP ConstantExpr, a Cast ConstExpr, an Instruction, etc., etc.
>>
>> Look at the doxygen docs for the ConstantExpr class.  You can use that
>> information to figure out how to write code that peers into the
>> ConstExpr to see what global value it is indexing off of.
>>
>> -- John T.
>>
>> P.S.  I grew up in Wisconsin and like Badger Hockey at UW-Madison.  Go
>> Bucky!
>>
>>> I think this means that the variable is a global constant string. Do you
>>> know how to get the name of this global string, and how to use the name
>>> to
>>> get the string value?
>>>
>>> Btw: when I use pCall->getArgOperand(0)->getName(), I can only get "".
>>>
>>> thanks a lot!
>>>
>>> Linhai
>>>
>>>> songlh at cs.wisc.edu wrote:
>>>>> Hi everyone:
>>>>>
>>>>>       The code I am analyzing is :
>>>>>
>>>>>       int main()
>>>>>       {
>>>>>           int i = 0;
>>>>>           printf("hello world!");
>>>>>           printf( "%d" , i );
>>>>>       }
>>>>>
>>>>>
>>>>>
>>>>>       I want to get each place where printf is called, and the argument
>>>>> used
>>>>> during that call.
>>>>>
>>>>>       so I write llvm pass code like:
>>>>>
>>>>>       void Myfunction( Function&    F){
>>>>>           for( Function::iterator b = F.begin() , be = F.end() ;
>>>>>            b != be; ++b){
>>>>>               for(BasicBlock::iterator i = b.begin() , ie = b.end();
>>>>>                i != ie; i ++){
>>>>>                   if( isa<CallInst>(&(*i)) || isa<InvokeInst>(&(*i))){
>>>>>                       //how could I get the function name and argument
>>>>>                       //used here
>>>>>                   }
>>>>>               }
>>>>>
>>>>>           }
>>>>>       }
>>>>>
>>>>>
>>>>>       How could I get the function name and the arguments when I know
>>>>> an
>>>>> Instruction is a function call?
>>>> There's a worked example at
>>>> http://wiki.llvm.org/HowTo:_Find_all_call_sites_of_a_function .
>>>>
>>>> With the CallInst/InvokeInst you can query getArgOperand() to get the
>>>> arguments or getCallee() which return a Function -- or it might not. If
>>>> the call is an indirect call (ie., function pointer) then you don't
>>>> know
>>>> what it's calling. Ignoring indirect calls, you can call getName() on a
>>>> function to get its name.
>>>>
>>>> Personally, I rely heavily on the doxygen to find my way around the
>>>> API:
>>>> http://llvm.org/doxygen/hierarchy.html . Look up "CallInst" for
>>>> example.
>>>> The getName() method isn't on Function, but all the way on the base
>>>> class Value.
>>>>
>>>> Nick
>>>>
>>>>>       thanks a lot!
>>>>>
>>>>>       Best wishes!
>>>>>
>>>>>                                                     Linhai Song
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>


From nlewycky at google.com  Wed Jan 19 16:03:52 2011
From: nlewycky at google.com (Nick Lewycky)
Date: Wed, 19 Jan 2011 14:03:52 -0800
Subject: [LLVMdev] induction variable computation not preserving scev
In-Reply-To: <54760F69-501D-4077-B82D-DAD6E9CA928E@apple.com>
References: <AANLkTinqt1mBGv0aUjUkADOC6CEQsgXUH=iyvm-URMfB@mail.gmail.com>
	<54760F69-501D-4077-B82D-DAD6E9CA928E@apple.com>
Message-ID: <AANLkTimTbx3=J_vktaOVLA+pyZ4xmt6OjuU7OKdcQrsT@mail.gmail.com>

On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote:

>
> On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote:
>
> > Hi,
> >
> > I tracked down a bug in indvars where we weren't updating SCEV properly.
> The attached patch shows the fix to this bug with a testcase, but it also
> causes five new test failures.
>
> Indvars isn't restructuring the loop there, so it ideally shouldn't
> need to call forgetLoop().


Hmm? It certainly is, it's changing the condition on the branch instruction
that makes up the loop latch!

Offhand, is it possible that the problem
> here is the same as the one in PR8037?
>

No, that only shows up when you try to run "opt -analyze -indvars
-scalar-evolution" by causing a crash. With that patch in place, you can see
that "opt -analyze -indvars -scalar-evolution" produces different values for
the SCEVs than you get with "opt -indvars | opt -analyze -scalar-evolution"
which led me to add the forgetLoop here.


> > Would someone be willing to take a look at the failures and figure out
> why we're getting worse output once this patch is applied? If I had to
> hazard a guess, I'd say that indvars is probably emitting code that can't be
> analyzed by SCEV as easily as the original.
>
> It's certainly plausible. It's easy to loose track of things like
> overflow behavior when folding casts into arithmetic, for example.
>
> Dan
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110119/32cd4172/attachment.html 

From grosbach at apple.com  Wed Jan 19 16:34:04 2011
From: grosbach at apple.com (Jim Grosbach)
Date: Wed, 19 Jan 2011 14:34:04 -0800
Subject: [LLVMdev] Possible issue with ARM/MC/MachO fixup
In-Reply-To: <AANLkTikRR-kJx_akMpxU6gsh6qvupVF=EL+P08=Dj1Xw@mail.gmail.com>
References: <AANLkTikRR-kJx_akMpxU6gsh6qvupVF=EL+P08=Dj1Xw@mail.gmail.com>
Message-ID: <3C7B9FF2-4920-4C93-BE16-A41A524129DC@apple.com>


On Jan 19, 2011, at 10:41 AM, Jason Kim wrote:

> Hi everyone.
> 
> In ARMAsmBackend.cpp, in routine DarwinARMAsmBackend::ApplyFixup()
> there is a curious call to getFixupKindNumBytes() - which can return
> 1,2, 3, or 4 depending upon the FixupKind
> 
> The code in ApplyFixup() seems to be lifted from the X86.
> 
> AFAIK, the initial Fixup.Offset() is always divisible by 4, at least
> for ARM mode - i.e. it is always at the instruction boundary.
> 
> it looks like adjustFixupValue() is meant to create a mask that can be
> bitwise OR'ed into the full instruction, which is 2 or 4 bytes
> So what does it mean to patch 1 or 3 bytes starting from the
> instruction boundary?
> 

It's just unused in the current implementation. The Fixup offset (the one that originates from the addFixup()) should always be zero.

> I don't know enough about Macho to tell whether this is a bug or not.
> If it isn't, apologies for the noise.

It's not a bug, per se, but the way the ARM fixups are handled needs some refactoring. The fixups shouldn't be quite as "smart" as they are and instead there should be one fixup per contiguous range of bits that need adjusted, and instructions with non-contiguous regions that need fixing up should use multiple fixups on the same instructions. In that situation, it'll be important to use the Fixup offset field to specify the starting byte for the fixup. Otherwise MC gets confused (it wants the fixups in order). The idea is that the adjustFixupValue() function will go away entirely and the MCExpr attached to the fixup will do all of the necessary value fiddling to get the right bits to apply to the instruction.

-Jim

From filcab at gmail.com  Wed Jan 19 17:00:24 2011
From: filcab at gmail.com (Filipe Cabecinhas)
Date: Wed, 19 Jan 2011 23:00:24 +0000
Subject: [LLVMdev] Extending llvm-mc to whole executables/libraries
Message-ID: <D3BC3023D137441EA2E3A17B012BCB84@gmail.com>

Hi,


I want to extend llvm-mc to make it disassemble whole files, instead of sequences of bytes.
Most of the work to read from a Mach-O file is already done by lldb, but that is outside llvm's repository and not useful to llvm-mc (as far as I know).


Is anyone working on something similar?
Is it desirable to have llvm-mc disassemble whole files? Or should I create another project for that?
How do you suggest reading the files? Re-implementing the reading stuff? "Steal" from lldb (I don't know how self-contained the plug-in may be? It could require a big part of lldb)? Any other ideas?


Regards,

Filipe Cabecinhas



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110119/6b2b6b1f/attachment.html 

From bigcheesegs at gmail.com  Thu Jan 20 00:08:33 2011
From: bigcheesegs at gmail.com (Michael Spencer)
Date: Thu, 20 Jan 2011 01:08:33 -0500
Subject: [LLVMdev] Extending llvm-mc to whole executables/libraries
In-Reply-To: <D3BC3023D137441EA2E3A17B012BCB84@gmail.com>
References: <D3BC3023D137441EA2E3A17B012BCB84@gmail.com>
Message-ID: <AANLkTik4Et2LNwWDtUS7-yNdRtRS4D-8qR53iWF-ozJM@mail.gmail.com>

On Wed, Jan 19, 2011 at 6:00 PM, Filipe Cabecinhas <filcab at gmail.com> wrote:
> Hi,
> I want to extend llvm-mc to make it disassemble whole files, instead of
> sequences of bytes.
> Most of the work to read from a Mach-O file is already done by lldb, but
> that is outside llvm's repository and not useful to llvm-mc (as far as I
> know).
> Is anyone working on something similar?
> Is it desirable to have llvm-mc disassemble whole files? Or should I create
> another project for that?
> How do you suggest reading the files? Re-implementing the reading stuff?
> "Steal" from lldb (I don't know how self-contained the plug-in may be? It
> could require a big part of lldb)? Any other ideas?
> Regards,
>
> ??Filipe Cabecinhas

I'm working on object file support, and am just about to commit
llvm-objdump which does just what you want. It is separate from, but
uses, MC.

I gave a talk at the last conference which explains the architecture
and future plans: http://llvm.org/devmtg/2010-11/

- Michael Spencer


From filcab at gmail.com  Thu Jan 20 04:37:04 2011
From: filcab at gmail.com (Filipe Cabecinhas)
Date: Thu, 20 Jan 2011 10:37:04 +0000
Subject: [LLVMdev] Extending llvm-mc to whole executables/libraries
In-Reply-To: <AANLkTik4Et2LNwWDtUS7-yNdRtRS4D-8qR53iWF-ozJM@mail.gmail.com>
References: <D3BC3023D137441EA2E3A17B012BCB84@gmail.com>
	<AANLkTik4Et2LNwWDtUS7-yNdRtRS4D-8qR53iWF-ozJM@mail.gmail.com>
Message-ID: <C78BECB5DE834FB5B7DA780633BA72BD@gmail.com>

Thanks


I'll be waiting for it, then.


Regards,

Filipe Cabecinhas

On Thursday, January 20, 2011 at 06:08, Michael Spencer wrote:

> On Wed, Jan 19, 2011 at 6:00 PM, Filipe Cabecinhas <filcab at gmail.com> wrote:
> 
> > Hi,
> > I want to extend llvm-mc to make it disassemble whole files, instead of
> > sequences of bytes.
> > Most of the work to read from a Mach-O file is already done by lldb, but
> > that is outside llvm's repository and not useful to llvm-mc (as far as I
> > know).
> > Is anyone working on something similar?
> > Is it desirable to have llvm-mc disassemble whole files? Or should I create
> > another project for that?
> > How do you suggest reading the files? Re-implementing the reading stuff?
> > "Steal" from lldb (I don't know how self-contained the plug-in may be? It
> > could require a big part of lldb)? Any other ideas?
> > Regards,
> > 
> > Filipe Cabecinhas
> > 
> > 
> 
> I'm working on object file support, and am just about to commit
> llvm-objdump which does just what you want. It is separate from, but
> uses, MC.
> 
> I gave a talk at the last conference which explains the architecture
> and future plans: http://llvm.org/devmtg/2010-11/
> 
> - Michael Spencer
> 
> 
> 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/f1f12a06/attachment.html 

From baldrick at free.fr  Thu Jan 20 04:51:08 2011
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 20 Jan 2011 11:51:08 +0100
Subject: [LLVMdev] [llvm-commits] [llvm] r123754 - in /llvm/trunk:
 lib/Analysis/InstructionSimplify.cpp
 test/Transforms/InstSimplify/2010-12-20-Distribute.ll
In-Reply-To: <8DB0B991C1E7438E9268EEBAB8B147DF@pc07654>
References: <20110118092458.AD9482A6C12C@llvm.org>
	<8DB0B991C1E7438E9268EEBAB8B147DF@pc07654>
Message-ID: <4D38139C.8070005@free.fr>

There's some interest in my "auto-simplifier", which is nice :), so let me
explain a bit about it.

On 19/01/11 19:35, Sandeep Patel wrote:
 > You've mentioned your auto-simplifier a few times now and curiosity is
 > getting the better of me. Can you explain it a bit more?

On 20/01/11 00:32, Nuno Lopes wrote:
 > Just out of curiosity, what's this auto-simplifier? Have you built some
 > superoptimizer or something similar?
 > I'm just asking because building a tool to generate the instruction simplifier
 > automatically is relatively high on my TODO list and I don't want to duplicate
 > work :)

The auto-simplifier is a very simple kind of super-optimizer.  It tries to find
optimizations suitable for InstructionSimplify [instsimplify].  The difference
between instsimplify and instcombine is that instcombine is allowed to create
new instructions while instsimplify needs to simplify expressions to already
existing subexpressions present inside the existing expression.  For example
instsimplify can turn this
   (X + Y) - X
into
   Y
because Y was already present inside the original expression, but it can't turn
   X - (X + Y)
into
   -Y
because -Y was not present inside the original expression.  Instcombine will
happily do the second transform because it doesn't have this limitation.
Instsimplify is allowed to produce constants that were original present, for
example it is allowed to turn
   X & X
into
   0

Given an expression the auto-simplifier finds subexpressions that always compute
the same result as the original expression (beware: it may sometimes get this
wrong, especially for large expressions, and say that it simplifies when it
doesn't;  on the other hand it should never say that an expression doesn't
simplify when it does - that's would be a bug).

You can get it like this: svn co svn://topo.math.u-psud.fr/harvest
As explained in the README there are two main parts: (1) harvesting expressions
from IR (currently only side-effect free integer expressions are supported), and
(2) looking for simplifications.

You can use it something like this to harvest IR sequences from the optimized
clang output for a file, sort them by order of popularity, and look for ones
that simplify:

   clang -c -emit-llvm -O2 file.c -o - | opt -load=./harvest.so -harvest 
-disable-output | sort | uniq -c | sort -n -r | grep -o "[^ ]*$" | ./solve

For example, doing this on gcc-as-one-big-file finds some simplifications:

Input: 06:07:06:07:07:0e:16:18:0e:09:01:00:-0004:1b:25
x = (((X + Y) >>l ..1.) & Z) + ..1.
Root: (x == 0) ? 1 : (zext x)
PASS:
x = (((X + Y) >>l ..1.) & Z) + ..1.
x == 0
constant folds to 0 01.1 11.0

Here the first three lines describe input expression.  The first line prints it
in its encoded normalized form (good for sorting on etc), the next two pretty
print it.  The expression is "(x == 0) ? 1 : (zext x)" where x is short-hand for
"(((X + Y) >>l ..1.) & Z) + ..1." as explained in the second line.  Here "..1."
stands for a constant which is not known but is known to be a power of two (it
is supposed to represent a single bit set to 1 in a sea of bits ....).  Anyway,
you see that the root of the expression is a select ("?") conditioned on x==0.
PASS means that it found a simplification.  The simplification is that "x==0"
is always false, i.e. constant folds to zero.  It prints that it constant folds
to one of the constants 0 (zero), 01.1 (max positive value, i.e. all bits one
except for the top bit), 11.0 (minus 2, i.e. all bits one except for the bottom
bit).  The reason it prints them all is that the result of the compare has i1
type and for a one bit type these three constants are all equal so it can't
distinguish between them.  Exercise: is this simplification correct (it is)? :)

Here's another one:

Input: 07:06:0f:-0002:00:-0005:1b:25
x = ..1.
Root: (X == 0) ? x : (x - X)
PASS:
x = ..1.
(X == 0) ? x : (x - X)
simplifies to
x = ..1.
x - X

It says that the select "(X == 0) ? x : (x - X)" simplifies to "x - X".
Well this is true, since if X is zero then x equals x-X.

Ciao, Duncan.

 >> Author: baldrick
 >> Date: Tue Jan 18 03:24:58 2011
 >> New Revision: 123754
 >>
 >> URL: http://llvm.org/viewvc/llvm-project?rev=123754&view=rev
 >> Log:
 >> Simplify (X<<1)-X into X. According to my auto-simplier this is the most
 >> common missed
 >> simplification in fully optimized code. It occurs sporadically in the
 >> testsuite, and
 >> many times in 403.gcc: the final bitcode has 131 fewer subtractions after this
 >> change.
 >> The reason that the multiplies are not eliminated is the same reason that
 >> instcombine
 >> did not catch this: they are used by other instructions (instcombine catches
 >> this with
 >> a more general transform which in general is only profitable if the operands
 >> have only
 >> one use).

From filcab at gmail.com  Thu Jan 20 05:37:41 2011
From: filcab at gmail.com (Filipe Cabecinhas)
Date: Thu, 20 Jan 2011 11:37:41 +0000
Subject: [LLVMdev] Warnings when compiling llvm+clang (Mac OS X system gcc)
Message-ID: <6721ECAB16D345739CC0E3F3E3E17424@gmail.com>

Hi,


There are some warnings in the LLVM and clang code bases:


----------------------------
llvm[0]: Compiling RegAllocGreedy.cpp for Release+Asserts build
/Users/filcab/dev/stuff/llvm/llvm/include/llvm/ADT/SmallVector.h: In member function ?void<unnamed>::RAGreedy::calcLiveBlockInfo(llvm::LiveInterval&)?:
/Users/filcab/dev/stuff/llvm/llvm/include/llvm/ADT/SmallVector.h:325: warning: ?BC.llvm::SpillPlacement::BlockConstraint::Exit? is used uninitialized in this function
----------------------------
^^ The error repeats several times.


It seems the error occurs when push_back copies the received object, which is a struct:
struct BlockConstraint {
unsigned Number; ///< Basic block number (from MBB::getNumber()).
BorderConstraint Entry : 8; ///< Constraint on block entry.
BorderConstraint Exit : 8; ///< Constraint on block exit.
};



Where only the Number member is initialized. Couldn't we initialize the other members to invalid values?


In clang, the warning is:


----------------------------
makellvm[0]: Compiling SemaTemplateVariadic.cpp for Release+Asserts build
/Users/filcab/dev/stuff/llvm/llvm/tools/clang/lib/Sema/SemaTemplateVariadic.cpp: In member function ?bool clang::Sema::CheckParameterPacksForExpansion(clang::SourceLocation, clang::SourceRange, const clang::UnexpandedParameterPack*, unsigned int, const clang::MultiLevelTemplateArgumentList&, bool&, bool&, llvm::Optional<unsigned int>&)?:
/Users/filcab/dev/stuff/llvm/llvm/tools/clang/lib/Sema/SemaTemplateVariadic.cpp:479: warning: ?Index? may be used uninitialized in this function
/Users/filcab/dev/stuff/llvm/llvm/tools/clang/lib/Sema/SemaTemplateVariadic.cpp:478: warning: ?Depth? may be used uninitialized in this function
----------------------------



It seems the problem gcc is seeing is:


the dyn_cast to cons TemplateTypeParmType fails
isa<ParlVarDecl>(ND) is true
Instantiation && Instantiation->is<DeclArgumentPack *>() is true
CurrentInstantiationScope->getPartiallySubstitutedPack() is true


I don't know enough about clang to know how feasible this path is, so I defer to this list.




BTW, clang++ doesn't warn about any of these "problems" (by using make CXX=clang++)


Regards,


Filipe Cabecinhas



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/8bfebad3/attachment.html 

From nunoplopes at sapo.pt  Thu Jan 20 05:48:14 2011
From: nunoplopes at sapo.pt (Nuno Lopes)
Date: Thu, 20 Jan 2011 11:48:14 -0000
Subject: [LLVMdev] [llvm-commits] [llvm] r123754 - in /llvm/trunk:
	lib/Analysis/InstructionSimplify.cpp
	test/Transforms/InstSimplify/2010-12-20-Distribute.ll
In-Reply-To: <4D38139C.8070005@free.fr>
References: <20110118092458.AD9482A6C12C@llvm.org>
	<8DB0B991C1E7438E9268EEBAB8B147DF@pc07654>
	<4D38139C.8070005@free.fr>
Message-ID: <03DBF41ECA58490DB34ADF183A49AA3F@pc07654>

Thanks for the nice explanation and for making the code available!
Nuno

----- Original Message -----
> There's some interest in my "auto-simplifier", which is nice :), so let me
> explain a bit about it.
>
> On 19/01/11 19:35, Sandeep Patel wrote:
> > You've mentioned your auto-simplifier a few times now and curiosity is
> > getting the better of me. Can you explain it a bit more?
>
> On 20/01/11 00:32, Nuno Lopes wrote:
> > Just out of curiosity, what's this auto-simplifier? Have you built some
> > superoptimizer or something similar?
> > I'm just asking because building a tool to generate the instruction 
> > simplifier
> > automatically is relatively high on my TODO list and I don't want to 
> > duplicate
> > work :)
>
> The auto-simplifier is a very simple kind of super-optimizer.  It tries to 
> find
> optimizations suitable for InstructionSimplify [instsimplify].  The 
> difference
> between instsimplify and instcombine is that instcombine is allowed to 
> create
> new instructions while instsimplify needs to simplify expressions to 
> already
> existing subexpressions present inside the existing expression.  For 
> example
> instsimplify can turn this
>   (X + Y) - X
> into
>   Y
> because Y was already present inside the original expression, but it can't 
> turn
>   X - (X + Y)
> into
>   -Y
> because -Y was not present inside the original expression.  Instcombine 
> will
> happily do the second transform because it doesn't have this limitation.
> Instsimplify is allowed to produce constants that were original present, 
> for
> example it is allowed to turn
>   X & X
> into
>   0
>
> Given an expression the auto-simplifier finds subexpressions that always 
> compute
> the same result as the original expression (beware: it may sometimes get 
> this
> wrong, especially for large expressions, and say that it simplifies when 
> it
> doesn't;  on the other hand it should never say that an expression doesn't
> simplify when it does - that's would be a bug).
>
> You can get it like this: svn co svn://topo.math.u-psud.fr/harvest
> As explained in the README there are two main parts: (1) harvesting 
> expressions
> from IR (currently only side-effect free integer expressions are 
> supported), and
> (2) looking for simplifications.
>
> You can use it something like this to harvest IR sequences from the 
> optimized
> clang output for a file, sort them by order of popularity, and look for 
> ones
> that simplify:
>
>   clang -c -emit-llvm -O2 file.c -o - | 
> opt -load=./harvest.so -harvest -disable-output | sort | uniq -c | 
> sort -n -r | grep -o "[^ ]*$" | ./solve
>
> For example, doing this on gcc-as-one-big-file finds some simplifications:
>
> Input: 06:07:06:07:07:0e:16:18:0e:09:01:00:-0004:1b:25
> x = (((X + Y) >>l ..1.) & Z) + ..1.
> Root: (x == 0) ? 1 : (zext x)
> PASS:
> x = (((X + Y) >>l ..1.) & Z) + ..1.
> x == 0
> constant folds to 0 01.1 11.0
>
> Here the first three lines describe input expression.  The first line 
> prints it
> in its encoded normalized form (good for sorting on etc), the next two 
> pretty
> print it.  The expression is "(x == 0) ? 1 : (zext x)" where x is 
> short-hand for
> "(((X + Y) >>l ..1.) & Z) + ..1." as explained in the second line.  Here 
> "..1."
> stands for a constant which is not known but is known to be a power of two 
> (it
> is supposed to represent a single bit set to 1 in a sea of bits ....). 
> Anyway,
> you see that the root of the expression is a select ("?") conditioned on 
> x==0.
> PASS means that it found a simplification.  The simplification is that 
> "x==0"
> is always false, i.e. constant folds to zero.  It prints that it constant 
> folds
> to one of the constants 0 (zero), 01.1 (max positive value, i.e. all bits 
> one
> except for the top bit), 11.0 (minus 2, i.e. all bits one except for the 
> bottom
> bit).  The reason it prints them all is that the result of the compare has 
> i1
> type and for a one bit type these three constants are all equal so it 
> can't
> distinguish between them.  Exercise: is this simplification correct (it 
> is)? :)
>
> Here's another one:
>
> Input: 07:06:0f:-0002:00:-0005:1b:25
> x = ..1.
> Root: (X == 0) ? x : (x - X)
> PASS:
> x = ..1.
> (X == 0) ? x : (x - X)
> simplifies to
> x = ..1.
> x - X
>
> It says that the select "(X == 0) ? x : (x - X)" simplifies to "x - X".
> Well this is true, since if X is zero then x equals x-X.
>
> Ciao, Duncan. 


From jdkunk3 at gmail.com  Thu Jan 20 07:37:18 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Thu, 20 Jan 2011 08:37:18 -0500
Subject: [LLVMdev] [LLVMDev] Live Intervals and Finding the next usage
Message-ID: <AANLkTikMBjbDecv=GchN3S8sfGG=C00jNdeQZnSxiJk6@mail.gmail.com>

I have a live interval, and I would like to find out what SlotIndex the next
use the register will occur? Is there any way to map a live interval back
into instructions or SlotIndexes or blocks used by?

- Thanks
Jeff Kunkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/fd429dbd/attachment.html 

From jnspaulsson at hotmail.com  Thu Jan 20 08:19:25 2011
From: jnspaulsson at hotmail.com (Jonas Paulsson)
Date: Thu, 20 Jan 2011 15:19:25 +0100
Subject: [LLVMdev] SelectionDAG, loops
Message-ID: <SNT106-W61271EC465C1B6BA5D1B3BB1F90@phx.gbl>


Hi,

I am trying to rewrite loop addressing to suit my target. I wonder if there is a simple way to find out if the current SelectionDAG is a loop-body?

I tried to rewrite LLVM code to do address arithmetic, ie %nextaddr = add i16* %curraddr, 4, but I could not find a way to make this work.

thanks,

Jonas

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/8abf74a5/attachment.html 

From jdkunk3 at gmail.com  Thu Jan 20 08:39:46 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Thu, 20 Jan 2011 09:39:46 -0500
Subject: [LLVMdev] [LLVMDev] Live Intervals and Finding the next usage
In-Reply-To: <AANLkTikMBjbDecv=GchN3S8sfGG=C00jNdeQZnSxiJk6@mail.gmail.com>
References: <AANLkTikMBjbDecv=GchN3S8sfGG=C00jNdeQZnSxiJk6@mail.gmail.com>
Message-ID: <AANLkTik8GHnz52VWBoJwf3bwME8Ei+TKwNzY=7m+4+8u@mail.gmail.com>

I am looking for the slot index of a register around the given slot index
Min. Is there a better way than the linear search:

...
findDefUsesAroundIndex( LiveInterval* li, SlotIndex Min )
...
  for( MachineOperand * mo = MRI->getRegUseDefListHead(li->reg);
    mo; mo = mo->getNextOperandForReg() )
  {
    SlotIndex si = SI->getInstructionIndex( use.getOperand().getParent() );
    if( Min.distance(si) >= 0 )
...

- Thanks
Jeff Kunkel


On Thu, Jan 20, 2011 at 8:37 AM, Jeff Kunkel <jdkunk3 at gmail.com> wrote:

> I have a live interval, and I would like to find out what SlotIndex the
> next use the register will occur? Is there any way to map a live interval
> back into instructions or SlotIndexes or blocks used by?
>
> - Thanks
> Jeff Kunkel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/543dc29d/attachment.html 

From jdkunk3 at gmail.com  Thu Jan 20 08:41:16 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Thu, 20 Jan 2011 09:41:16 -0500
Subject: [LLVMdev] [LLVMDev] Live Intervals and Finding the next usage
In-Reply-To: <AANLkTik8GHnz52VWBoJwf3bwME8Ei+TKwNzY=7m+4+8u@mail.gmail.com>
References: <AANLkTikMBjbDecv=GchN3S8sfGG=C00jNdeQZnSxiJk6@mail.gmail.com>
	<AANLkTik8GHnz52VWBoJwf3bwME8Ei+TKwNzY=7m+4+8u@mail.gmail.com>
Message-ID: <AANLkTi=cucTt6dN6POEanpWt_FEEDitGdGbend0XgFXb@mail.gmail.com>

On Thu, Jan 20, 2011 at 9:39 AM, Jeff Kunkel <jdkunk3 at gmail.com> wrote:

> I am looking for the slot index of a register around the given slot index
> Min. Is there a better way than the linear search:
>
> ...
> findDefUsesAroundIndex( LiveInterval* li, SlotIndex Min )
> ...
>   for( MachineOperand * mo = MRI->getRegUseDefListHead(li->reg);
>     mo; mo = mo->getNextOperandForReg() )
>   {
>     SlotIndex si = SI->getInstructionIndex( mo->getParent() );// changed
>     if( Min.distance(si) >= 0 )
> ...
>
> - Thanks
> Jeff Kunkel
>
>
> On Thu, Jan 20, 2011 at 8:37 AM, Jeff Kunkel <jdkunk3 at gmail.com> wrote:
>
>> I have a live interval, and I would like to find out what SlotIndex the
>> next use the register will occur? Is there any way to map a live interval
>> back into instructions or SlotIndexes or blocks used by?
>>
>> - Thanks
>> Jeff Kunkel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/dacee19e/attachment.html 

From stoklund at 2pi.dk  Thu Jan 20 10:35:03 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Thu, 20 Jan 2011 08:35:03 -0800
Subject: [LLVMdev] [LLVMDev] Live Intervals and Finding the next usage
In-Reply-To: <AANLkTikMBjbDecv=GchN3S8sfGG=C00jNdeQZnSxiJk6@mail.gmail.com>
References: <AANLkTikMBjbDecv=GchN3S8sfGG=C00jNdeQZnSxiJk6@mail.gmail.com>
Message-ID: <6CCB5BAD-9F07-4510-AAED-F3487C415F67@2pi.dk>


On Jan 20, 2011, at 5:37 AM, Jeff Kunkel wrote:

> I have a live interval, and I would like to find out what SlotIndex the next use the register will occur? Is there any way to map a live interval back into instructions or SlotIndexes or blocks used by?

Not really, you have to use the use-def chain. See SplitAnalysis::analyzeUses().

/jakob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/c34b5fca/attachment.bin 

From clattner at apple.com  Thu Jan 20 11:12:34 2011
From: clattner at apple.com (Chris Lattner)
Date: Thu, 20 Jan 2011 09:12:34 -0800
Subject: [LLVMdev] SelectionDAG, loops
In-Reply-To: <SNT106-W61271EC465C1B6BA5D1B3BB1F90@phx.gbl>
References: <SNT106-W61271EC465C1B6BA5D1B3BB1F90@phx.gbl>
Message-ID: <040238D4-7796-4277-9408-6903C52EBC6D@apple.com>


On Jan 20, 2011, at 6:19 AM, Jonas Paulsson wrote:

> Hi,
> 
> I am trying to rewrite loop addressing to suit my target. I wonder if there is a simple way to find out if the current SelectionDAG is a loop-body?
> 
> I tried to rewrite LLVM code to do address arithmetic, ie %nextaddr = add i16* %curraddr, 4, but I could not find a way to make this work.

Hi Jonas,

I'm not sure exactly what you're doing here, but it sounds like what the LoopStrengthReduction pass does.  To get it to work for your target you need to implement the TargetLoweringInfo hooks that it uses.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/b9b5e9fc/attachment-0001.html 

From jdkunk3 at gmail.com  Thu Jan 20 11:18:59 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Thu, 20 Jan 2011 12:18:59 -0500
Subject: [LLVMdev] [LLVMDev] Live Intervals and Finding the next usage
In-Reply-To: <6CCB5BAD-9F07-4510-AAED-F3487C415F67@2pi.dk>
References: <AANLkTikMBjbDecv=GchN3S8sfGG=C00jNdeQZnSxiJk6@mail.gmail.com>
	<6CCB5BAD-9F07-4510-AAED-F3487C415F67@2pi.dk>
Message-ID: <AANLkTi=2zgc3rUumd3qV0xOtqO4C+WnpxaxVoX9zhXhX@mail.gmail.com>

If I had more than just the one requirement, I would use SplitAnalysis. It
provides quite a descriptive list of dependencies for the live interval.
However, since I only have the one requirement, I will retain the current
code. Although, I will use the
MachineRegisterInfo::reg_nodbg_iterator<http://llvm.org/docs/doxygen/html/classllvm_1_1MachineRegisterInfo.html#af7083a77ea4e68dd4982ae6e03b6ced0>.
I believe this is what I need.

Thanks,
Jeff Kunkel

On Thu, Jan 20, 2011 at 11:35 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> On Jan 20, 2011, at 5:37 AM, Jeff Kunkel wrote:
>
> > I have a live interval, and I would like to find out what SlotIndex the
> next use the register will occur? Is there any way to map a live interval
> back into instructions or SlotIndexes or blocks used by?
>
> Not really, you have to use the use-def chain. See
> SplitAnalysis::analyzeUses().
>
> /jakob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/b64f8207/attachment.html 

From jdkunk3 at gmail.com  Thu Jan 20 11:43:47 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Thu, 20 Jan 2011 12:43:47 -0500
Subject: [LLVMdev] [LLVMDev] Block Layout
Message-ID: <AANLkTinA52eFZetp3uOGhXiytC4C0SfSG9nW+Gghh+jB@mail.gmail.com>

I am wondering which pass is responsible for laying out the basic blocks in
an order advantageous for live intervals?

- Thanks
- Jeff Kunkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/11256b1f/attachment.html 

From stoklund at 2pi.dk  Thu Jan 20 12:04:33 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Thu, 20 Jan 2011 10:04:33 -0800
Subject: [LLVMdev] [LLVMDev] Block Layout
In-Reply-To: <AANLkTinA52eFZetp3uOGhXiytC4C0SfSG9nW+Gghh+jB@mail.gmail.com>
References: <AANLkTinA52eFZetp3uOGhXiytC4C0SfSG9nW+Gghh+jB@mail.gmail.com>
Message-ID: <3B4DD019-7CCB-46B5-A075-FE70B33C3C54@2pi.dk>


On Jan 20, 2011, at 9:43 AM, Jeff Kunkel wrote:

> I am wondering which pass is responsible for laying out the basic blocks in an order advantageous for live intervals?

I don't think any passes are trying to do block layout until after register allocation.

/jakob



From venkatra at cs.wisc.edu  Thu Jan 20 12:27:24 2011
From: venkatra at cs.wisc.edu (Venkatraman Govindaraju)
Date: Thu, 20 Jan 2011 12:27:24 -0600
Subject: [LLVMdev] Modifying the patterns/ instruction selection phase
 in LLVM 2.7
In-Reply-To: <1423349269.42770.1295414338973.JavaMail.root@mail.cs.ucla.edu>
References: <58690641.42708.1295413442635.JavaMail.root@mail.cs.ucla.edu>
	<1423349269.42770.1295414338973.JavaMail.root@mail.cs.ucla.edu>
Message-ID: <AANLkTinv_vf9rCMqKAMO7O6+oFsqOQCs+6N1wE-wwsiY@mail.gmail.com>

I have similar requirements for my project. This is what I do.

  1. Add a new intrinsic function to LLVM that corresponds to
"functions with particular type of function names".
      The steps to create intrinsic function is documented in
http://llvm.org/docs/ExtendingLLVM.html#intrinsic.
  2. Create a lowering pass that lowers "functions with particular
type" ( eg. p0, p1) to the intrinsic.
  3. Create a instruction pattern in SparcInstrInfo.td that matches
the intrinsic.
      From the arguments to the intrinsic function,  encode the
"<number>"  and output a "sethi" instruction.

Thanks,
Venkatraman


On Tue, Jan 18, 2011 at 11:18 PM, Raghu Prabhakar <raghu at cs.ucla.edu> wrote:
> Hello all,
>
> I am trying to modify the Sparc backend to do something for my team's project, to do the following.
>
> Whenever the backend encounters a call to one particular type of function names (functions like p0(), p1()..etc), I want the backend to generate a "sethi %g0, <number>", and NOT a "call p0, call p1..." instruction. However, the backend should work as usual for any other function name.
>
> Now I figured that there are two ways to do this :
> 1) Modifying the "SparcISelLowering.cpp" to emit a special SDNode (with a special opcode that I have introduced into SPISD namespace) whenever it finds a "call @p0" in the LowerCall function. This node should have an entry in the "SparcInstrInfo.td" file.
>
> 2) No modifications to the Lowering phase. However, the pattern corresponding to the "sethi" instruction must be modified/new pattern added which corresponds to "call p0" kind of selectionDAG nodes.
>
> In either case, I am a bit confused about how tblgen's pattern representation scheme works. One more issue is that the destination register of "sethi %g0, <NUM>" HAS to be %g0 (which makes it a no-op on an actual sparc machine..I'm using a simulator), and <NUM> depends on p0 and its operands. There are ways where the certain registers required can be hard-assigned during instruction selection itself, but I'm unsure as to how to do that. Am I looking at the right set of files? Is there a better way to accomplish what I'm trying to do?
>
> I'm relatively new to LLVM, so I have some trouble freely navigating through the source in spite of being heavily documented.
>
> Any suggestions is of great help.
>
> Thanks.
> Raghu.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From criswell at illinois.edu  Thu Jan 20 12:31:04 2011
From: criswell at illinois.edu (John Criswell)
Date: Thu, 20 Jan 2011 12:31:04 -0600
Subject: [LLVMdev] Modifying the patterns/ instruction selection phase
 in LLVM 2.7
In-Reply-To: <AANLkTinv_vf9rCMqKAMO7O6+oFsqOQCs+6N1wE-wwsiY@mail.gmail.com>
References: <58690641.42708.1295413442635.JavaMail.root@mail.cs.ucla.edu>	<1423349269.42770.1295414338973.JavaMail.root@mail.cs.ucla.edu>
	<AANLkTinv_vf9rCMqKAMO7O6+oFsqOQCs+6N1wE-wwsiY@mail.gmail.com>
Message-ID: <4D387F68.4010803@illinois.edu>

On 1/20/11 12:27 PM, Venkatraman Govindaraju wrote:

Just out of curiosity, have either of you considered writing an LLVM 
transform that simply replaces these call instructions with inline 
assembly code that does what you want?  If that works, it seems much 
simpler than modifying/enhancing the code generator.

-- John T.

> I have similar requirements for my project. This is what I do.
>
>    1. Add a new intrinsic function to LLVM that corresponds to
> "functions with particular type of function names".
>        The steps to create intrinsic function is documented in
> http://llvm.org/docs/ExtendingLLVM.html#intrinsic.
>    2. Create a lowering pass that lowers "functions with particular
> type" ( eg. p0, p1) to the intrinsic.
>    3. Create a instruction pattern in SparcInstrInfo.td that matches
> the intrinsic.
>        From the arguments to the intrinsic function,  encode the
> "<number>"  and output a "sethi" instruction.
>
> Thanks,
> Venkatraman
>
>
> On Tue, Jan 18, 2011 at 11:18 PM, Raghu Prabhakar<raghu at cs.ucla.edu>  wrote:
>> Hello all,
>>
>> I am trying to modify the Sparc backend to do something for my team's project, to do the following.
>>
>> Whenever the backend encounters a call to one particular type of function names (functions like p0(), p1()..etc), I want the backend to generate a "sethi %g0,<number>", and NOT a "call p0, call p1..." instruction. However, the backend should work as usual for any other function name.
>>
>> Now I figured that there are two ways to do this :
>> 1) Modifying the "SparcISelLowering.cpp" to emit a special SDNode (with a special opcode that I have introduced into SPISD namespace) whenever it finds a "call @p0" in the LowerCall function. This node should have an entry in the "SparcInstrInfo.td" file.
>>
>> 2) No modifications to the Lowering phase. However, the pattern corresponding to the "sethi" instruction must be modified/new pattern added which corresponds to "call p0" kind of selectionDAG nodes.
>>
>> In either case, I am a bit confused about how tblgen's pattern representation scheme works. One more issue is that the destination register of "sethi %g0,<NUM>" HAS to be %g0 (which makes it a no-op on an actual sparc machine..I'm using a simulator), and<NUM>  depends on p0 and its operands. There are ways where the certain registers required can be hard-assigned during instruction selection itself, but I'm unsure as to how to do that. Am I looking at the right set of files? Is there a better way to accomplish what I'm trying to do?
>>
>> I'm relatively new to LLVM, so I have some trouble freely navigating through the source in spite of being heavily documented.
>>
>> Any suggestions is of great help.
>>
>> Thanks.
>> Raghu.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From venkatra at cs.wisc.edu  Thu Jan 20 13:01:11 2011
From: venkatra at cs.wisc.edu (Venkatraman Govindaraju)
Date: Thu, 20 Jan 2011 13:01:11 -0600
Subject: [LLVMdev] Modifying the patterns/ instruction selection phase
 in LLVM 2.7
In-Reply-To: <4D387F68.4010803@illinois.edu>
References: <58690641.42708.1295413442635.JavaMail.root@mail.cs.ucla.edu>
	<1423349269.42770.1295414338973.JavaMail.root@mail.cs.ucla.edu>
	<AANLkTinv_vf9rCMqKAMO7O6+oFsqOQCs+6N1wE-wwsiY@mail.gmail.com>
	<4D387F68.4010803@illinois.edu>
Message-ID: <AANLkTi=QU_HTS+cb-JWMsucY7QxRjV7gXSuRERCo6hPf@mail.gmail.com>

For my case, I can't replace these call instructions with inline
assembly code because I need to encode the registers into the
"number".

For instance, if the call instruction is  %result = call i32 @foo(i32
%a)  and the result is assigned to register %l0 and the variable "a"
to register %l1,  then I encode all foo, %l0 and %l1 and generate a
sethi instruction.

thanks,
Venkatraman



On Thu, Jan 20, 2011 at 12:31 PM, John Criswell <criswell at illinois.edu> wrote:
> On 1/20/11 12:27 PM, Venkatraman Govindaraju wrote:
>
> Just out of curiosity, have either of you considered writing an LLVM
> transform that simply replaces these call instructions with inline assembly
> code that does what you want? ?If that works, it seems much simpler than
> modifying/enhancing the code generator.
>
> -- John T.
>
>> I have similar requirements for my project. This is what I do.
>>
>> ? 1. Add a new intrinsic function to LLVM that corresponds to
>> "functions with particular type of function names".
>> ? ? ? The steps to create intrinsic function is documented in
>> http://llvm.org/docs/ExtendingLLVM.html#intrinsic.
>> ? 2. Create a lowering pass that lowers "functions with particular
>> type" ( eg. p0, p1) to the intrinsic.
>> ? 3. Create a instruction pattern in SparcInstrInfo.td that matches
>> the intrinsic.
>> ? ? ? From the arguments to the intrinsic function, ?encode the
>> "<number>" ?and output a "sethi" instruction.
>>
>> Thanks,
>> Venkatraman
>>
>>
>> On Tue, Jan 18, 2011 at 11:18 PM, Raghu Prabhakar<raghu at cs.ucla.edu>
>> ?wrote:
>>>
>>> Hello all,
>>>
>>> I am trying to modify the Sparc backend to do something for my team's
>>> project, to do the following.
>>>
>>> Whenever the backend encounters a call to one particular type of function
>>> names (functions like p0(), p1()..etc), I want the backend to generate a
>>> "sethi %g0,<number>", and NOT a "call p0, call p1..." instruction. However,
>>> the backend should work as usual for any other function name.
>>>
>>> Now I figured that there are two ways to do this :
>>> 1) Modifying the "SparcISelLowering.cpp" to emit a special SDNode (with a
>>> special opcode that I have introduced into SPISD namespace) whenever it
>>> finds a "call @p0" in the LowerCall function. This node should have an entry
>>> in the "SparcInstrInfo.td" file.
>>>
>>> 2) No modifications to the Lowering phase. However, the pattern
>>> corresponding to the "sethi" instruction must be modified/new pattern added
>>> which corresponds to "call p0" kind of selectionDAG nodes.
>>>
>>> In either case, I am a bit confused about how tblgen's pattern
>>> representation scheme works. One more issue is that the destination register
>>> of "sethi %g0,<NUM>" HAS to be %g0 (which makes it a no-op on an actual
>>> sparc machine..I'm using a simulator), and<NUM> ?depends on p0 and its
>>> operands. There are ways where the certain registers required can be
>>> hard-assigned during instruction selection itself, but I'm unsure as to how
>>> to do that. Am I looking at the right set of files? Is there a better way to
>>> accomplish what I'm trying to do?
>>>
>>> I'm relatively new to LLVM, so I have some trouble freely navigating
>>> through the source in spite of being heavily documented.
>>>
>>> Any suggestions is of great help.
>>>
>>> Thanks.
>>> Raghu.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From gohman at apple.com  Thu Jan 20 13:23:47 2011
From: gohman at apple.com (Dan Gohman)
Date: Thu, 20 Jan 2011 11:23:47 -0800
Subject: [LLVMdev] induction variable computation not preserving scev
In-Reply-To: <AANLkTimTbx3=J_vktaOVLA+pyZ4xmt6OjuU7OKdcQrsT@mail.gmail.com>
References: <AANLkTinqt1mBGv0aUjUkADOC6CEQsgXUH=iyvm-URMfB@mail.gmail.com>
	<54760F69-501D-4077-B82D-DAD6E9CA928E@apple.com>
	<AANLkTimTbx3=J_vktaOVLA+pyZ4xmt6OjuU7OKdcQrsT@mail.gmail.com>
Message-ID: <39B7D225-68BC-4B19-A716-BC8CF4BC8709@apple.com>


On Jan 19, 2011, at 2:03 PM, Nick Lewycky wrote:

> On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote:
> 
> On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote:
> 
> > Hi,
> >
> > I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test failures.
> 
> Indvars isn't restructuring the loop there, so it ideally shouldn't
> need to call forgetLoop().
> 
> Hmm? It certainly is, it's changing the condition on the branch instruction that makes up the loop latch!
> 
> Offhand, is it possible that the problem
> here is the same as the one in PR8037?
> 
> No, that only shows up when you try to run "opt -analyze -indvars -scalar-evolution" by causing a crash. With that patch in place, you can see that "opt -analyze -indvars -scalar-evolution" produces different values for the SCEVs than you get with "opt -indvars | opt -analyze -scalar-evolution" which led me to add the forgetLoop here.

Ah, I tried the testcase, saw the crash, and assumed that was the bug
you were aiming to fix. The forgetLoop() call shouldn't be necessary
for correctness. But I do see how ScalarEvolution's cached tripcounts
are sub-optimal in this case, because they retain the type of the loop's
original induction variable, rather than the type that indvars has
chosen for the new induction variable. So forgetLoop() makes sense
there.

Dan



From nlewycky at google.com  Thu Jan 20 14:44:53 2011
From: nlewycky at google.com (Nick Lewycky)
Date: Thu, 20 Jan 2011 12:44:53 -0800
Subject: [LLVMdev] induction variable computation not preserving scev
In-Reply-To: <39B7D225-68BC-4B19-A716-BC8CF4BC8709@apple.com>
References: <AANLkTinqt1mBGv0aUjUkADOC6CEQsgXUH=iyvm-URMfB@mail.gmail.com>
	<54760F69-501D-4077-B82D-DAD6E9CA928E@apple.com>
	<AANLkTimTbx3=J_vktaOVLA+pyZ4xmt6OjuU7OKdcQrsT@mail.gmail.com>
	<39B7D225-68BC-4B19-A716-BC8CF4BC8709@apple.com>
Message-ID: <AANLkTi=BsrZhpiMQ+6xBbmqLXxJ_p+UmPB5_RbJ7KYdH@mail.gmail.com>

On 20 January 2011 11:23, Dan Gohman <gohman at apple.com> wrote:

>
> On Jan 19, 2011, at 2:03 PM, Nick Lewycky wrote:
>
> > On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote:
> >
> > On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote:
> >
> > > Hi,
> > >
> > > I tracked down a bug in indvars where we weren't updating SCEV
> properly. The attached patch shows the fix to this bug with a testcase, but
> it also causes five new test failures.
> >
> > Indvars isn't restructuring the loop there, so it ideally shouldn't
> > need to call forgetLoop().
> >
> > Hmm? It certainly is, it's changing the condition on the branch
> instruction that makes up the loop latch!
> >
> > Offhand, is it possible that the problem
> > here is the same as the one in PR8037?
> >
> > No, that only shows up when you try to run "opt -analyze -indvars
> -scalar-evolution" by causing a crash. With that patch in place, you can see
> that "opt -analyze -indvars -scalar-evolution" produces different values for
> the SCEVs than you get with "opt -indvars | opt -analyze -scalar-evolution"
> which led me to add the forgetLoop here.
>
> Ah, I tried the testcase, saw the crash, and assumed that was the bug
> you were aiming to fix. The forgetLoop() call shouldn't be necessary
> for correctness.


Why not though? Is there some guarantee that the values of the variables
within the loop can't have been changed by this? I expected to find such a
property based on my understanding of indvars, but when I looked through the
code I couldn't convince myself of it. Can you make such an argument?

But I do see how ScalarEvolution's cached tripcounts
> are sub-optimal in this case, because they retain the type of the loop's
> original induction variable, rather than the type that indvars has
> chosen for the new induction variable. So forgetLoop() makes sense
> there.
>

That's what I expected, and what I see in the testcase attached. However, a
bunch of tests fail with this patch in:

Failing Tests (5):
>     LLVM :: Transforms/IndVarSimplify/ashr-tripcount.ll
>     LLVM :: Transforms/IndVarSimplify/iv-sext.ll
>     LLVM :: Transforms/IndVarSimplify/preserve-signed-wrap.ll
>     LLVM :: Transforms/IndVarSimplify/promote-iv-to-eliminate-casts.ll
>     LLVM :: Transforms/IndVarSimplify/signed-trip-count.ll


and as far as I can see, they're not just silly errors because we changed
the SCEVs slightly; we're actually generating worse code when with
forgetLoop() in indvars. That's what I don't understand.

I debugged one example and that led to the simplification I added to SCEV in
r123838, but we're still not eliminating the sext instructions that the
testcases expect.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/ddb95b83/attachment.html 

From rcsaba at gmail.com  Thu Jan 20 14:49:28 2011
From: rcsaba at gmail.com (Csaba Raduly)
Date: Thu, 20 Jan 2011 21:49:28 +0100
Subject: [LLVMdev] Dubious code in llvm/lib/MC/MachObjectWriter.cpp
Message-ID: <AANLkTimcMVXqV9kGO+rKsONQGLtuxPF5276upo8HVB8E@mail.gmail.com>

In llvm/lib/MC/MachObjectWriter.cpp, there's

    assert(OS.tell() - Start == is64Bit() ?
           macho::Header64Size : macho::Header32Size);

Shouldn't that be

    assert(OS.tell() - Start == (is64Bit() ?
           macho::Header64Size : macho::Header32Size));

MSVC emits a warning, and it doesn't seem right to compare a boolean
with a difference of two integers.

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macho.diff
Type: application/octet-stream
Size: 912 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/113b3a2f/attachment.obj 

From puyan at gatech.edu  Thu Jan 20 14:54:11 2011
From: puyan at gatech.edu (Puyan Lotfi)
Date: Thu, 20 Jan 2011 15:54:11 -0500
Subject: [LLVMdev] Linking an opt optimization pass to clang?
Message-ID: <AANLkTimw0abysN8ZFjTObGkcw4SRAvTjQTHuNghjPL+f@mail.gmail.com>

Hi

I am trying to figure out how to link an opt pass to llvm-gcc or clang.
Is there a document on how to do this?

-Puyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/05d5499c/attachment.html 

From rcsaba at gmail.com  Thu Jan 20 14:57:01 2011
From: rcsaba at gmail.com (Csaba Raduly)
Date: Thu, 20 Jan 2011 21:57:01 +0100
Subject: [LLVMdev] Minor warning reduction in lib/CodeGen/SpillPlacement.cpp
Message-ID: <AANLkTi=LcNmtxVW-Gs5At_n89Hv0Ho5NH_mRW01p9iko@mail.gmail.com>

MSVC complains of truncating a double to a float. Let's just give it a float.

-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spill.diff
Type: application/octet-stream
Size: 554 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/77639f37/attachment.obj 

From raghu at cs.ucla.edu  Thu Jan 20 14:59:03 2011
From: raghu at cs.ucla.edu (Raghu Prabhakar)
Date: Thu, 20 Jan 2011 12:59:03 -0800 (PST)
Subject: [LLVMdev] Modifying the patterns/ instruction selection phase
 in LLVM 2.7
In-Reply-To: <AANLkTi=QU_HTS+cb-JWMsucY7QxRjV7gXSuRERCo6hPf@mail.gmail.com>
Message-ID: <1846393754.46192.1295557143389.JavaMail.root@mail.cs.ucla.edu>

I face the same problem - The function name and registers used must be encoded into the <number>. Adding an intrinsic function looks like a neat way to do things. In my current approach, I have done the following :

1) I have added a new instruction in the "SPISD" namespace, and modified the "SparcISelLowering.cpp" to emit TRAPINST into the selectionDAG whenever a "call @p0". This part is working fine. 
2) I want to edit the SparcInstrInfo.td file to emit a "sethi %g0,<number>" whenever it tries to pattern match the SPISD::TRAPINST node. I am, however, stuck in this step. My instruction selector is failing to come up with a match. I looked in the "SparcGenInstrNames.inc" file, and I did not find "TRAPINST" there. Is there something fundamentally wrong that I'm doing here while adding a pattern?

Thanks for the help !
Raghu.

For my case, I can't replace these call instructions with inline
assembly code because I need to encode the registers into the
"number".

For instance, if the call instruction is  %result = call i32 @foo(i32
%a)  and the result is assigned to register %l0 and the variable "a"
to register %l1,  then I encode all foo, %l0 and %l1 and generate a
sethi instruction.




On Thu, Jan 20, 2011 at 12:31 PM, John Criswell <criswell at illinois.edu> wrote:
> On 1/20/11 12:27 PM, Venkatraman Govindaraju wrote:
>
> Just out of curiosity, have either of you considered writing an LLVM
> transform that simply replaces these call instructions with inline assembly
> code that does what you want? ?If that works, it seems much simpler than
> modifying/enhancing the code generator.
>
> -- John T.
>
>> I have similar requirements for my project. This is what I do.
>>
>> ? 1. Add a new intrinsic function to LLVM that corresponds to
>> "functions with particular type of function names".
>> ? ? ? The steps to create intrinsic function is documented in
>> http://llvm.org/docs/ExtendingLLVM.html#intrinsic.
>> ? 2. Create a lowering pass that lowers "functions with particular
>> type" ( eg. p0, p1) to the intrinsic.
>> ? 3. Create a instruction pattern in SparcInstrInfo.td that matches
>> the intrinsic.
>> ? ? ? From the arguments to the intrinsic function, ?encode the
>> "<number>" ?and output a "sethi" instruction.
>>
>> Thanks,
>> Venkatraman
>>
>>
>> On Tue, Jan 18, 2011 at 11:18 PM, Raghu Prabhakar<raghu at cs.ucla.edu>
>> ?wrote:
>>>
>>> Hello all,
>>>
>>> I am trying to modify the Sparc backend to do something for my team's
>>> project, to do the following.
>>>
>>> Whenever the backend encounters a call to one particular type of function
>>> names (functions like p0(), p1()..etc), I want the backend to generate a
>>> "sethi %g0,<number>", and NOT a "call p0, call p1..." instruction. However,
>>> the backend should work as usual for any other function name.
>>>
>>> Now I figured that there are two ways to do this :
>>> 1) Modifying the "SparcISelLowering.cpp" to emit a special SDNode (with a
>>> special opcode that I have introduced into SPISD namespace) whenever it
>>> finds a "call @p0" in the LowerCall function. This node should have an entry
>>> in the "SparcInstrInfo.td" file.
>>>
>>> 2) No modifications to the Lowering phase. However, the pattern
>>> corresponding to the "sethi" instruction must be modified/new pattern added
>>> which corresponds to "call p0" kind of selectionDAG nodes.
>>>
>>> In either case, I am a bit confused about how tblgen's pattern
>>> representation scheme works. One more issue is that the destination register
>>> of "sethi %g0,<NUM>" HAS to be %g0 (which makes it a no-op on an actual
>>> sparc machine..I'm using a simulator), and<NUM> ?depends on p0 and its
>>> operands. There are ways where the certain registers required can be
>>> hard-assigned during instruction selection itself, but I'm unsure as to how
>>> to do that. Am I looking at the right set of files? Is there a better way to
>>> accomplish what I'm trying to do?
>>>
>>> I'm relatively new to LLVM, so I have some trouble freely navigating
>>> through the source in spite of being heavily documented.
>>>
>>> Any suggestions is of great help.
>>>
>>> Thanks.
>>> Raghu.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From z_alk at live.concordia.ca  Thu Jan 20 18:00:49 2011
From: z_alk at live.concordia.ca (z_alk at live.concordia.ca)
Date: Fri, 21 Jan 2011 00:00:49 +0000
Subject: [LLVMdev] including llvm data structures in eclipse
Message-ID: <FFBC51BCEBEC314290CF91C45446528219F59461@CH1PRD0104MB087.prod.exchangelabs.com>

Hello all,

I'm trying to include and use the Module.h class into my project
I get these 5 errors when I attempt to compile a cpp file that has #include <llvm/Module.h> (through eclipse)

Description    Resource    Path    Location    Type
#error "Must #define __STDC_CONSTANT_MACROS before " "#including System/DataTypes.h"    template        line 49, external location: /usr/lib/llvm-2.8/include/llvm/System/DataTypes.h    C/C++ Problem

Description    Resource    Path    Location    Type
#error "Must #define __STDC_LIMIT_MACROS before #including System/DataTypes.h"    template        line 45, external location: /usr/lib/llvm-2.8/include/llvm/System/DataTypes.h    C/C++ Problem

Description    Resource    Path    Location    Type
make: *** [src/template.o] Error 1    template        line 0    C/C++ Problem

Description    Resource    Path    Location    Type
there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available    template        line 38, external location: /usr/lib/llvm-2.8/include/llvm/Support/MathExtras.h    C/C++ Problem

Description    Resource    Path    Location    Type
there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available    template        line 57, external location: /usr/lib/llvm-2.8/include/llvm/Support/MathExtras.h    C/C++ Problem



Here's what I've done
Working in ubuntu,
installed llvm-gcc using "sudo apt-get install llvm-gcc-4.2" because I can't seem to understand the get started documentation...
installed eclipse and its CDT
in eclipse, added in the project properties to include the path for headers /usr/lib/llvm-2.8/include, and the path for libraries /usr/lib/llvm/lib

Am I missing something ?
I am sort of a beginner when it comes to linux and software development in linux..

Thanks !
Zaid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/12b917f2/attachment.html 

From jdkunk3 at gmail.com  Thu Jan 20 19:18:21 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Thu, 20 Jan 2011 20:18:21 -0500
Subject: [LLVMdev] [LLVMDev] Reg Alloc: Spiller::Spill question
Message-ID: <AANLkTi=VZNwj+f2VVFb2Tcov7pue3A1LtRqja6cukrp0@mail.gmail.com>

Spiller::Spill( LiveInterval *li,
                          SmallVectorImpl<LiveInterval*> &newIntervals,
                          const SmallVectorImpl<LiveInterval*> &spillIs );

has two reference vectors which contain a small list of Live Intervals. What
is the register allocator's job to do with these intervals other than
analysis. What more needed other than to know they exist?

- Thanks
- Jeff Kunkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110120/86c62ea6/attachment.html 

From surifilms at gmail.com  Thu Jan 20 22:02:09 2011
From: surifilms at gmail.com (Surinder)
Date: Fri, 21 Jan 2011 15:02:09 +1100
Subject: [LLVMdev] Pointers in Load and Store
Message-ID: <AANLkTimM-c3qK7xJxg6K7tABjuyZd98A8YoqPa7ZRsL4@mail.gmail.com>

When I compile C programs into llvm, it produces load instructions in
two different flavours.

(1)    %8 = load i8** %bp, align 8

(2)    %1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0,
i64 0), align 1

I know that %bp in first case and the entire "getelementptr inbounds
([4 x i8]* @.str, i64 0, i64 0)" in second case can be obtained by
dump'ing I.getOperand(0)

However, I want to find out which of the two forms of load have been
produced because in the second case, I want to insert checks for array
bounds.

How can I find out when I am in Instruction object I and I.getOpcode()
== 29 whether I am dealing with type (1) or type (2) above.

Thanks.

Surinder Kumar Jain

From criswell at illinois.edu  Thu Jan 20 22:12:24 2011
From: criswell at illinois.edu (John Criswell)
Date: Thu, 20 Jan 2011 22:12:24 -0600
Subject: [LLVMdev] Pointers in Load and Store
In-Reply-To: <AANLkTimM-c3qK7xJxg6K7tABjuyZd98A8YoqPa7ZRsL4@mail.gmail.com>
References: <AANLkTimM-c3qK7xJxg6K7tABjuyZd98A8YoqPa7ZRsL4@mail.gmail.com>
Message-ID: <4D3907A8.6080205@illinois.edu>

On 1/20/2011 10:02 PM, Surinder wrote:
> When I compile C programs into llvm, it produces load instructions in
> two different flavours.
>
> (1)    %8 = load i8** %bp, align 8
>
> (2)    %1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0,
> i64 0), align 1
>
> I know that %bp in first case and the entire "getelementptr inbounds
> ([4 x i8]* @.str, i64 0, i64 0)" in second case can be obtained by
> dump'ing I.getOperand(0)
>
> However, I want to find out which of the two forms of load have been
> produced because in the second case, I want to insert checks for array
> bounds.
>
> How can I find out when I am in Instruction object I and I.getOpcode()
> == 29 whether I am dealing with type (1) or type (2) above.

The second load instruction is not really a "special" load instruction.  
Rather, its pointer argument is an LLVM constant expression (class 
llvm::ConstExpr).  The Getelementptr (GEP), which would normally be a 
GEP instruction, is instead a constant expression that will be converted 
into a constant numeric value at code generation time.

So, what you need to do is to examine the LoadInst's operand and see if 
its a ConstExpr, and then see whether the ConstExpr's opcode is a GEP 
opcode.

However, there's an easier way to handle this.  SAFECode 
(http://safecode.cs.illinois.edu) has an LLVM pass which converts 
constant expression GEPs into GEP instructions.  If you run it on your 
code first, you'll get the following instruction sequence:

%tmp = getelementptr inbounds ([4 x i8]* @.str, i64 0,i64 0), align 1
%1 = load i8* %tmp

You then merely search for GEP instructions and put run-time checks on 
those (which you have to do anyway if you're adding array bounds 
checking).  The only ConstantExpr GEPs that aren't converted, I think, 
are those in global variable initializers.

Now, regarding the insertion of array bounds checks, SAFECode does that, 
too (it is a memory safety compiler for C code).  It also provides a 
simple static array bounds checker and some array bounds check 
optimization passes.

I can direct you to the relevant portions of the source code if you're 
interested.

-- John T.

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


From ww345ww at gmail.com  Fri Jan 21 01:14:51 2011
From: ww345ww at gmail.com (Qingan Li)
Date: Fri, 21 Jan 2011 15:14:51 +0800
Subject: [LLVMdev] About static-profile in llvm-2.8
Message-ID: <AANLkTik7eNXrc5P7pTnB5LGPYM+Zf26HQhf=npowMTqf@mail.gmail.com>

When I searched for branch frequency profiling on the internet, I got this
link  by a casual chance:
http://homepages.dcc.ufmg.br/~rimsa/tools/stprof-llvm.patch.
It seems it was written by Andrei Rimsa.

So I downloaded and integrate these files into the llvm-2.8 building. After
the building, I tried "opt -static-profile bitcnt_1.bc", and an segment
fault error occured. I debugged it step by step, and found the initial
reason was:
in StaticProfilePass.cpp: line 307 (funciton: PropagateCallFrequency), since
the root of type CallGraphNode * has no valid function,  the
node->getFunction() returned a NULL pointer, thus the F->getName() in line
307 caused a code down. I confirmed that there was a main function in
bitcnt_1.c (from MiBench)

I need the help.
-- 
Best regards,

Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/27b9eb56/attachment.html 

From hkultala at cs.tut.fi  Fri Jan 21 01:11:22 2011
From: hkultala at cs.tut.fi (Heikki Kultala)
Date: Fri, 21 Jan 2011 09:11:22 +0200
Subject: [LLVMdev] why dummy asserting base/interface class virtual methods
 instead of pure virtual methods?
Message-ID: <4D39319A.7060507@cs.tut.fi>

LLVM code base seems to be full of base/interface classes, which have 
methods like

   virtual SDValue
     LowerCall(SDValue Chain, SDValue Callee,
               CallingConv::ID CallConv, bool isVarArg, bool &isTailCall,
               const SmallVectorImpl<ISD::OutputArg> &Outs,
               const SmallVectorImpl<SDValue> &OutVals,
               const SmallVectorImpl<ISD::InputArg> &Ins,
               DebugLoc dl, SelectionDAG &DAG,
               SmallVectorImpl<SDValue> &InVals) const {
     assert(0 && "Not Implemented");
     return SDValue();    // this is here to silence compiler errors
   }




Why are these not pure virtual methods?

From logytech at gmail.com  Fri Jan 21 03:32:05 2011
From: logytech at gmail.com (Andrei Alvares)
Date: Fri, 21 Jan 2011 07:32:05 -0200
Subject: [LLVMdev] About static-profile in llvm-2.8
In-Reply-To: <AANLkTik7eNXrc5P7pTnB5LGPYM+Zf26HQhf=npowMTqf@mail.gmail.com>
References: <AANLkTik7eNXrc5P7pTnB5LGPYM+Zf26HQhf=npowMTqf@mail.gmail.com>
Message-ID: <AANLkTi=Lb_aazfccPVkRng4xgTpEcR7NKa3+w-CFfd6+@mail.gmail.com>

Hi Li Qingan,

 I did this patch for LLVM 2.7, and ported it to LLVM 2.8, but I
haven't fully tested in 2.8.
 Could you please provide your .bc?

 Thanks,
   Andrei

On Fri, Jan 21, 2011 at 5:14 AM, Qingan Li <ww345ww at gmail.com> wrote:
>
> When I searched for branch frequency profiling on the internet, I got this
> link ?by a casual
> chance:?http://homepages.dcc.ufmg.br/~rimsa/tools/stprof-llvm.patch.
> It seems it was written by Andrei Rimsa.
> So I downloaded and integrate these files into the llvm-2.8 building. After
> the building, I tried "opt -static-profile bitcnt_1.bc", and an segment
> fault error occured. I debugged it step by step, and found the initial
> reason was:
> in StaticProfilePass.cpp: line 307 (funciton: PropagateCallFrequency), since
> the root of type CallGraphNode * has no valid function, ?the
> node->getFunction() returned a NULL pointer, thus the F->getName() in line
> 307 caused a code down. I confirmed that there was a main function in
> bitcnt_1.c (from MiBench)
> I need the help.
> --
> Best regards,
> Li Qingan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From xinfinity_a at yahoo.com  Fri Jan 21 06:22:10 2011
From: xinfinity_a at yahoo.com (Xinfinity)
Date: Fri, 21 Jan 2011 04:22:10 -0800 (PST)
Subject: [LLVMdev]  goto in inline asm
Message-ID: <30728118.post@talk.nabble.com>


Is goto from inline asm supported in LLVM 2.8 ? 
I am searching for something similar to what gcc 4.5 does: 

http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20asm%20with%20goto
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20asm%20with%20goto 

which allows jumping from inline assembly to a label defined in C.

I want to jump from inline asm to a basic block in LLVM. As far as I know in
LLVM 2.7 this was not yet possible. Is it allowed a jump like this in LLVM
2.8 ?

Alexandra
-- 
View this message in context: http://old.nabble.com/goto-in-inline-asm-tp30728118p30728118.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From m.vijay at nus.edu.sg  Fri Jan 21 07:48:02 2011
From: m.vijay at nus.edu.sg (Vijayaraghavan Murali)
Date: Fri, 21 Jan 2011 21:48:02 +0800
Subject: [LLVMdev] View variable-register map
Message-ID: <4D398E92.3020405@nus.edu.sg>

Hello everyone,

I have started using LLVM only recently, so I'm a kind of a newbie. I'm 
using it to observe the effects of our path-sensitive analysis of the 
source code on register allocation.

I just wish to know if other than manually comparing the llc generated 
code with the source program, is there any other way of knowing which 
variables in the program are mapped to which registers? I was not able 
to find any suitable option for the same, so I'm wondering if there is a 
workaround.

Thank you!

------------
Vijayaraghavan Murali (Vijay)

From fvbommel at gmail.com  Fri Jan 21 07:52:29 2011
From: fvbommel at gmail.com (Frits van Bommel)
Date: Fri, 21 Jan 2011 14:52:29 +0100
Subject: [LLVMdev] goto in inline asm
In-Reply-To: <30728118.post@talk.nabble.com>
References: <30728118.post@talk.nabble.com>
Message-ID: <AANLkTikHBOFYK6nS_vmMjLsi5ySJPaOi2Us-+pG4Lbkx@mail.gmail.com>

On Fri, Jan 21, 2011 at 1:22 PM, Xinfinity <xinfinity_a at yahoo.com> wrote:
> I want to jump from inline asm to a basic block in LLVM. As far as I know in
> LLVM 2.7 this was not yet possible. Is it allowed a jump like this in LLVM
> 2.8 ?

This is not directly representable in LLVM IR.
However, it *is* possible to "restructure" the inline asm so that it
returns either an int or a blockaddress for use with respectively a
switch or indirectbr occurring right after the inline asm. This can be
done by replacing the labels being jumped to with labels defined in
the inline asm (e.g. at the end), which then put the appropriate
values in a register (or memory location) being used as output. And of
course there should be code added to return the "default destination"
if no 'goto' is reached.
Obviously, this requires the frontend doing this to have special code
for each cpu architecture you want to support this on.

LDC (www.dsource.org/projects/ldc/) uses this technique.
I'm not sure if (and how) clang, dragonegg and llvm-gcc handle this.


In order to represent this directly in LLVM IR, there would need to be
a variant of inline asm calls that is a terminator instruction,
probably quite similar to 'indirectbr' (but with a default
destination, like 'switch'). Otherwise there would be no way to
properly keep PHI nodes of successors up to date, for instance.
I imagine this would be tricky to implement "properly" though.

From fvbommel at gmail.com  Fri Jan 21 08:03:51 2011
From: fvbommel at gmail.com (Frits van Bommel)
Date: Fri, 21 Jan 2011 15:03:51 +0100
Subject: [LLVMdev] View variable-register map
In-Reply-To: <4D398E92.3020405@nus.edu.sg>
References: <4D398E92.3020405@nus.edu.sg>
Message-ID: <AANLkTi=MVExNt_0HU4vk1f9dxJk0pqBbKxYuEFXxRsXd@mail.gmail.com>

On Fri, Jan 21, 2011 at 2:48 PM, Vijayaraghavan Murali
<m.vijay at nus.edu.sg> wrote:
> I just wish to know if other than manually comparing the llc generated
> code with the source program, is there any other way of knowing which
> variables in the program are mapped to which registers? I was not able
> to find any suitable option for the same, so I'm wondering if there is a
> workaround.

Isn't this exactly one of the things debug information is for?
You'd need to compile with -g and somehow read the DWARF information
generated. As a bonus, this should work with gcc output too.

You'd still be comparing llc output with the source code[1], but you
no longer need to do it manually :).


[1]: Or the clang AST, I suppose.

From snaphat at gmail.com  Fri Jan 21 09:32:13 2011
From: snaphat at gmail.com (Aaron Myles Landwehr)
Date: Fri, 21 Jan 2011 10:32:13 -0500
Subject: [LLVMdev] How to extend llvm IR and frontend?
Message-ID: <AANLkTimgMX+jLa0cGa-iHiXcOJOUqg_5+nM8+TDBU2wN@mail.gmail.com>

Hi all,

Hypothetically, suppose I have a generic system with multiple address spaces
such that each address space is accessed using different instructions.

Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of
c variables and function return types such that the following would be
valid:

foo void* a;
foo void* somefunc(){...}
bar int b;
int somefunc2(bar int*){...}

Furthermore, if I wanted this keyword to be added as part of the LLVM IR in
some manner such that the during the translation of LLVM IR to some target
machine ASM it could be used to switch which address spaces are used (e.g.
if I specify one of the keywords, I get some instruction or group of
instructions to access a certain address space), what would be the
correct/easiest place(s) to add this functionality, and would there be
existing code that does something similar that can be used as a starting
point?

More Info: suppose this uses clang as a frontend.

Thanks,
Aaron Landwehr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/d96c0631/attachment.html 

From jdkunk3 at gmail.com  Fri Jan 21 10:51:05 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Fri, 21 Jan 2011 11:51:05 -0500
Subject: [LLVMdev] How to extend llvm IR and frontend?
In-Reply-To: <AANLkTimgMX+jLa0cGa-iHiXcOJOUqg_5+nM8+TDBU2wN@mail.gmail.com>
References: <AANLkTimgMX+jLa0cGa-iHiXcOJOUqg_5+nM8+TDBU2wN@mail.gmail.com>
Message-ID: <AANLkTikx8OxVrKqYwwdEcC0ZqX85hFNXHz_99ja3J6wU@mail.gmail.com>

I would think clang would be more appropriate for adding a c-declaration
descriptor. However, assuming that no translation down to llvm exists, you
would need to create the information as either metadata (preferred) or as a
new type (ugly and time consuming). If you can keep it as metadata, then
some later passes may gather that meta-data and execute properly. A new type
requires much in the way of hacking other passes to inform them what to do
upon seeing the new type.

- My 2 cents,
Jeff Kunkel

On Fri, Jan 21, 2011 at 10:32 AM, Aaron Myles Landwehr <snaphat at gmail.com>wrote:

> Hi all,
>
> Hypothetically, suppose I have a generic system with multiple address
> spaces such that each address space is accessed using different
> instructions.
>
> Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of
> c variables and function return types such that the following would be
> valid:
>
> foo void* a;
> foo void* somefunc(){...}
> bar int b;
> int somefunc2(bar int*){...}
>
> Furthermore, if I wanted this keyword to be added as part of the LLVM IR in
> some manner such that the during the translation of LLVM IR to some target
> machine ASM it could be used to switch which address spaces are used (e.g.
> if I specify one of the keywords, I get some instruction or group of
> instructions to access a certain address space), what would be the
> correct/easiest place(s) to add this functionality, and would there be
> existing code that does something similar that can be used as a starting
> point?
>
> More Info: suppose this uses clang as a frontend.
>
> Thanks,
> Aaron Landwehr
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/78b84a85/attachment-0001.html 

From MDecker at lucasgroup.com  Fri Jan 21 10:57:29 2011
From: MDecker at lucasgroup.com (Decker, Michael)
Date: Fri, 21 Jan 2011 11:57:29 -0500
Subject: [LLVMdev] Compiler Developer Opportunity
Message-ID: <E242A947797B69489E341C8EB0A6F0CA020ED1A4@ex02.lucas.internal>

A premiere Proprietary Trading Firm in Chicago, IL is looking for a
Compiler Developer to join their team.  After reading the job
description, if you are interested in this great opportunity, email me
your updated word resume to mdecker at lucasgroup.com and call me at
713-470-5790 to discuss this position further.
 
 
Compiler Developer

 


In this role, you will be responsible for working closely with traders
and quantitative researchers to develop a domain specific language for
trading applications as well as to optimize the processing of extremely
large datasets.

 

Requires:

 

*    Advanced degree in Computer Science, Mathematics, Logic or similar.

*    Strong experience with compiler development and research.

*    Strong experience with compiler theory - demonstrated flexibility
and not tied to one framework.

*    Experience with LLVM, gnu and other compiler frameworks.

*    Experience building compilers for functional, logical or dataflow
languages is desired.

 

More Information to determine if you have the specific experience
necessary to have success in this position:

 

In general, compiler optimizations can be divided into low-level,
mid-level, and high-level. Low-level is stuff close to the hardware like
instructions scheduling, register allocation, etc. Mid level includes
stuff like memory layout and coarse-grain parallelism. High-level is
things like translating constructs in your language to other constructs
still in your language but have better performance characteristics. 
 
The preferred skill set would be someone in the mid-level and high-level
optimizations than low-level since our client uses an open-source
framework which provides much of the low-level passes. Logical,
functional, data-flow, and declarative languages tend to do a lot more
on the high-level side, which is one of the reasons why our client is
interested in those people. Work that is done on SQL-query plan
optimization usually falls into the high-level category as well. 
 
Regards,
 
Michael Decker
Executive Search Consultant, Information Technology


 

5120 Woodway Drive
Houston, TX 77056-1160

Main: (713) 864-7733 x290
Direct: (713) 470-5790

Fax: (713) 864-7887
Mobile: (281) 744-2672

Linkedin: http://www.linkedin.com/in/topnotchrecruiter

Email: mdecker at lucasgroup.com
Website: www.lucasgroup.com <http://www.lucasgroup.com/>  

P Please consider the environment before printing this email

 

******

NOTICE:  Any resumes, candidate or client information contained in or attached to this email are exclusive property of Lucas Group, confidential and/or trade secret, and the recipient of this email agrees to keep such information confidential.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/5cf48c0d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 11382 bytes
Desc: att349a8.bmp
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/5cf48c0d/attachment.bmp 

From grosbach at apple.com  Fri Jan 21 10:59:53 2011
From: grosbach at apple.com (Jim Grosbach)
Date: Fri, 21 Jan 2011 08:59:53 -0800
Subject: [LLVMdev] How to extend llvm IR and frontend?
In-Reply-To: <AANLkTimgMX+jLa0cGa-iHiXcOJOUqg_5+nM8+TDBU2wN@mail.gmail.com>
References: <AANLkTimgMX+jLa0cGa-iHiXcOJOUqg_5+nM8+TDBU2wN@mail.gmail.com>
Message-ID: <F390D036-B5B2-4770-9DE7-12C00E80262D@apple.com>

The LLVM address space qualifiers will get you at least part of the way. I'd suggest starting your search there.

More generally speaking, note that in the front end you really want this sort of thing to be (syntactically) a type qualifier so you can support pointers back and forth between the address spaces in a natural way. You'll also want a generic pointer type (can reference any address space) to use for unqualified pointers. Otherwise you can't make a conformant C compiler.

-Jim

On Jan 21, 2011, at 7:32 AM, Aaron Myles Landwehr wrote:

> Hi all,
> 
> Hypothetically, suppose I have a generic system with multiple address spaces such that each address space is accessed using different instructions.
> 
> Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of c variables and function return types such that the following would be valid:
> 
> foo void* a;
> foo void* somefunc(){...}
> bar int b;
> int somefunc2(bar int*){...}
> 
> Furthermore, if I wanted this keyword to be added as part of the LLVM IR in some manner such that the during the translation of LLVM IR to some target machine ASM it could be used to switch which address spaces are used (e.g. if I specify one of the keywords, I get some instruction or group of instructions to access a certain address space), what would be the correct/easiest place(s) to add this functionality, and would there be existing code that does something similar that can be used as a starting point?
> 
> More Info: suppose this uses clang as a frontend.
> 
> Thanks,
> Aaron Landwehr
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From jdkunk3 at gmail.com  Fri Jan 21 11:01:30 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Fri, 21 Jan 2011 12:01:30 -0500
Subject: [LLVMdev] why dummy asserting base/interface class virtual
 methods instead of pure virtual methods?
In-Reply-To: <4D39319A.7060507@cs.tut.fi>
References: <4D39319A.7060507@cs.tut.fi>
Message-ID: <AANLkTinrL8d76DSo+B10s7xNSeRWw1V+KVpzpeLgh20=@mail.gmail.com>

Software engineers like to work/test on one function at a time. So being
able to compile and test is an important factor when creating/writing code.
Thus, the functions are not pure-virtual. They fail at run time instead.

- Jeff

On Fri, Jan 21, 2011 at 2:11 AM, Heikki Kultala <hkultala at cs.tut.fi> wrote:

> LLVM code base seems to be full of base/interface classes, which have
> methods like
>
>   virtual SDValue
>     LowerCall(SDValue Chain, SDValue Callee,
>               CallingConv::ID CallConv, bool isVarArg, bool &isTailCall,
>               const SmallVectorImpl<ISD::OutputArg> &Outs,
>               const SmallVectorImpl<SDValue> &OutVals,
>               const SmallVectorImpl<ISD::InputArg> &Ins,
>               DebugLoc dl, SelectionDAG &DAG,
>               SmallVectorImpl<SDValue> &InVals) const {
>     assert(0 && "Not Implemented");
>     return SDValue();    // this is here to silence compiler errors
>   }
>
>
>
>
> Why are these not pure virtual methods?
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/a4448379/attachment.html 

From fvbommel at gmail.com  Fri Jan 21 12:23:52 2011
From: fvbommel at gmail.com (Frits van Bommel)
Date: Fri, 21 Jan 2011 19:23:52 +0100
Subject: [LLVMdev] How to extend llvm IR and frontend?
In-Reply-To: <AANLkTimgMX+jLa0cGa-iHiXcOJOUqg_5+nM8+TDBU2wN@mail.gmail.com>
References: <AANLkTimgMX+jLa0cGa-iHiXcOJOUqg_5+nM8+TDBU2wN@mail.gmail.com>
Message-ID: <AANLkTi=eOaRPo54LHF2mdLy6p9yXAZSJodOLW66aXNzs@mail.gmail.com>

On Fri, Jan 21, 2011 at 4:32 PM, Aaron Myles Landwehr <snaphat at gmail.com> wrote:
> Hypothetically, suppose I have a generic system with multiple address spaces
> such that each address space is accessed using different instructions.
> Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of
> c variables and function return types such that the following would be
> valid:
> foo void* a;
> foo void* somefunc(){...}
> bar int b;
> int somefunc2(bar int*){...}

How about putting

  #define foo __attribute__((address_space(256)))
  #define bar __attribute__((address_space(257)))

in some header? (Or on the command line, or in clang's default #defines, ...)
Though maybe they'd need to be in a slightly different place; the
example in the documentation
(http://clang.llvm.org/docs/LanguageExtensions.html) is

  #define GS_RELATIVE __attribute__((address_space(256)))
  int foo(int GS_RELATIVE *P) {
    return *P;
  }

so maybe it won't work if they're in front of the declaration.

And of course, they're not technically keywords...

> Furthermore, if I wanted this keyword to be added as part of the LLVM IR in
> some manner such that the during the translation of LLVM IR to some target
> machine ASM it could be used to switch which address spaces are used (e.g.
> if I specify one of the keywords, I get some instruction or group of
> instructions to access a certain address space), what would be the
> correct/easiest place(s) to add this functionality, and would there be
> existing code that does something similar that can be used as a starting
> point?

The x86 frontend does something like this for fs and gs segment
specifiers, but those just add a prefix to the instruction so they
might not actually be different instructions (I'm not sure).

From czhao at eecg.toronto.edu  Fri Jan 21 14:50:31 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Fri, 21 Jan 2011 15:50:31 -0500
Subject: [LLVMdev] all LLVM Instructions that may write to memory -- other
	than StoreInst?
Message-ID: <4D39F197.6090306@eecg.toronto.edu>

I need to figure out all LLVM Instructions that may write to memory.

In http://llvm.org/docs/tutorial/OCamlLangImpl7.html, it mentions that
"In LLVM, all memory accesses are explicit with load/store instructions, 
and it is carefully designed not to have (or need) an "address-of" 
operator."

I take this as "StoreInst is the only one that writes to memory".

However, this doesn't seem to be enough.

Consider:
...
int a, b, d;
d = a + b;
...

The above code is turned into LLVM IR:

   %0 = load i32* @a, align 4
   %1 = load i32* @b, align 4
   %2 = add nsw i32 %1, %0
   store i32 %2, i32* @d, align 4

Is it possible that temps such as %0, %1 and/or %2 will NOT being register allocated later in the compilation stage, and thus left in memory?

The above code, when converted back to C level, looks like this:
...
   unsigned int llvm_cbe_tmp__6;
   unsigned int llvm_cbe_tmp__7;
   unsigned int llvm_cbe_tmp__8;
   unsigned int llvm_cbe_tmp__9;

   llvm_cbe_tmp__6 = *(&a);
   llvm_cbe_tmp__7 = *(&b);
   llvm_cbe_tmp__8 = ((unsigned int )(((unsigned int )llvm_cbe_tmp__7) + ((unsigned int )llvm_cbe_tmp__6)));
   *(&d) = llvm_cbe_tmp__8;
   llvm_cbe_tmp__9 =  /*tail*/ printf(((&_OC_str.array[((signed int )0u)])), llvm_cbe_tmp__8);
...

It seems the compiler-generated temps are _actually_ left on stack, and writes to them are actually writes to stack memory (via load, add, ...).



I am confused here.
Could somebody help to clarify it?

Thank you

Chuck



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/a53772e3/attachment.html 

From douglasdocouto at gmail.com  Fri Jan 21 14:56:32 2011
From: douglasdocouto at gmail.com (Douglas do Couto Teixeira)
Date: Fri, 21 Jan 2011 18:56:32 -0200
Subject: [LLVMdev] How to change the type of an Instruction?
Message-ID: <AANLkTinckvZACezY4AFENa4co+_jhS3cWc+37OUMZqwY@mail.gmail.com>

Hello guys,

I wonder how I can change the type of an integer variable. For instance,
given the instruction "%3 = add i32 %1, %2" I would like to alter the
instruction to "%3 = add i16 %1, %2". Is there any way to do this?

Best wishes,

Douglas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/c0007572/attachment.html 

From nlewycky at google.com  Fri Jan 21 16:25:08 2011
From: nlewycky at google.com (Nick Lewycky)
Date: Fri, 21 Jan 2011 14:25:08 -0800
Subject: [LLVMdev] How to change the type of an Instruction?
In-Reply-To: <AANLkTinckvZACezY4AFENa4co+_jhS3cWc+37OUMZqwY@mail.gmail.com>
References: <AANLkTinckvZACezY4AFENa4co+_jhS3cWc+37OUMZqwY@mail.gmail.com>
Message-ID: <AANLkTin1=uaisjUyBz2rTRxS4pWK3=Ek-ikyHYRC3oYw@mail.gmail.com>

On 21 January 2011 12:56, Douglas do Couto Teixeira <
douglasdocouto at gmail.com> wrote:

> Hello guys,
>
> I wonder how I can change the type of an integer variable. For instance,
> given the instruction "%3 = add i32 %1, %2" I would like to alter the
> instruction to "%3 = add i16 %1, %2". Is there any way to do this?
>

No. Instead you create a new Instruction, in this case with
BinaryOperator::CreateAdd, then OldInst->replaceAllUsesWith(NewInst) to
update all the users, then OldInst->eraseFromParent() since it's now dead
code.

Also, all values have types immutably assigned at creation, so you'll need
to insert casts (trunc instructions in your case) to cast %1 and %2 from i32
to i16 for the smaller add.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/91e43425/attachment.html 

From criswell at illinois.edu  Fri Jan 21 16:33:59 2011
From: criswell at illinois.edu (John Criswell)
Date: Fri, 21 Jan 2011 16:33:59 -0600
Subject: [LLVMdev] all LLVM Instructions that may write to memory --
 other than StoreInst?
In-Reply-To: <4D39F197.6090306@eecg.toronto.edu>
References: <4D39F197.6090306@eecg.toronto.edu>
Message-ID: <4D3A09D7.4090603@illinois.edu>

On 1/21/11 2:50 PM, Chuck Zhao wrote:
> I need to figure out all LLVM Instructions that may write to memory.
>
> In http://llvm.org/docs/tutorial/OCamlLangImpl7.html, it mentions that
> "In LLVM, all memory accesses are explicit with load/store 
> instructions, and it is carefully designed not to have (or need) an 
> "address-of" operator."
>
> I take this as "StoreInst is the only one that writes to memory".

There are intrinsic functions which write to memory also, such as memcpy.
>
> However, this doesn't seem to be enough.

Your observation is correct.  Strictly speaking, any instruction can 
write to memory after code generation because it may access a stack 
spill slot or a function parameter which the ABI places on the stack.

When the Language Reference Manual talks about writing to memory, it is 
talking about writing to memory that is visible at the LLVM IR level.  
The stack frame is invisible at the LLVM IR level.  Put another way, 
"memory" is a set of memory locations which can be explicitly accessed 
by LLVM load and store instructions and are not in SSA form; it is not 
all of the memory within the computer.

If you're interested in finding instructions that write to RAM 
(including writes to stack spill slots), it may be better to work on 
Machine Instructions within the code generator framework.

-- John T.


>
> Consider:
> ...
> int a, b, d;
> d = a + b;
> ...
>
> The above code is turned into LLVM IR:
>    %0 = load i32* @a, align 4
>    %1 = load i32* @b, align 4
>    %2 = add nsw i32 %1, %0
>    store i32 %2, i32* @d, align 4
>
> Is it possible that temps such as %0, %1 and/or %2 will NOT being register allocated later in the compilation stage, and thus left in memory?
>
> The above code, when converted back to C level, looks like this:
> ...
>    unsigned int llvm_cbe_tmp__6;
>    unsigned int llvm_cbe_tmp__7;
>    unsigned int llvm_cbe_tmp__8;
>    unsigned int llvm_cbe_tmp__9;
>
>    llvm_cbe_tmp__6 = *(&a);
>    llvm_cbe_tmp__7 = *(&b);
>    llvm_cbe_tmp__8 = ((unsigned int )(((unsigned int )llvm_cbe_tmp__7) + ((unsigned int )llvm_cbe_tmp__6)));
>    *(&d) = llvm_cbe_tmp__8;
>    llvm_cbe_tmp__9 =  /*tail*/ printf(((&_OC_str.array[((signed int )0u)])), llvm_cbe_tmp__8);
> ...
>
> It seems the compiler-generated temps are _actually_ left on stack, and writes to them are actually writes to stack memory (via load, add, ...).
>
>
>
> I am confused here.
> Could somebody help to clarify it?
>
> Thank you
>
> Chuck
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/e5a2fa13/attachment.html 

From greened at obbligato.org  Fri Jan 21 16:40:05 2011
From: greened at obbligato.org (David A. Greene)
Date: Fri, 21 Jan 2011 16:40:05 -0600
Subject: [LLVMdev] TableGen Operator Names
In-Reply-To: <FE9F9A42-3453-454F-BF40-660D95BA3259@apple.com> (Chris Lattner's
	message of "Tue, 11 Jan 2011 17:39:22 -0800")
References: <nngpqs8bp64.fsf@royale.us.cray.com>
	<DAB73736-AB7E-4835-B3A2-A27B5A9614A7@apple.com>
	<nngfwsz6v97.fsf@royale.us.cray.com>
	<FE9F9A42-3453-454F-BF40-660D95BA3259@apple.com>
Message-ID: <nngbp39lw3e.fsf@royale.us.cray.com>

Chris Lattner <clattner at apple.com> writes:

>> Fair enough.  What would make a better proposal?  I'd like to keep the
>> syntax concise.  I wonder if there is a way we could get rid of the
>> "operator" entirely and just specify names, like:
>> 
>> strconcat("this", "that")
>> 
>> instead of 
>> 
>> !strconcat("this", "that")
>> 
>> What do you think?
>
> That would be nice.  I haven't looked in years, but I thought that there was a parser ambiguity issue.

I think it would require removing knowledge of operators in the lexer,
just have it return an ID token for the operator name and then have the
parser implement a rule:

Operator : ID '(' ArgList ')'

But I haven't played around with it yet.

                               -Dave

From greened at obbligato.org  Fri Jan 21 16:45:31 2011
From: greened at obbligato.org (David A. Greene)
Date: Fri, 21 Jan 2011 16:45:31 -0600
Subject: [LLVMdev] PostRAScheduling for x86
In-Reply-To: <102D99A6-E64D-40EE-9D79-F4E994E61A93@2pi.dk> (Jakob Stoklund
	Olesen's message of "Tue, 11 Jan 2011 15:00:34 -0800")
References: <AANLkTimvY2ywS65CH6qEpDpV+vWw33A7ia+mWz2K-sQ5@mail.gmail.com>
	<102D99A6-E64D-40EE-9D79-F4E994E61A93@2pi.dk>
Message-ID: <nng7hdxlvuc.fsf@royale.us.cray.com>

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:

> On Jan 11, 2011, at 2:56 PM, JG wrote:
>
>> I am trying to understand why PostRAScheduling is done only for
>> ARM. Is there any limitation which prevents this from being done for
>> x86 ?
>
> It's a 10% increase in overall compile time, and it does not help very much for x86.
>
> The out-of-order execution on new x86 chips hide any benefits from late scheduling.

I agree about the compile time issue.  For us it is much worse than a
10% hit as HPC codes tend to have very large basic blocks.  The compile
time hit made it unusable for us and our users aer accustomed to much
longer compile times than most LLVM users would accept.

I disagree about the performance benefit.  Post-RA scheduling certainly
helps in certain spilling cases on x86, which we addressed with the
schedule-spills changes in VirtRegRewriter.  I'm not convinced the
current schedule-spills solution is the best in terms of software
engineering as it's a bit of a hack.  Having a more general post-RA
scheduling pass which can focus on the things that really matter for a
particular target would be very nice indeed.  Getting the focus right
would alleviate the compile time problem as well, I think.

Of course, I have zero time right now to actually do anything about it.
:)

                            -Dave

From harip at vt.edu  Fri Jan 21 16:56:15 2011
From: harip at vt.edu (Hari Pyla)
Date: Fri, 21 Jan 2011 17:56:15 -0500
Subject: [LLVMdev] -ffixed option in llvm-gcc
Message-ID: <4D3A0F0F.60407@vt.edu>

Hi
  I am trying to register shadow a global variable using -ffixed option 
in llvm-gcc. I am able to accomplish this using gcc however llvm-gcc 
seems to ignore this option and generate code using the register.

command line:
 >gcc -Wall -m64 -O3 -pthread -ftls-model=initial-exec -ffixed-r12 
test.c -o test
 >objdump -d ./test | grep r12


 >llvm-gcc -Wall -m64 -O3 -pthread -ftls-model=initial-exec -ffixed-r12 
test.c -o test
 >objdump -d ./test | grep r12
....
...  //uses r12 register

I was wondering if "-ffixed" option is not supported by llvm-gcc. If so 
I was wondering what is the best approach to register shadow a global 
variable in llvm.

Best,
--Hari

From gohman at apple.com  Fri Jan 21 16:58:41 2011
From: gohman at apple.com (Dan Gohman)
Date: Fri, 21 Jan 2011 14:58:41 -0800
Subject: [LLVMdev] induction variable computation not preserving scev
In-Reply-To: <AANLkTi=BsrZhpiMQ+6xBbmqLXxJ_p+UmPB5_RbJ7KYdH@mail.gmail.com>
References: <AANLkTinqt1mBGv0aUjUkADOC6CEQsgXUH=iyvm-URMfB@mail.gmail.com>
	<54760F69-501D-4077-B82D-DAD6E9CA928E@apple.com>
	<AANLkTimTbx3=J_vktaOVLA+pyZ4xmt6OjuU7OKdcQrsT@mail.gmail.com>
	<39B7D225-68BC-4B19-A716-BC8CF4BC8709@apple.com>
	<AANLkTi=BsrZhpiMQ+6xBbmqLXxJ_p+UmPB5_RbJ7KYdH@mail.gmail.com>
Message-ID: <8F5E9274-80D8-4493-805F-7EFEF58CE005@apple.com>


On Jan 20, 2011, at 12:44 PM, Nick Lewycky wrote:

> On 20 January 2011 11:23, Dan Gohman <gohman at apple.com> wrote:
> 
> On Jan 19, 2011, at 2:03 PM, Nick Lewycky wrote:
> 
> > On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote:
> >
> > On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote:
> >
> > > Hi,
> > >
> > > I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test failures.
> >
> > Indvars isn't restructuring the loop there, so it ideally shouldn't
> > need to call forgetLoop().
> >
> > Hmm? It certainly is, it's changing the condition on the branch instruction that makes up the loop latch!
> >
> > Offhand, is it possible that the problem
> > here is the same as the one in PR8037?
> >
> > No, that only shows up when you try to run "opt -analyze -indvars -scalar-evolution" by causing a crash. With that patch in place, you can see that "opt -analyze -indvars -scalar-evolution" produces different values for the SCEVs than you get with "opt -indvars | opt -analyze -scalar-evolution" which led me to add the forgetLoop here.
> 
> Ah, I tried the testcase, saw the crash, and assumed that was the bug
> you were aiming to fix. The forgetLoop() call shouldn't be necessary
> for correctness.
> 
> Why not though? Is there some guarantee that the values of the variables within the loop can't have been changed by this? I expected to find such a property based on my understanding of indvars, but when I looked through the code I couldn't convince myself of it. Can you make such an argument?

Indvars doesn't change the values of any existing instructions,
and it doesn't change the actual trip count of the loop. It just
adds new instructions which compute the same values as old
instructions, and deletes the old instructions. ScalarEvolution
uses ValueHandles to be notified of the deletions, and it doesn't
immediately care about new instructions.

Dan



From greened at obbligato.org  Fri Jan 21 16:59:05 2011
From: greened at obbligato.org (David A. Greene)
Date: Fri, 21 Jan 2011 16:59:05 -0600
Subject: [LLVMdev] Question about porting LLVM - a single instruction op
	mnemonic with multiple operand forms
In-Reply-To: <D556DCBBC0EA924A9AC80003B621211205FBD28DA6@sausexmbp02.amd.com>
	(Micah Villmow's message of "Tue, 18 Jan 2011 12:50:00 -0600")
References: <AANLkTi=Dw2SPyMUGSH-ztNUfM+pReP0cr=zuUPFCGBr5@mail.gmail.com>
	<D556DCBBC0EA924A9AC80003B621211205FBD28DA6@sausexmbp02.amd.com>
Message-ID: <nng39ollv7q.fsf@royale.us.cray.com>

"Villmow, Micah" <Micah.Villmow at amd.com> writes:

> I have this same problem in our backend. I solve it by adding a pseudo
> instruction at instruction selection that transforms @R1 into R1, so
> only a single pattern is required. I then can propogate the pseudo
> instruction after instruction selection.

What's the rationale behind this approach?  It seems a bit clumsy to me.
An instruction with varying addressing modes is not a single
instruction.  They have different encodings, for starters.  Defining
separate patterns for them is the "clean" LLVM approach.  I would think
your approach adds the danger of the pseudo-instruction getting lost at
some point.

If the redundancy in specifying patterns for different addressing modes
is the problem, I have some stuff to submit that helps with that.  It
will probably take quite a bit of patch churn before it makes it to
trunk, however.

                               -Dave

From czhao at eecg.toronto.edu  Fri Jan 21 17:00:07 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Fri, 21 Jan 2011 18:00:07 -0500
Subject: [LLVMdev] all LLVM Instructions that may write to memory --
 other than StoreInst?
In-Reply-To: <4D3A09D7.4090603@illinois.edu>
References: <4D39F197.6090306@eecg.toronto.edu> <4D3A09D7.4090603@illinois.edu>
Message-ID: <4D3A0FF7.4000405@eecg.toronto.edu>

John,

Thanks for the reply.
I agree with your comments that the "Memory" LLVM Spec refers to doesn't 
include stack.

Let me leverage a bit further:

If I need to work on high-level IRs (not machine dependent, not in the 
code-gen stage), is it reasonable to assume that
ALL LLVM IRs that have a result field will have potential to write stack?


E.g.

   <result>  = add<ty>  <op1>,<op2>           /; yields {ty}:result/


   br i1<cond>, label<iftrue>, label<iffalse>
   br label<dest>           /; Unconditional branch/


ADD can (potential) write stack to store its result, while BR will NEVER 
write stack because its doesn't have a result.


Thank you

Chuck




On 1/21/2011 5:33 PM, John Criswell wrote:
> On 1/21/11 2:50 PM, Chuck Zhao wrote:
>> I need to figure out all LLVM Instructions that may write to memory.
>>
>> In http://llvm.org/docs/tutorial/OCamlLangImpl7.html, it mentions that
>> "In LLVM, all memory accesses are explicit with load/store 
>> instructions, and it is carefully designed not to have (or need) an 
>> "address-of" operator."
>>
>> I take this as "StoreInst is the only one that writes to memory".
>
> There are intrinsic functions which write to memory also, such as memcpy.
>>
>> However, this doesn't seem to be enough.
>
> Your observation is correct.  Strictly speaking, any instruction can 
> write to memory after code generation because it may access a stack 
> spill slot or a function parameter which the ABI places on the stack.
>
> When the Language Reference Manual talks about writing to memory, it 
> is talking about writing to memory that is visible at the LLVM IR 
> level.  The stack frame is invisible at the LLVM IR level.  Put 
> another way, "memory" is a set of memory locations which can be 
> explicitly accessed by LLVM load and store instructions and are not in 
> SSA form; it is not all of the memory within the computer.
>
> If you're interested in finding instructions that write to RAM 
> (including writes to stack spill slots), it may be better to work on 
> Machine Instructions within the code generator framework.
>
> -- John T.
>
>
>>
>> Consider:
>> ...
>> int a, b, d;
>> d = a + b;
>> ...
>>
>> The above code is turned into LLVM IR:
>>    %0 = load i32* @a, align 4
>>    %1 = load i32* @b, align 4
>>    %2 = add nsw i32 %1, %0
>>    store i32 %2, i32* @d, align 4
>>
>> Is it possible that temps such as %0, %1 and/or %2 will NOT being register allocated later in the compilation stage, and thus left in memory?
>>
>> The above code, when converted back to C level, looks like this:
>> ...
>>    unsigned int llvm_cbe_tmp__6;
>>    unsigned int llvm_cbe_tmp__7;
>>    unsigned int llvm_cbe_tmp__8;
>>    unsigned int llvm_cbe_tmp__9;
>>
>>    llvm_cbe_tmp__6 = *(&a);
>>    llvm_cbe_tmp__7 = *(&b);
>>    llvm_cbe_tmp__8 = ((unsigned int )(((unsigned int )llvm_cbe_tmp__7) + ((unsigned int )llvm_cbe_tmp__6)));
>>    *(&d) = llvm_cbe_tmp__8;
>>    llvm_cbe_tmp__9 =  /*tail*/ printf(((&_OC_str.array[((signed int )0u)])), llvm_cbe_tmp__8);
>> ...
>>
>> It seems the compiler-generated temps are _actually_ left on stack, and writes to them are actually writes to stack memory (via load, add, ...).
>>
>>
>>
>> I am confused here.
>> Could somebody help to clarify it?
>>
>> Thank you
>>
>> Chuck
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/9276a7a2/attachment.html 

From greened at obbligato.org  Fri Jan 21 17:11:58 2011
From: greened at obbligato.org (David A. Greene)
Date: Fri, 21 Jan 2011 17:11:58 -0600
Subject: [LLVMdev] [LLVMDev] Reg Alloc: Spiller::Spill question
In-Reply-To: <AANLkTi=VZNwj+f2VVFb2Tcov7pue3A1LtRqja6cukrp0@mail.gmail.com>
	(Jeff Kunkel's message of "Thu, 20 Jan 2011 20:18:21 -0500")
References: <AANLkTi=VZNwj+f2VVFb2Tcov7pue3A1LtRqja6cukrp0@mail.gmail.com>
Message-ID: <nngy66dkg1t.fsf@royale.us.cray.com>

Jeff Kunkel <jdkunk3 at gmail.com> writes:

> Spiller::Spill(?LiveInterval *li,
> ?? ? ? ? ? ? ? ? ? ? ? ? ?SmallVectorImpl<LiveInterval*> &newIntervals,
> ?? ? ? ? ? ? ? ? ? ? ? ? ?const SmallVectorImpl<LiveInterval*> &spillIs );
>
> has two reference vectors which contain a small list of?Live
> Intervals. What is the register allocator's job to do with these
> intervals other than analysis. What more needed other than to know
> they exist?

It's been a while since I looked at this, so Evan can correct any
mistakes I make.  :)

spillIs is passed into the spiller and indicates the intervals that
alias the interval being spilled.  In other words, they indicate
registers that are sub-/super-registers of the one being spilled.  These
intervals must be spilled along with the "primary" one.

I think this comes into play in linear scan when it has to force a
reallocation of a physical register and must backtrack.  The details of
this are very fuzzy to me.

The newIntervals vector gets filled in by LiveIntervalAnalysis with the
new intervals created when spilling in done.  Spilling is essentially a
splitting of a live interval into multiple sub-intervals.  Those
sub-intervals will need to be allocated to registers.  The newIntervals
output tells the register allocator the new intervals it must add to its
work queue.

                             -Dave


From Micah.Villmow at amd.com  Fri Jan 21 17:18:53 2011
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Fri, 21 Jan 2011 17:18:53 -0600
Subject: [LLVMdev] Question about porting LLVM - a single instruction op
 mnemonic with multiple operand forms
In-Reply-To: <nng39ollv7q.fsf@royale.us.cray.com>
References: <AANLkTi=Dw2SPyMUGSH-ztNUfM+pReP0cr=zuUPFCGBr5@mail.gmail.com>
	<D556DCBBC0EA924A9AC80003B621211205FBD28DA6@sausexmbp02.amd.com>
	<nng39ollv7q.fsf@royale.us.cray.com>
Message-ID: <D556DCBBC0EA924A9AC80003B621211205FBD291AA@sausexmbp02.amd.com>



> -----Original Message-----
> From: David A. Greene [mailto:greened at obbligato.org]
> Sent: Friday, January 21, 2011 2:59 PM
> To: Villmow, Micah
> Cc: Lu Mitnick; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Question about porting LLVM - a single
> instruction op mnemonic with multiple operand forms
> 
> "Villmow, Micah" <Micah.Villmow at amd.com> writes:
> 
> > I have this same problem in our backend. I solve it by adding a
> pseudo
> > instruction at instruction selection that transforms @R1 into R1, so
> > only a single pattern is required. I then can propogate the pseudo
> > instruction after instruction selection.
> 
> What's the rationale behind this approach?  It seems a bit clumsy to
> me.
> An instruction with varying addressing modes is not a single
> instruction.  They have different encodings, for starters.  Defining
> separate patterns for them is the "clean" LLVM approach.  I would think
> your approach adds the danger of the pseudo-instruction getting lost at
> some point.
[Villmow, Micah] It isn't that I have different addressing modes. There is
only a single instruction, but multiple different types of input arguments.
The pseudo instruction's that I use simplify the patterns by only requiring
me to write patterns for registers and not register, immediates, addresses
and any other operand type. So, instead of having to write patterns like
ADDrr, ADDri, ADDrs, etc.. for 16 different register classes, I only write
a single ADD multi-class pattern that takes only registers as inputs. I do 
luckily have another compiler that takes my output and generates a 
binary to remove any pseudo instructions. 

Micah
> 
> If the redundancy in specifying patterns for different addressing modes
> is the problem, I have some stuff to submit that helps with that.  It
> will probably take quite a bit of patch churn before it makes it to
> trunk, however.
> 
>                                -Dave




From criswell at illinois.edu  Fri Jan 21 17:22:11 2011
From: criswell at illinois.edu (John Criswell)
Date: Fri, 21 Jan 2011 17:22:11 -0600
Subject: [LLVMdev] all LLVM Instructions that may write to memory --
 other than StoreInst?
In-Reply-To: <4D3A0FF7.4000405@eecg.toronto.edu>
References: <4D39F197.6090306@eecg.toronto.edu> <4D3A09D7.4090603@illinois.edu>
	<4D3A0FF7.4000405@eecg.toronto.edu>
Message-ID: <4D3A1523.4090502@illinois.edu>

On 1/21/11 5:00 PM, Chuck Zhao wrote:
> John,
>
> Thanks for the reply.
> I agree with your comments that the "Memory" LLVM Spec refers to 
> doesn't include stack.

It includes stack objects (memory allocated by the alloca instruction) 
but not the stack frame (e.g., spill slots).

>
> Let me leverage a bit further:
>
> If I need to work on high-level IRs (not machine dependent, not in the 
> code-gen stage), is it reasonable to assume that
> ALL LLVM IRs that have a result field will have potential to write stack?

Strictly speaking, I would go so far as to assume that any LLVM IR 
instruction can write to the stack frame.

>
>
> E.g.
>    <result>  = add<ty>  <op1>,<op2>           /; yields {ty}:result/
>
>    br i1<cond>, label<iftrue>, label<iffalse>
>    br label<dest>           /; Unconditional branch/
>
> ADD can (potential) write stack to store its result, while BR will 
> NEVER write stack because its doesn't have a result.

You might be able to get away with this on some platforms.  However, you 
can't assume this in general; the LLVM IR makes no guarantees at all 
about which instructions read and write the stack frame and which do 
not.  The branch could load its argument from the stack frame or from a 
global value pool.  On a VLIW machine, it could be packed into an 
instruction that also contains a read/write from/to the stack frame.  
Maybe the processor only supports indirect branch instructions.

Whether you want to count on LLVM IR branches writing to the stack 
depends on what hardware architecture you're using and what you're 
doing.  If you're counting memory accesses for a heuristic only on x86, 
then assuming branches don't write to memory seems like a reasonable 
assumption.  If you need an accurate count on all supported platforms, 
I'd look into analyzing the generated machine code.

-- John T.

>
>
> Thank you
>
> Chuck
>
>
>
>
> On 1/21/2011 5:33 PM, John Criswell wrote:
>> On 1/21/11 2:50 PM, Chuck Zhao wrote:
>>> I need to figure out all LLVM Instructions that may write to memory.
>>>
>>> In http://llvm.org/docs/tutorial/OCamlLangImpl7.html, it mentions that
>>> "In LLVM, all memory accesses are explicit with load/store 
>>> instructions, and it is carefully designed not to have (or need) an 
>>> "address-of" operator."
>>>
>>> I take this as "StoreInst is the only one that writes to memory".
>>
>> There are intrinsic functions which write to memory also, such as memcpy.
>>>
>>> However, this doesn't seem to be enough.
>>
>> Your observation is correct.  Strictly speaking, any instruction can 
>> write to memory after code generation because it may access a stack 
>> spill slot or a function parameter which the ABI places on the stack.
>>
>> When the Language Reference Manual talks about writing to memory, it 
>> is talking about writing to memory that is visible at the LLVM IR 
>> level.  The stack frame is invisible at the LLVM IR level.  Put 
>> another way, "memory" is a set of memory locations which can be 
>> explicitly accessed by LLVM load and store instructions and are not 
>> in SSA form; it is not all of the memory within the computer.
>>
>> If you're interested in finding instructions that write to RAM 
>> (including writes to stack spill slots), it may be better to work on 
>> Machine Instructions within the code generator framework.
>>
>> -- John T.
>>
>>
>>>
>>> Consider:
>>> ...
>>> int a, b, d;
>>> d = a + b;
>>> ...
>>>
>>> The above code is turned into LLVM IR:
>>>    %0 = load i32* @a, align 4
>>>    %1 = load i32* @b, align 4
>>>    %2 = add nsw i32 %1, %0
>>>    store i32 %2, i32* @d, align 4
>>>
>>> Is it possible that temps such as %0, %1 and/or %2 will NOT being register allocated later in the compilation stage, and thus left in memory?
>>>
>>> The above code, when converted back to C level, looks like this:
>>> ...
>>>    unsigned int llvm_cbe_tmp__6;
>>>    unsigned int llvm_cbe_tmp__7;
>>>    unsigned int llvm_cbe_tmp__8;
>>>    unsigned int llvm_cbe_tmp__9;
>>>
>>>    llvm_cbe_tmp__6 = *(&a);
>>>    llvm_cbe_tmp__7 = *(&b);
>>>    llvm_cbe_tmp__8 = ((unsigned int )(((unsigned int )llvm_cbe_tmp__7) + ((unsigned int )llvm_cbe_tmp__6)));
>>>    *(&d) = llvm_cbe_tmp__8;
>>>    llvm_cbe_tmp__9 =  /*tail*/ printf(((&_OC_str.array[((signed int )0u)])), llvm_cbe_tmp__8);
>>> ...
>>>
>>> It seems the compiler-generated temps are _actually_ left on stack, and writes to them are actually writes to stack memory (via load, add, ...).
>>>
>>>
>>>
>>> I am confused here.
>>> Could somebody help to clarify it?
>>>
>>> Thank you
>>>
>>> Chuck
>>>
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/8b9082b7/attachment.html 

From jdkunk3 at gmail.com  Fri Jan 21 17:33:39 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Fri, 21 Jan 2011 18:33:39 -0500
Subject: [LLVMdev] [LLVMDev] Reg Alloc: Spiller::Spill question
In-Reply-To: <nngy66dkg1t.fsf@royale.us.cray.com>
References: <AANLkTi=VZNwj+f2VVFb2Tcov7pue3A1LtRqja6cukrp0@mail.gmail.com>
	<nngy66dkg1t.fsf@royale.us.cray.com>
Message-ID: <AANLkTinZ_D1Jzu0D3X3OiH-V5uB2=2FCFFt0HnUkLXen@mail.gmail.com>

Thanks, I think I have figured it out. However, I moved on to SplitEditor
class. It was quite well done; I must say. Although the SpillAnalysis is a
bit heavy-weight for the stuff I would like to do.

- Jeff

On Fri, Jan 21, 2011 at 6:11 PM, David A. Greene <greened at obbligato.org>wrote:

> Jeff Kunkel <jdkunk3 at gmail.com> writes:
>
> > Spiller::Spill( LiveInterval *li,
> >                           SmallVectorImpl<LiveInterval*> &newIntervals,
> >                           const SmallVectorImpl<LiveInterval*> &spillIs
> );
> >
> > has two reference vectors which contain a small list of Live
> > Intervals. What is the register allocator's job to do with these
> > intervals other than analysis. What more needed other than to know
> > they exist?
>
> It's been a while since I looked at this, so Evan can correct any
> mistakes I make.  :)
>
> spillIs is passed into the spiller and indicates the intervals that
> alias the interval being spilled.  In other words, they indicate
> registers that are sub-/super-registers of the one being spilled.  These
> intervals must be spilled along with the "primary" one.
>
> I think this comes into play in linear scan when it has to force a
> reallocation of a physical register and must backtrack.  The details of
> this are very fuzzy to me.
>
> The newIntervals vector gets filled in by LiveIntervalAnalysis with the
> new intervals created when spilling in done.  Spilling is essentially a
> splitting of a live interval into multiple sub-intervals.  Those
> sub-intervals will need to be allocated to registers.  The newIntervals
> output tells the register allocator the new intervals it must add to its
> work queue.
>
>                             -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/3b9ad9d5/attachment.html 

From stoklund at 2pi.dk  Fri Jan 21 20:09:39 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Fri, 21 Jan 2011 18:09:39 -0800
Subject: [LLVMdev] -ffixed option in llvm-gcc
In-Reply-To: <4D3A0F0F.60407@vt.edu>
References: <4D3A0F0F.60407@vt.edu>
Message-ID: <1425739B-1141-40A5-B03D-A78A5F89F0D0@2pi.dk>


On Jan 21, 2011, at 2:56 PM, Hari Pyla wrote:

> I was wondering if "-ffixed" option is not supported by llvm-gcc. If so 
> I was wondering what is the best approach to register shadow a global 
> variable in llvm.

LLVM doesn't support -ffixed and global register variables.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110121/f00a8518/attachment.html 

From rjmccall at apple.com  Fri Jan 21 22:46:14 2011
From: rjmccall at apple.com (John McCall)
Date: Fri, 21 Jan 2011 20:46:14 -0800
Subject: [LLVMdev] How to extend llvm IR and frontend?
In-Reply-To: <AANLkTi=eOaRPo54LHF2mdLy6p9yXAZSJodOLW66aXNzs@mail.gmail.com>
References: <AANLkTimgMX+jLa0cGa-iHiXcOJOUqg_5+nM8+TDBU2wN@mail.gmail.com>
	<AANLkTi=eOaRPo54LHF2mdLy6p9yXAZSJodOLW66aXNzs@mail.gmail.com>
Message-ID: <3B368402-A6DE-49BC-8AB5-6C9815304191@apple.com>


On Jan 21, 2011, at 10:23 AM, Frits van Bommel wrote:

> On Fri, Jan 21, 2011 at 4:32 PM, Aaron Myles Landwehr <snaphat at gmail.com> wrote:
>> Hypothetically, suppose I have a generic system with multiple address spaces
>> such that each address space is accessed using different instructions.
>> Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of
>> c variables and function return types such that the following would be
>> valid:
>> foo void* a;
>> foo void* somefunc(){...}
>> bar int b;
>> int somefunc2(bar int*){...}
> 
> How about putting
> 
>  #define foo __attribute__((address_space(256)))
>  #define bar __attribute__((address_space(257)))
> 
> in some header? (Or on the command line, or in clang's default #defines, ...)
> Though maybe they'd need to be in a slightly different place; the
> example in the documentation
> (http://clang.llvm.org/docs/LanguageExtensions.html) is
> 
>  #define GS_RELATIVE __attribute__((address_space(256)))
>  int foo(int GS_RELATIVE *P) {
>    return *P;
>  }
> 
> so maybe it won't work if they're in front of the declaration.

That would work fine.  The attribute works like a normal qualifier:  just like 'int const *'
and 'const int *' both mean "pointer to const int", 'GS_RELATIVE int *' and
'int GS_RELATIVE *' both mean "pointer to int object in address space 256".
Whereas 'int * GS_RELATIVE *' means "pointer to pointer object in address
space 256 that points to int object in generic address space".

John.

From surifilms at gmail.com  Fri Jan 21 22:46:25 2011
From: surifilms at gmail.com (Surinder)
Date: Sat, 22 Jan 2011 15:46:25 +1100
Subject: [LLVMdev] Pointers in Load and Store
In-Reply-To: <4D3907A8.6080205@illinois.edu>
References: <AANLkTimM-c3qK7xJxg6K7tABjuyZd98A8YoqPa7ZRsL4@mail.gmail.com>
	<4D3907A8.6080205@illinois.edu>
Message-ID: <AANLkTinQvssjgK4h9AYC+upgT4AMM9g_3u3evE63Vv+O@mail.gmail.com>

John,

I have looked at the SAFECode and thought following sould work

       if (isa<Constant>(I.getOperand(0)))
       { Out << "*** operand 0 is a constant ******";
         if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0)))
           { Out << "********operand is an instruction ****";
             if (GetElementPtrInst *gepI =
dyn_cast<GetElementPtrInst>(operandI))
               { Out << "*** operand is a gep instruction ********";
                 if (const ArrayType *ar =
dyn_cast<ArrayType>(gepI->getPointerOperandType()->getElementType()))
                   hi=ar->getNumElements();

But this does not recognize that operand(0) of instruction I is even
an instruction, let alone a get element pointer instruction.  I have
taken the code from line 632 and line 757 of
safecode/lib/ArrayBoundsChecks/ArrayBoundCheck.cpp

I must be doing something wrong, what is it?

Surinder Kumar Jain


PS: Yes, I will be using safecode but still I want to know why above
code does not work.  I am posting a separate mail wioth the title "OPT
optimizations"


On Fri, Jan 21, 2011 at 3:12 PM, John Criswell <criswell at illinois.edu> wrote:
> On 1/20/2011 10:02 PM, Surinder wrote:
>> When I compile C programs into llvm, it produces load instructions in
>> two different flavours.
>>
>> (1) ? ?%8 = load i8** %bp, align 8
>>
>> (2) ? ?%1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0,
>> i64 0), align 1
>>
>> I know that %bp in first case and the entire "getelementptr inbounds
>> ([4 x i8]* @.str, i64 0, i64 0)" in second case can be obtained by
>> dump'ing I.getOperand(0)
>>
>> However, I want to find out which of the two forms of load have been
>> produced because in the second case, I want to insert checks for array
>> bounds.
>>
>> How can I find out when I am in Instruction object I and I.getOpcode()
>> == 29 whether I am dealing with type (1) or type (2) above.
>
> The second load instruction is not really a "special" load instruction.
> Rather, its pointer argument is an LLVM constant expression (class
> llvm::ConstExpr). ?The Getelementptr (GEP), which would normally be a
> GEP instruction, is instead a constant expression that will be converted
> into a constant numeric value at code generation time.
>
> So, what you need to do is to examine the LoadInst's operand and see if
> its a ConstExpr, and then see whether the ConstExpr's opcode is a GEP
> opcode.
>
> However, there's an easier way to handle this. ?SAFECode
> (http://safecode.cs.illinois.edu) has an LLVM pass which converts
> constant expression GEPs into GEP instructions. ?If you run it on your
> code first, you'll get the following instruction sequence:
>
> %tmp = getelementptr inbounds ([4 x i8]* @.str, i64 0,i64 0), align 1
> %1 = load i8* %tmp
>
> You then merely search for GEP instructions and put run-time checks on
> those (which you have to do anyway if you're adding array bounds
> checking). ?The only ConstantExpr GEPs that aren't converted, I think,
> are those in global variable initializers.
>
> Now, regarding the insertion of array bounds checks, SAFECode does that,
> too (it is a memory safety compiler for C code). ?It also provides a
> simple static array bounds checker and some array bounds check
> optimization passes.
>
> I can direct you to the relevant portions of the source code if you're
> interested.
>
> -- John T.
>
>> Thanks.
>>
>> Surinder Kumar Jain
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From surifilms at gmail.com  Fri Jan 21 22:48:51 2011
From: surifilms at gmail.com (Surinder)
Date: Sat, 22 Jan 2011 15:48:51 +1100
Subject: [LLVMdev] OPT optimizations
Message-ID: <AANLkTim5975ZPR=SXvQWLn7JwehOKzst1iWfi2_Xi0MA@mail.gmail.com>

Hi,

OPT documentation mentions optimization options -O1,-O2 and -O3 etc.
(I am using -O0, no optimizations). The documentation does not tell
you what optimizations are included in each option.  It says they are
same as gcc.  gcc dodoc is not of much help either.  Where can I find
this information.

Surinder Kumar Jain

From criswell at illinois.edu  Fri Jan 21 23:08:01 2011
From: criswell at illinois.edu (John Criswell)
Date: Fri, 21 Jan 2011 23:08:01 -0600
Subject: [LLVMdev] Pointers in Load and Store
In-Reply-To: <AANLkTinQvssjgK4h9AYC+upgT4AMM9g_3u3evE63Vv+O@mail.gmail.com>
References: <AANLkTimM-c3qK7xJxg6K7tABjuyZd98A8YoqPa7ZRsL4@mail.gmail.com>	<4D3907A8.6080205@illinois.edu>
	<AANLkTinQvssjgK4h9AYC+upgT4AMM9g_3u3evE63Vv+O@mail.gmail.com>
Message-ID: <4D3A6631.60601@illinois.edu>

On 1/21/2011 10:46 PM, Surinder wrote:
> John,
>
> I have looked at the SAFECode and thought following sould work
>
>         if (isa<Constant>(I.getOperand(0)))
>         { Out<<  "*** operand 0 is a constant ******";
>           if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0)))
>             { Out<<  "********operand is an instruction ****";
>               if (GetElementPtrInst *gepI =
> dyn_cast<GetElementPtrInst>(operandI))
>                 { Out<<  "*** operand is a gep instruction ********";
>                   if (const ArrayType *ar =
> dyn_cast<ArrayType>(gepI->getPointerOperandType()->getElementType()))
>                     hi=ar->getNumElements();

> But this does not recognize that operand(0) of instruction I is even
> an instruction, let alone a get element pointer instruction.  I have
> taken the code from line 632 and line 757 of
> safecode/lib/ArrayBoundsChecks/ArrayBoundCheck.cpp
>
> I must be doing something wrong, what is it?

The problem is simple: you're looking at the wrong source file.
:)

More specifically, you're looking at the very antiquated static array 
bounds checking pass (it hasn't compiled in several years now).  The 
file you want to look at is in lib/InsertPoolChecks/insert.cpp.  This 
file contains the InsertPoolChecks pass which, in mainline SAFECode, is 
responsible for inserting array bounds checks and indirect function call 
checks.  In particular, you want to look at the addGetElementPtrChecks() 
method.

As for Constant Expression GEPs, you want to look at the BreakConstGEP 
pass, located in lib/ArrayBoundsChecks/BreakConstantGEPs.cpp.

The BreakConstantGEP pass is run first.  All it does is find 
instructions that use constant expression GEPs and replaces the Constant 
Expression GEP with a GEP instruction.  All of the other SAFECode passes 
that worry about array bounds checks (i.e., the static array bounds 
checking passes in lib/ArrayBoundsCheck and the run-time instrumentation 
pass in lib/InsertPoolChecks/insert.cpp) only look for GEP instructions.

-- John T.


> Surinder Kumar Jain
>
>
> PS: Yes, I will be using safecode but still I want to know why above
> code does not work.  I am posting a separate mail wioth the title "OPT
> optimizations"


>
> On Fri, Jan 21, 2011 at 3:12 PM, John Criswell<criswell at illinois.edu>  wrote:
>> On 1/20/2011 10:02 PM, Surinder wrote:
>>> When I compile C programs into llvm, it produces load instructions in
>>> two different flavours.
>>>
>>> (1)    %8 = load i8** %bp, align 8
>>>
>>> (2)    %1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0,
>>> i64 0), align 1
>>>
>>> I know that %bp in first case and the entire "getelementptr inbounds
>>> ([4 x i8]* @.str, i64 0, i64 0)" in second case can be obtained by
>>> dump'ing I.getOperand(0)
>>>
>>> However, I want to find out which of the two forms of load have been
>>> produced because in the second case, I want to insert checks for array
>>> bounds.
>>>
>>> How can I find out when I am in Instruction object I and I.getOpcode()
>>> == 29 whether I am dealing with type (1) or type (2) above.
>> The second load instruction is not really a "special" load instruction.
>> Rather, its pointer argument is an LLVM constant expression (class
>> llvm::ConstExpr).  The Getelementptr (GEP), which would normally be a
>> GEP instruction, is instead a constant expression that will be converted
>> into a constant numeric value at code generation time.
>>
>> So, what you need to do is to examine the LoadInst's operand and see if
>> its a ConstExpr, and then see whether the ConstExpr's opcode is a GEP
>> opcode.
>>
>> However, there's an easier way to handle this.  SAFECode
>> (http://safecode.cs.illinois.edu) has an LLVM pass which converts
>> constant expression GEPs into GEP instructions.  If you run it on your
>> code first, you'll get the following instruction sequence:
>>
>> %tmp = getelementptr inbounds ([4 x i8]* @.str, i64 0,i64 0), align 1
>> %1 = load i8* %tmp
>>
>> You then merely search for GEP instructions and put run-time checks on
>> those (which you have to do anyway if you're adding array bounds
>> checking).  The only ConstantExpr GEPs that aren't converted, I think,
>> are those in global variable initializers.
>>
>> Now, regarding the insertion of array bounds checks, SAFECode does that,
>> too (it is a memory safety compiler for C code).  It also provides a
>> simple static array bounds checker and some array bounds check
>> optimization passes.
>>
>> I can direct you to the relevant portions of the source code if you're
>> interested.
>>
>> -- John T.
>>
>>> Thanks.
>>>
>>> Surinder Kumar Jain
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>


From m.vijay at nus.edu.sg  Fri Jan 21 23:12:45 2011
From: m.vijay at nus.edu.sg (Vijayaraghavan Murali)
Date: Sat, 22 Jan 2011 13:12:45 +0800
Subject: [LLVMdev] View variable-register map
In-Reply-To: <AANLkTi=MVExNt_0HU4vk1f9dxJk0pqBbKxYuEFXxRsXd@mail.gmail.com>
References: <4D398E92.3020405@nus.edu.sg>
	<AANLkTi=MVExNt_0HU4vk1f9dxJk0pqBbKxYuEFXxRsXd@mail.gmail.com>
Message-ID: <4D3A674D.1090200@nus.edu.sg>


Thank you Frits! I noticed the following lines in the dwarf output (run 
with -O2):

     .uleb128    40              # Offset
     .byte   134                     # DW_CFA_offset + Reg (6)
     .uleb128    4               # Offset
     .byte   135                     # DW_CFA_offset + Reg (7)
     .uleb128    3               # Offset
     .byte   131                     # DW_CFA_offset + Reg (3)

I think this is the closest to some sort of register "mapping", that I 
*think* changes wrt to the live intervals in the program. But there is 
no information about variables to which the registers are mapped.

Actually, it's fine because I don't necessarily need the 
variable-register map. Even the number of registers used would suffice, 
which I can obtain from the above. But, can you just confirm if this is 
the result of register allocation and that the "Reg (#)" lines represent 
the different registers used?

Thank you once again!

Vijay


On 01/21/2011 10:03 PM, Frits van Bommel wrote:
> On Fri, Jan 21, 2011 at 2:48 PM, Vijayaraghavan Murali
> <m.vijay at nus.edu.sg>  wrote:
>> I just wish to know if other than manually comparing the llc generated
>> code with the source program, is there any other way of knowing which
>> variables in the program are mapped to which registers? I was not able
>> to find any suitable option for the same, so I'm wondering if there is a
>> workaround.
>
> Isn't this exactly one of the things debug information is for?
> You'd need to compile with -g and somehow read the DWARF information
> generated. As a bonus, this should work with gcc output too.
>
> You'd still be comparing llc output with the source code[1], but you
> no longer need to do it manually :).
>
>
> [1]: Or the clang AST, I suppose.

From grosser at fim.uni-passau.de  Fri Jan 21 23:17:08 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Sat, 22 Jan 2011 00:17:08 -0500
Subject: [LLVMdev] OPT optimizations
In-Reply-To: <AANLkTim5975ZPR=SXvQWLn7JwehOKzst1iWfi2_Xi0MA@mail.gmail.com>
References: <AANLkTim5975ZPR=SXvQWLn7JwehOKzst1iWfi2_Xi0MA@mail.gmail.com>
Message-ID: <4D3A6854.3080003@fim.uni-passau.de>

On 01/21/2011 11:48 PM, Surinder wrote:
> Hi,
>
> OPT documentation mentions optimization options -O1,-O2 and -O3 etc.
> (I am using -O0, no optimizations). The documentation does not tell
> you what optimizations are included in each option.  It says they are
> same as gcc.  gcc dodoc is not of much help either.  Where can I find
> this information.

Just call

opt -O3 -debug-pass=Arguments program.ll

which prints the list of passes executed.

Cheers
Tobi

From king19880326 at gmail.com  Sat Jan 22 01:09:54 2011
From: king19880326 at gmail.com (Lu Mitnick)
Date: Sat, 22 Jan 2011 15:09:54 +0800
Subject: [LLVMdev] Question about porting LLVM - code selection without
	assembler feature
Message-ID: <AANLkTikzW3GpL5a8h59Pr7eMcK897NSR60Krw6M8o-2R@mail.gmail.com>

Hello all,

I am adding a new target into LLVM. However there is a assembler for that
target and I just want LLVM to generate assembly. I read the document
"Writing an LLVM Backend". I am wondering to know whether I can ignore the
Inst field in the following example:

class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> :
Instruction {

  field bits<32> Inst;
  let Namespace = "SP";
  bits<2> op;
  let Inst{31-30} = op;
  dag OutOperandList = outs;
  dag InOperandList = ins;
  let AsmString   = asmstr;
  let Pattern = pattern;
}

And define the instruction class of ported target as:

class Instxxx<dag outs, dag ins, string asmstr, list<dag> pattern> :
Instruction {

  let Namespace = "xxx";
  dag OutOperandList = outs;
  dag InOperandList = ins;
  let AsmString   = asmstr;
  let Pattern = pattern;
}

Second, I have read the documentation of "TableGen Fundamentals" and
"The LLVM Target Independent Code Generator". But I don't know how to
fill the dag filed of instruction. like [(store IntRegs:$src,
ADDRrr:$addr)] of the following example:

def STrr  : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),

               "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]>;


Would anyone mind to tell me where to find the documentation of the
dag in Independent Code Generator??


thanks a lot


yi-hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110122/20d7c4fb/attachment.html 

From fvbommel at gmail.com  Sat Jan 22 03:01:58 2011
From: fvbommel at gmail.com (Frits van Bommel)
Date: Sat, 22 Jan 2011 10:01:58 +0100
Subject: [LLVMdev] View variable-register map
In-Reply-To: <4D3A674D.1090200@nus.edu.sg>
References: <4D398E92.3020405@nus.edu.sg>
	<AANLkTi=MVExNt_0HU4vk1f9dxJk0pqBbKxYuEFXxRsXd@mail.gmail.com>
	<4D3A674D.1090200@nus.edu.sg>
Message-ID: <AANLkTinCygJ5=Q0As8spru4zT0WiqOqpZ1jTqvVJkmUZ@mail.gmail.com>

On Sat, Jan 22, 2011 at 6:12 AM, Vijayaraghavan Murali
<m.vijay at nus.edu.sg> wrote:
>
> Thank you Frits! I noticed the following lines in the dwarf output (run with
> -O2):
>
> ? ?.uleb128 ? ?40 ? ? ? ? ? ? ?# Offset
> ? ?.byte ? 134 ? ? ? ? ? ? ? ? ? ? # DW_CFA_offset + Reg (6)
> ? ?.uleb128 ? ?4 ? ? ? ? ? ? ? # Offset
> ? ?.byte ? 135 ? ? ? ? ? ? ? ? ? ? # DW_CFA_offset + Reg (7)
> ? ?.uleb128 ? ?3 ? ? ? ? ? ? ? # Offset
> ? ?.byte ? 131 ? ? ? ? ? ? ? ? ? ? # DW_CFA_offset + Reg (3)
>
> I think this is the closest to some sort of register "mapping", that I
> *think* changes wrt to the live intervals in the program. But there is no
> information about variables to which the registers are mapped.

There should be an encoding of variable names somewhere. I don't
really know how to read debug info myself though, so I'm not sure
where exactly.
There's probably some library that can help though. A quick bit of
googling points to libdwarf:
<http://reality.sgiweb.org/davea/dwarf.html>

> Actually, it's fine because I don't necessarily need the variable-register
> map. Even the number of registers used would suffice, which I can obtain
> from the above. But, can you just confirm if this is the result of register
> allocation and that the "Reg (#)" lines represent the different registers
> used?

Like I said, I don't really know how to read DWARF. But maybe someone
else on this list can enlighten you?


From baldrick at free.fr  Sat Jan 22 05:17:53 2011
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 22 Jan 2011 12:17:53 +0100
Subject: [LLVMdev] all LLVM Instructions that may write to memory --
 other than StoreInst?
In-Reply-To: <4D39F197.6090306@eecg.toronto.edu>
References: <4D39F197.6090306@eecg.toronto.edu>
Message-ID: <4D3ABCE1.6060500@free.fr>

Hi Chuck,

> I need to figure out all LLVM Instructions that may write to memory.

I->mayWriteToMemory()

Ciao, Duncan.

From renato.golin at arm.com  Sat Jan 22 06:05:53 2011
From: renato.golin at arm.com (Renato Golin)
Date: Sat, 22 Jan 2011 12:05:53 +0000
Subject: [LLVMdev] Target Triple Changes
Message-ID: <AANLkTi=h-VJYxLc4E0wD39M-5=9sQpDt_MvHHjv4tWQf@mail.gmail.com>

Hi all,

There's been some controversies in the TargetTriple changes and I want
to explain it better in the list (to a wider audience) and also
propose my plans on how to support the ARM platform better, especially
cross-compilation in Clang.

All this discussion came as a spin-off of bug 8911
(http://llvm.org/bugs/show_bug.cgi?id=8957)...

Today we have three major problems in cross-compiling to ARM with Clang:

 1. Some ARM triples "arm*-none-eabi" don't get properly recognized,
so Clang doesn't generate correct AAPCS (soft and hard) calls and
don't pass the correct triple to LLC.

 2. Some options in Clang are chosen by parsing the triple directly,
because triples don't have all properties necessary to make such
decisions.

 3. Clang today has only host-triple, which is inaccurate to describe
a cross-compilation  environment, when the difference between the host
and the target matters when the driver is choosing what to run and
what options to pass.


To fix that, I think we needs three things:

 1. Adding the options to the triple, so EABI can be recognized and
properly stored to avoid string comparisons. This is not as simple as
it seems because "arm-none-eabi" actually puts EABI in the OS slot,
and the triple validation breaks before it gets to parsing the
environment, because OS is actually invalid. There are some
alternatives (such as split: normalization / validation and do special
fiddling in between) but the main problem is that the triple logic is
not written in stone and different vendors use different styles.

 2. Clang parses - if arch.contains("v6") - which is not ideal. Clang
should have a localized parse for sub-architectures (only important
for ARM, I believe) and fill in TargetData objects with all
information it can gather (by also using the other triple properties)
to make every IR / command line generation decision based on that. I
don't know why Clang calls LLC with command line options instead of
just calling the back-end directly passing the TargetData, but it
doesn't make that much difference.

 3. Once all that support is in place, implement a target triple and
use it for codegen/cmd-line choices, while the host triple is still
used to choose what binaries to call by the driver.

I hope all that makes sense, and if so, I plan on working on that.

-- 
cheers,
--renato

From czhao at eecg.toronto.edu  Sat Jan 22 08:07:30 2011
From: czhao at eecg.toronto.edu (Chuck Zhao)
Date: Sat, 22 Jan 2011 09:07:30 -0500
Subject: [LLVMdev] all LLVM Instructions that may write to memory --
 other than StoreInst?
In-Reply-To: <4D3ABCE1.6060500@free.fr>
References: <4D39F197.6090306@eecg.toronto.edu> <4D3ABCE1.6060500@free.fr>
Message-ID: <4D3AE4A2.8020906@eecg.toronto.edu>

Duncan,

I looked at this function even before starting the discussions.

I think it respects LLVM's principle that only Loads and Stores (+VAArg, 
and maybe Call) that can access global memory, but doesn't address the 
issues of accessing stack frames or stack objects.

Thank you for the hint.

Chuck

On 1/22/2011 6:17 AM, Duncan Sands wrote:
> Hi Chuck,
>
>> I need to figure out all LLVM Instructions that may write to memory.
> I->mayWriteToMemory()
>
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From surifilms at gmail.com  Sat Jan 22 19:19:13 2011
From: surifilms at gmail.com (Surinder)
Date: Sun, 23 Jan 2011 12:19:13 +1100
Subject: [LLVMdev] Pointers in Load and Store
In-Reply-To: <4D3A6631.60601@illinois.edu>
References: <AANLkTimM-c3qK7xJxg6K7tABjuyZd98A8YoqPa7ZRsL4@mail.gmail.com>
	<4D3907A8.6080205@illinois.edu>
	<AANLkTinQvssjgK4h9AYC+upgT4AMM9g_3u3evE63Vv+O@mail.gmail.com>
	<4D3A6631.60601@illinois.edu>
Message-ID: <AANLkTimQxB8DcHg7RT0DWyNai_3obRTTCgvZgMOrXv3y@mail.gmail.com>

John,

I have looked at the real code (instead of the obsolete one) and it
appears to be easy to find if an operand is a getelementptr
instruction.

  if (ConstantExpr * CE = dyn_cast<ConstantExpr>(I.getOperand(0)))
    { Out<<  "*** operand 0 is a constant Expr******";
       if (CE->getOpcode() == Instruction::GetElementPtr)
         { Out<<  "*** operand 0 is a gep instruction ********";
           if (const ArrayType *ar =
dyn_cast<ArrayType>(CE->getPointerOperandType()->getElementType()))
              hi=ar->getNumElements();

Thank you for that.

I would like to use safecode programs rather than write my own code.
However, the website of safecode says that it works only with version
2.6 or 2.7 of llvm whereas I use version 2.8 of llvm.

To get around the problem, I plan to do as follows :

(1)  Do not install safecode with llvm 2.8 (as it may or may not work)

(2)  Create a new pass named "unGep", "Breaks Constant GEPs"

(3) The new pass derives from FunctionPass (because safecode does so,
if I had to write it, ModulePass would have been good enough.)

(4) The RunOnFunction method of the unGep pass invokes
addPoolChecks(F) passing it the function F.  I will modify
addGetElementPtrChecks so that it produces array bounds in the way I
need. (I need a check that array bounds are being voilated for my
reaserch to detect overflows.)

I will then run opt as

opt -load../unGep.so

to produce llvm code without geps as operands.

Please advise if this will work or if there is an easier way.

Thanks.

Surinder Kumar Jain


On Sat, Jan 22, 2011 at 4:08 PM, John Criswell <criswell at illinois.edu> wrote:
> On 1/21/2011 10:46 PM, Surinder wrote:
>>
>> John,
>>
>> I have looked at the SAFECode and thought following sould work
>>
>> ? ? ? ?if (isa<Constant>(I.getOperand(0)))
>> ? ? ? ?{ Out<< ?"*** operand 0 is a constant ******";
>> ? ? ? ? ?if (Instruction *operandI =
>> dyn_cast<Instruction>(I.getOperand(0)))
>> ? ? ? ? ? ?{ Out<< ?"********operand is an instruction ****";
>> ? ? ? ? ? ? ?if (GetElementPtrInst *gepI =
>> dyn_cast<GetElementPtrInst>(operandI))
>> ? ? ? ? ? ? ? ?{ Out<< ?"*** operand is a gep instruction ********";
>> ? ? ? ? ? ? ? ? ?if (const ArrayType *ar =
>> dyn_cast<ArrayType>(gepI->getPointerOperandType()->getElementType()))
>> ? ? ? ? ? ? ? ? ? ?hi=ar->getNumElements();
>
>> But this does not recognize that operand(0) of instruction I is even
>> an instruction, let alone a get element pointer instruction. ?I have
>> taken the code from line 632 and line 757 of
>> safecode/lib/ArrayBoundsChecks/ArrayBoundCheck.cpp
>>
>> I must be doing something wrong, what is it?
>
> The problem is simple: you're looking at the wrong source file.
> :)
>
> More specifically, you're looking at the very antiquated static array bounds
> checking pass (it hasn't compiled in several years now). ?The file you want
> to look at is in lib/InsertPoolChecks/insert.cpp. ?This file contains the
> InsertPoolChecks pass which, in mainline SAFECode, is responsible for
> inserting array bounds checks and indirect function call checks. ?In
> particular, you want to look at the addGetElementPtrChecks() method.
>
> As for Constant Expression GEPs, you want to look at the BreakConstGEP pass,
> located in lib/ArrayBoundsChecks/BreakConstantGEPs.cpp.
>
> The BreakConstantGEP pass is run first. ?All it does is find instructions
> that use constant expression GEPs and replaces the Constant Expression GEP
> with a GEP instruction. ?All of the other SAFECode passes that worry about
> array bounds checks (i.e., the static array bounds checking passes in
> lib/ArrayBoundsCheck and the run-time instrumentation pass in
> lib/InsertPoolChecks/insert.cpp) only look for GEP instructions.
>
> -- John T.
>
>
>> Surinder Kumar Jain
>>
>>
>> PS: Yes, I will be using safecode but still I want to know why above
>> code does not work. ?I am posting a separate mail wioth the title "OPT
>> optimizations"
>
>
>>
>> On Fri, Jan 21, 2011 at 3:12 PM, John Criswell<criswell at illinois.edu>
>> ?wrote:
>>>
>>> On 1/20/2011 10:02 PM, Surinder wrote:
>>>>
>>>> When I compile C programs into llvm, it produces load instructions in
>>>> two different flavours.
>>>>
>>>> (1) ? ?%8 = load i8** %bp, align 8
>>>>
>>>> (2) ? ?%1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0,
>>>> i64 0), align 1
>>>>
>>>> I know that %bp in first case and the entire "getelementptr inbounds
>>>> ([4 x i8]* @.str, i64 0, i64 0)" in second case can be obtained by
>>>> dump'ing I.getOperand(0)
>>>>
>>>> However, I want to find out which of the two forms of load have been
>>>> produced because in the second case, I want to insert checks for array
>>>> bounds.
>>>>
>>>> How can I find out when I am in Instruction object I and I.getOpcode()
>>>> == 29 whether I am dealing with type (1) or type (2) above.
>>>
>>> The second load instruction is not really a "special" load instruction.
>>> Rather, its pointer argument is an LLVM constant expression (class
>>> llvm::ConstExpr). ?The Getelementptr (GEP), which would normally be a
>>> GEP instruction, is instead a constant expression that will be converted
>>> into a constant numeric value at code generation time.
>>>
>>> So, what you need to do is to examine the LoadInst's operand and see if
>>> its a ConstExpr, and then see whether the ConstExpr's opcode is a GEP
>>> opcode.
>>>
>>> However, there's an easier way to handle this. ?SAFECode
>>> (http://safecode.cs.illinois.edu) has an LLVM pass which converts
>>> constant expression GEPs into GEP instructions. ?If you run it on your
>>> code first, you'll get the following instruction sequence:
>>>
>>> %tmp = getelementptr inbounds ([4 x i8]* @.str, i64 0,i64 0), align 1
>>> %1 = load i8* %tmp
>>>
>>> You then merely search for GEP instructions and put run-time checks on
>>> those (which you have to do anyway if you're adding array bounds
>>> checking). ?The only ConstantExpr GEPs that aren't converted, I think,
>>> are those in global variable initializers.
>>>
>>> Now, regarding the insertion of array bounds checks, SAFECode does that,
>>> too (it is a memory safety compiler for C code). ?It also provides a
>>> simple static array bounds checker and some array bounds check
>>> optimization passes.
>>>
>>> I can direct you to the relevant portions of the source code if you're
>>> interested.
>>>
>>> -- John T.
>>>
>>>> Thanks.
>>>>
>>>> Surinder Kumar Jain
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>
>


From surifilms at gmail.com  Sun Jan 23 00:30:58 2011
From: surifilms at gmail.com (Surinder)
Date: Sun, 23 Jan 2011 17:30:58 +1100
Subject: [LLVMdev] Undoing SSA and Phi instructions
Message-ID: <AANLkTimZWe3BqnRSp-bn_UGkr84_k9kxFH_nr-4ja7UK@mail.gmail.com>

Hi,

I am emitting llvm bit code using

llvm-gcc -c -emit-llvm -O0 -o test.bc test.c

and then optimizing it with

opt -O3 -print-module test.bc

in order to obtain a dump of generated IR.


The resulting code has Phi nodes and is perhaps in SSA form.  I want
to undo the SSA form while retaining all the other optimizations.  Is
mem2reg the right optimization to be added after -O3, i.e.,

opt -O3 -mem2reg -print-module test.bc

will print the llvm in non-SSA form with no Phi nodes.

Surinder

From nicholas at mxc.ca  Sun Jan 23 00:45:12 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 22 Jan 2011 22:45:12 -0800
Subject: [LLVMdev] Undoing SSA and Phi instructions
In-Reply-To: <AANLkTimZWe3BqnRSp-bn_UGkr84_k9kxFH_nr-4ja7UK@mail.gmail.com>
References: <AANLkTimZWe3BqnRSp-bn_UGkr84_k9kxFH_nr-4ja7UK@mail.gmail.com>
Message-ID: <4D3BCE78.6010301@mxc.ca>

On 01/22/2011 10:30 PM, Surinder wrote:
> Hi,
>
> I am emitting llvm bit code using
>
> llvm-gcc -c -emit-llvm -O0 -o test.bc test.c
>
> and then optimizing it with
>
> opt -O3 -print-module test.bc
>
> in order to obtain a dump of generated IR.
>
>
> The resulting code has Phi nodes and is perhaps in SSA form.  I want
> to undo the SSA form while retaining all the other optimizations.  Is
> mem2reg the right optimization to be added after -O3, i.e.,
>
> opt -O3 -mem2reg -print-module test.bc
>
> will print the llvm in non-SSA form with no Phi nodes.

I think you're looking for "opt -O3 -reg2mem -S test.bc" though I don't 
think it *guarantees* that it will remove all phi nodes. I don't think 
we have anything besides codegen that does.

Nick

From baldrick at free.fr  Sun Jan 23 06:44:37 2011
From: baldrick at free.fr (Duncan Sands)
Date: Sun, 23 Jan 2011 13:44:37 +0100
Subject: [LLVMdev] all LLVM Instructions that may write to memory --
 other than StoreInst?
In-Reply-To: <4D3AE4A2.8020906@eecg.toronto.edu>
References: <4D39F197.6090306@eecg.toronto.edu> <4D3ABCE1.6060500@free.fr>
	<4D3AE4A2.8020906@eecg.toronto.edu>
Message-ID: <4D3C22B5.2060407@free.fr>

Hi Chuck,

> I looked at this function even before starting the discussions.
>
> I think it respects LLVM's principle that only Loads and Stores (+VAArg,
> and maybe Call) that can access global memory, but doesn't address the
> issues of accessing stack frames or stack objects.

I think you need to look at the code generators, since what you're asking
doesn't make much sense at the IR level.  For example pretty much *any*
IR instruction could result in accessing the stack if the code generator
spilled registers to the stack.

Ciao, Duncan.

>
> Thank you for the hint.
>
> Chuck
>
> On 1/22/2011 6:17 AM, Duncan Sands wrote:
>> Hi Chuck,
>>
>>> I need to figure out all LLVM Instructions that may write to memory.
>> I->mayWriteToMemory()
>>
>> Ciao, Duncan.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From baldrick at free.fr  Sun Jan 23 07:33:21 2011
From: baldrick at free.fr (Duncan Sands)
Date: Sun, 23 Jan 2011 14:33:21 +0100
Subject: [LLVMdev] Target Triple Changes
In-Reply-To: <AANLkTi=h-VJYxLc4E0wD39M-5=9sQpDt_MvHHjv4tWQf@mail.gmail.com>
References: <AANLkTi=h-VJYxLc4E0wD39M-5=9sQpDt_MvHHjv4tWQf@mail.gmail.com>
Message-ID: <4D3C2E21.9010208@free.fr>

Hi Renato,

>   1. Some ARM triples "arm*-none-eabi" don't get properly recognized,
> so Clang doesn't generate correct AAPCS (soft and hard) calls and
> don't pass the correct triple to LLC.

in order to have "eabi" be properly recognized by LLVM, it is enough to
add "eabi" as a valid environment value.  Then Triple::Normalize will
automatically move eabi to the environment position, resulting in
arm*-none--eabi  So I think this is easy to take care of.

>   2. Some options in Clang are chosen by parsing the triple directly,
> because triples don't have all properties necessary to make such
> decisions.

I think that's a good thing!  Clang's needs are different to LLVM's, so
probably clang should have it's own ClangTriple class.  Given a triple
string you probably first want to have Triple::Normalize crunch on it,
permuting recognized components into the correct positions, and then
have ClangTriple apply additional logic.

>   1. Adding the options to the triple, so EABI can be recognized and
> properly stored to avoid string comparisons. This is not as simple as
> it seems because "arm-none-eabi" actually puts EABI in the OS slot,

That's because Triple doesn't (or didn't) know that eabi is a valid value
for  environment.  If it did then Normalize would move it to the right
position.

Ciao, Duncan.

From renato.golin at arm.com  Sun Jan 23 14:38:38 2011
From: renato.golin at arm.com (Renato Golin)
Date: Sun, 23 Jan 2011 20:38:38 +0000
Subject: [LLVMdev] Target Triple Changes
In-Reply-To: <4D3C2E21.9010208@free.fr>
References: <AANLkTi=h-VJYxLc4E0wD39M-5=9sQpDt_MvHHjv4tWQf@mail.gmail.com>
	<4D3C2E21.9010208@free.fr>
Message-ID: <AANLkTi=nePkQcPRS+Vs1JOugOPifwyGojHRKzdDRixpO@mail.gmail.com>

On 23 January 2011 13:33, Duncan Sands <baldrick at free.fr> wrote:
> in order to have "eabi" be properly recognized by LLVM, it is enough to
> add "eabi" as a valid environment value. ?Then Triple::Normalize will
> automatically move eabi to the environment position, resulting in
> arm*-none--eabi ?So I think this is easy to take care of.

That could work, if Clang/LLVM could work around the "--" issue. When
looking for "arm-none-eabi.gcc", clang would never find a
"arm-none--eabi-gcc". We could do a "canonicalTriple" to print the
proper way (with two dashes) and a "compressedTriple" printing the
expected by GCC. That would make my change in the normalization
redundant, but would require some cleanup in Clang (which I'm not that
familiar). But I think this is also not the best way to fix the
problem, see below...


> I think that's a good thing! ?Clang's needs are different to LLVM's, so
> probably clang should have it's own ClangTriple class. ?Given a triple
> string you probably first want to have Triple::Normalize crunch on it,
> permuting recognized components into the correct positions, and then
> have ClangTriple apply additional logic.

I agree that Clang has different needs and probably ClangTriple should
extend Triple in that way, but that's not what's happening. Clang
parses independently and messes up when passing the triple back to
LLC. It should keep the triple intact or parse it completely,

And, given that Clang only parses triples from the command-line and
LLVM only parses it from the IR, if the parser is different (ie, when
Clang passes it via command-line to llc) , you might get different
results from the LLVM's parser (Triple) and the Clang parser
(ClangTriple -> Triple).

Adding the fact that Clang calls LLC instead of invoking the back-end
directly using TargetData and setting the rest of the options
directly, we have a design decision in our hands, that I was expecting
to delay to the second cycle.

In my view, there are two ways of doing this:

 1. Have a very basic Triple class (removing the Env-to-OS feature
I've added), extending ClangTriple to parse ARM sub-architectures,
Env-to-OS idiosyncrasy and create a TargetData object from the
difference between ClangTriple and Triple, and setting all
sub-architecture parameters (AAPCS, EABI, VFP, hardFP, softFP, etc)
directly on the back-end properties and invoking the back-end
directly.

 2. Have Clang to call LLC via command-line, where we're forced to
have the same triple parser for both cases (LLVM's Triple), or face
the difference in attributes when coming from Clang or LLC directly
via command line.

I prefer the first path, but I have actually coded the second. Why?
Because I didn't want to break everything. I just wanted to add EABI
to Environment, but that brought all the other problems. So I had a
choice: either re-factor the whole Clang-LLC interaction or do the
required modification to have it working with the current design, even
if it was a bit ugly.

To be honest, this change doesn't fix our cross-compilation problems,
but it was the first toe in the cold water, to get *precisely* the
feed-back you're giving us... ;)

Hope this makes things a bit more clear.

cheers,
--renato


From surifilms at gmail.com  Sun Jan 23 22:35:38 2011
From: surifilms at gmail.com (Surinder)
Date: Mon, 24 Jan 2011 15:35:38 +1100
Subject: [LLVMdev] LLVM grammar for ANTLR
Message-ID: <AANLkTikv=LQiXL3ZQHAdgQ68kVN_L0Q7PpibVKxeP4VU@mail.gmail.com>

Has anyone written a grammar for LLVM for ANTLR.  I mean an ANTLR
grammar that parses LLVM instructions.  Is an LLVM grammar available
for any other parsing tool?

Surinder

From neda8664 at gmail.com  Mon Jan 24 00:26:15 2011
From: neda8664 at gmail.com (neda 8664)
Date: Mon, 24 Jan 2011 09:56:15 +0330
Subject: [LLVMdev] extract thread form sequential program
Message-ID: <AANLkTi=66Z4WOAyQS698nNfBXJb8eMtfYLfn+kyPXhmc@mail.gmail.com>

Hi ,
how i can assign instruction of program to a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/8c87ab35/attachment.html 

From harel.cain at gmail.com  Mon Jan 24 03:56:18 2011
From: harel.cain at gmail.com (Harel Cain)
Date: Mon, 24 Jan 2011 11:56:18 +0200
Subject: [LLVMdev] How to create an IntegerType of the native word size
Message-ID: <AANLkTinC=Z7HYiMqM_ys8mg9__Td2KGqUBAx_cG_DMYJ@mail.gmail.com>

Hi all,

I couldn't find any reasonable way to create the IntegerType that would
match, say, intptr_t, that is the native word size of the machine I'm
building on. More accurately defined, when compiling on a 64 bit Mac OS
machine I want it to be Int64Ty, but if for example I'm using the "-arch
i386" command line option on that machine during compilation, I want it to
be Int32Ty.

I'm sure that has to be some perfect solution out there, does anyone know?


Thanks!

Harel Cain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/fdd53a9e/attachment.html 

From baldrick at free.fr  Mon Jan 24 04:18:19 2011
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 24 Jan 2011 11:18:19 +0100
Subject: [LLVMdev] extract thread form sequential program
In-Reply-To: <AANLkTi=66Z4WOAyQS698nNfBXJb8eMtfYLfn+kyPXhmc@mail.gmail.com>
References: <AANLkTi=66Z4WOAyQS698nNfBXJb8eMtfYLfn+kyPXhmc@mail.gmail.com>
Message-ID: <4D3D51EB.2080400@free.fr>

Hi neda 8664,

> how i can assign instruction of program to a thread?

LLVM doesn't have special support for threads, you need to call library
functions the same as you would from C.  I suggest you write some C code
that does what you want, then run it through http://llvm.org/demo/ to see
the corresponding LLVM IR.

Ciao, Duncan.

From baldrick at free.fr  Mon Jan 24 04:22:09 2011
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 24 Jan 2011 11:22:09 +0100
Subject: [LLVMdev] How to create an IntegerType of the native word size
In-Reply-To: <AANLkTinC=Z7HYiMqM_ys8mg9__Td2KGqUBAx_cG_DMYJ@mail.gmail.com>
References: <AANLkTinC=Z7HYiMqM_ys8mg9__Td2KGqUBAx_cG_DMYJ@mail.gmail.com>
Message-ID: <4D3D52D1.8040005@free.fr>

Hi Harel Cain,

> I couldn't find any reasonable way to create the IntegerType that would match,
> say, intptr_t, that is the native word size of the machine I'm building on. More
> accurately defined, when compiling on a 64 bit Mac OS machine I want it to be
> Int64Ty, but if for example I'm using the "-arch i386" command line option on
> that machine during compilation, I want it to be Int32Ty.
>
> I'm sure that has to be some perfect solution out there, does anyone know?

try the getIntPtrType method defined in TargetData.  It is defined in TargetData
because you need to know the target in order to know the size of a pointer.

Ciao, Duncan.

From etherzhhb at gmail.com  Mon Jan 24 04:25:19 2011
From: etherzhhb at gmail.com (ether zhhb)
Date: Mon, 24 Jan 2011 18:25:19 +0800
Subject: [LLVMdev] How to create an IntegerType of the native word size
In-Reply-To: <AANLkTinC=Z7HYiMqM_ys8mg9__Td2KGqUBAx_cG_DMYJ@mail.gmail.com>
References: <AANLkTinC=Z7HYiMqM_ys8mg9__Td2KGqUBAx_cG_DMYJ@mail.gmail.com>
Message-ID: <AANLkTi=i4Ktprq7jvyKEyncSNOzMJDkZxB3BzpDzhOwU@mail.gmail.com>

hi,

You may try TargetData's "getIntPtrType" for intptr_t.

best regards
ether

On Mon, Jan 24, 2011 at 5:56 PM, Harel Cain <harel.cain at gmail.com> wrote:
> Hi all,
>
> I couldn't find any reasonable way to create the IntegerType that would
> match, say, intptr_t, that is the native word size of the machine I'm
> building on. More accurately defined, when compiling on a 64 bit Mac OS
> machine I want it to be Int64Ty, but if for example I'm using the "-arch
> i386" command line option on that machine during compilation, I want it to
> be Int32Ty.
>
> I'm sure that has to be some perfect solution out there, does anyone know?
>
>
> Thanks!
>
> Harel Cain
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From bijoy123_8 at yahoo.com  Mon Jan 24 04:51:29 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Mon, 24 Jan 2011 02:51:29 -0800 (PST)
Subject: [LLVMdev] Error in compiling "Hello World" in a LLVM-GCC cross
	crosscompiler
Message-ID: <298814.83314.qm@web121702.mail.ne1.yahoo.com>

Hi,
???I use the crosstool build script to build a crosscompiler for ARM.?I get the following error when compilng "helloworld" program:
?
llvm-gcc hello.c -o hello
?
as: unrecognized option `-meabi=4' 
?
I?know that?the reason is not to get proper cross assembler. It tries to use the native assembler but I am unable to fix the problem. I use 
llvm-gcc -### hello.c -o hello and see the following going on:
?
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: /MinGW/llvm-project/src/llvm-gcc-4.2/configure --enable-languag
es=c --enable-bindings=none --disable-threads --enable-llvm=/usr/local/crosstool
/arm-none-linux-gnueabi/llvm --disable-gold --disable-multilib --prefix=/usr/loc
al/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2 --disable-shared --disable-libs
sp --program-prefix=llvm- --disable-bootstrap --disable-libmudflap --target=arm-
none-linux-gnueabi --disable-libstdcxx-pch --enable-optimized --with-as=/usr/loc
al/crosstool/codesourcery/arm-2010q1/bin/arm-none-linux-gnueabi-as --with-ld=/us
r/local/crosstool/codesourcery/arm-2010q1/bin/arm-none-linux-gnueabi-ld --with-s
ysroot=/usr/local/crosstool/codesourcery/arm-2010q1/arm-none-linux-gnueabi/libc
Thread model: single
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
?"c:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/bin/../l
ibexec/gcc/arm-none-linux-gnueabi/4.2.1/cc1.exe" "-quiet" "-iprefix" "c:\\mingw\
\msys\\1.0\\local\\crosstool\\arm-none-linux-gnueabi\\llvm-gcc-4.2\\bin\\../lib/
gcc/arm-none-linux-gnueabi/4.2.1/" "hello.c" "-quiet" "-dumpbase" "hello.c" "-au
xbase" "hello" "-o" "D:/DOCUME~2/AZIM/LOCALS~1/Temp/ccO28l0y.s"
?"as" "-meabi=4" "-o" "D:/DOCUME~2/AZIM/LOCALS~1/Temp/ccs3L4rX.o" "D:/DOCUME~2/A
ZIM/LOCALS~1/Temp/ccO28l0y.s"
?"c:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/bin/../l
ibexec/gcc/arm-none-linux-gnueabi/4.2.1/collect2.exe" "--sysroot=C:/MinGW/msys/1
.0/local/crosstool/codesourcery/arm-2010q1/arm-none-linux-gnueabi/libc" "--eh-fr
ame-hdr" "-dynamic-linker" "/lib/ld-linux.so.3" "-X" "-m" "armelf_linux_eabi" "-
o" "hello" "C:/MinGW/msys/1.0/local/crosstool/codesourcery/arm-2010q1/arm-none-l
inux-gnueabi/libc/usr/lib/crt1.o" "C:/MinGW/msys/1.0/local/crosstool/codesourcer
y/arm-2010q1/arm-none-linux-gnueabi/libc/usr/lib/crti.o" "c:/mingw/msys/1.0/loca
l/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/bin/../lib/gcc/arm-none-linux-gn
ueabi/4.2.1/crtbegin.o" "-Lc:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnue
abi/llvm-gcc-4.2/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1" "-Lc:/mingw/msys/1
.0/local/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/bin/../lib/gcc" "-LC:/Min
GW/msys/1.0/local/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/lib/gcc/arm-none
-linux-gnueabi/4.2.1" "-Lc:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnueab
i/llvm-gcc-4.2/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-
linux-gnueabi/lib" "-LC:/MinGW/msys/1.0/local/crosstool/arm-none-linux-gnueabi/l
lvm-gcc-4.2/lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnue
abi/lib" "-LC:/MinGW/msys/1.0/local/crosstool/codesourcery/arm-2010q1/arm-none-l
inux-gnueabi/libc/lib" "-LC:/MinGW/msys/1.0/local/crosstool/codesourcery/arm-201
0q1/arm-none-linux-gnueabi/libc/usr/lib" "D:/DOCUME~2/AZIM/LOCALS~1/Temp/ccs3L4r
X.o" "-lgcc" "-lc" "-lgcc" "c:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnu
eabi/llvm-gcc-4.2/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/crtend.o" "C:/MinG
W/msys/1.0/local/crosstool/codesourcery/arm-2010q1/arm-none-linux-gnueabi/libc/u
sr/lib/crtn.o"
?
I also use the following commands to see where is linker and assembler. 
?
$ which as
?
/mingw/bin/as.exe
?
$ which ld
?
/mingw/bin/ld.exe
?
It will be great if I get any suggestions or comments. Will a symbolic link to the cross assembler and linker to these native assembler and linker solve the problem?
?
Thanks?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/4c6bf22d/attachment.html 

From douglasdocouto at gmail.com  Mon Jan 24 06:41:11 2011
From: douglasdocouto at gmail.com (Douglas do Couto Teixeira)
Date: Mon, 24 Jan 2011 10:41:11 -0200
Subject: [LLVMdev] How to change the type of an Instruction?
In-Reply-To: <AANLkTin1=uaisjUyBz2rTRxS4pWK3=Ek-ikyHYRC3oYw@mail.gmail.com>
References: <AANLkTinckvZACezY4AFENa4co+_jhS3cWc+37OUMZqwY@mail.gmail.com>
	<AANLkTin1=uaisjUyBz2rTRxS4pWK3=Ek-ikyHYRC3oYw@mail.gmail.com>
Message-ID: <AANLkTimhSrOBSm+iLQU=VAnAnr03S+CHdMBaip28a9z1@mail.gmail.com>

Hi,

Nick, thanks for the reply.
I still have a problem: I only need to "clone" an Instruction, changing its
type. That is, I would like to keep all characteristics of the old
Instruction and create a new one only with a different type. I am trying
create a new Instruction thus:

%3 = add nsw i32 %1, %2 ; <i16> [#uses=2]  //Old Instruction

Value* Op0 = I->getOperand(0);
Value* Op1 = I->getOperand(1);
Value* V0 = new Value(Type::getInt16Ty(Op0->getContext()),
Op0->getValueID());
Value* V1 = new Value(Type::getInt16Ty(Op1->getContext()),
Op1->getValueID());
Instruction* newInst = BinaryOperator::CreateNSWAdd(V0, V1, "test");
errs() << "NewInst:\n" << *newInst << "\n";


But I get something like this:

%test = add nsw i16 <badref>, <badref> ; <i16> [#uses=0]


What I am doing wrong?


Best,

Douglas

On Fri, Jan 21, 2011 at 8:25 PM, Nick Lewycky <nlewycky at google.com> wrote:

> On 21 January 2011 12:56, Douglas do Couto Teixeira <
> douglasdocouto at gmail.com> wrote:
>
>> Hello guys,
>>
>> I wonder how I can change the type of an integer variable. For instance,
>> given the instruction "%3 = add i32 %1, %2" I would like to alter the
>> instruction to "%3 = add i16 %1, %2". Is there any way to do this?
>>
>
> No. Instead you create a new Instruction, in this case with
> BinaryOperator::CreateAdd, then OldInst->replaceAllUsesWith(NewInst) to
> update all the users, then OldInst->eraseFromParent() since it's now dead
> code.
>
> Also, all values have types immutably assigned at creation, so you'll need
> to insert casts (trunc instructions in your case) to cast %1 and %2 from i32
> to i16 for the smaller add.
>
> Nick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/039591fc/attachment.html 

From undingen at gmail.com  Mon Jan 24 07:34:52 2011
From: undingen at gmail.com (Marius Wachtler)
Date: Mon, 24 Jan 2011 14:34:52 +0100
Subject: [LLVMdev] How to change the type of an Instruction?
In-Reply-To: <AANLkTimhSrOBSm+iLQU=VAnAnr03S+CHdMBaip28a9z1@mail.gmail.com>
References: <AANLkTinckvZACezY4AFENa4co+_jhS3cWc+37OUMZqwY@mail.gmail.com>
	<AANLkTin1=uaisjUyBz2rTRxS4pWK3=Ek-ikyHYRC3oYw@mail.gmail.com>
	<AANLkTimhSrOBSm+iLQU=VAnAnr03S+CHdMBaip28a9z1@mail.gmail.com>
Message-ID: <AANLkTikJK3YAH5nddwHKsfsLhU8qcSUA9mrvQ7UKAGHd@mail.gmail.com>

Hello

I think you will just have to insert a truncation instruction...

For example:

   CastInst* V0 = new TruncInst(Op0, Type::getInt16Ty(Op0->getContext()));
   CastInst* V1 = new TruncInst(Op1, Type::getInt16Ty(Op0->getContext()));
   BinaryOperator* newInst = BinaryOperator::CreateNSWAdd(V0, V1, "test");

I find the online demo on llvm.org helpful for this sort of questions
(Show LLVM C++ API code).

Hope this Helps

-- Marius Wachtler

From bijoy123_8 at yahoo.com  Mon Jan 24 08:04:55 2011
From: bijoy123_8 at yahoo.com (akramul azim)
Date: Mon, 24 Jan 2011 06:04:55 -0800 (PST)
Subject: [LLVMdev] Error in cross-compiling "Hello World"
Message-ID: <731361.19349.qm@web121702.mail.ne1.yahoo.com>











Hi,
???I use the crosstool build script to build a crosscompiler for ARM.?I get the following error when compilng "helloworld" program:
?
llvm-gcc hello.c -o hello
?
as: unrecognized option `-meabi=4' 
?
I?know that?the reason is not to get proper cross assembler. It tries to use the native assembler but I am unable to fix the problem. I use 
llvm-gcc -### hello.c -o hello and see the following going on:
?
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: /MinGW/llvm-project/src/llvm-gcc-4.2/configure --enable-languag
es=c --enable-bindings=none --disable-threads --enable-llvm=/usr/local/crosstool
/arm-none-linux-gnueabi/llvm --disable-gold --disable-multilib --prefix=/usr/loc
al/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2 --disable-shared --disable-libs
sp --program-prefix=llvm- --disable-bootstrap --disable-libmudflap --target=arm-
none-linux-gnueabi --disable-libstdcxx-pch --enable-optimized --with-as=/usr/loc
al/crosstool/codesourcery/arm-2010q1/bin/arm-none-linux-gnueabi-as --with-ld=/us
r/local/crosstool/codesourcery/arm-2010q1/bin/arm-none-linux-gnueabi-ld --with-s
ysroot=/usr/local/crosstool/codesourcery/arm-2010q1/arm-none-linux-gnueabi/libc
Thread model: single
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
?"c:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/bin/../l
ibexec/gcc/arm-none-linux-gnueabi/4.2.1/cc1.exe" "-quiet" "-iprefix" "c:\\mingw\
\msys\\1.0\\local\\crosstool\\arm-none-linux-gnueabi\\llvm-gcc-4.2\\bin\\../lib/
gcc/arm-none-linux-gnueabi/4.2.1/" "hello.c" "-quiet" "-dumpbase" "hello.c" "-au
xbase" "hello" "-o" "D:/DOCUME~2/AZIM/LOCALS~1/Temp/ccO28l0y.s"
?"as" "-meabi=4" "-o" "D:/DOCUME~2/AZIM/LOCALS~1/Temp/ccs3L4rX.o" "D:/DOCUME~2/A
ZIM/LOCALS~1/Temp/ccO28l0y.s"
?"c:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/bin/../l
ibexec/gcc/arm-none-linux-gnueabi/4.2.1/collect2.exe" "--sysroot=C:/MinGW/msys/1
.0/local/crosstool/codesourcery/arm-2010q1/arm-none-linux-gnueabi/libc" "--eh-fr
ame-hdr" "-dynamic-linker" "/lib/ld-linux.so.3" "-X" "-m" "armelf_linux_eabi" "-
o" "hello" "C:/MinGW/msys/1.0/local/crosstool/codesourcery/arm-2010q1/arm-none-l
inux-gnueabi/libc/usr/lib/crt1.o" "C:/MinGW/msys/1.0/local/crosstool/codesourcer
y/arm-2010q1/arm-none-linux-gnueabi/libc/usr/lib/crti.o" "c:/mingw/msys/1.0/loca
l/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/bin/../lib/gcc/arm-none-linux-gn
ueabi/4.2.1/crtbegin.o" "-Lc:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnue
abi/llvm-gcc-4.2/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1" "-Lc:/mingw/msys/1
.0/local/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/bin/../lib/gcc" "-LC:/Min
GW/msys/1.0/local/crosstool/arm-none-linux-gnueabi/llvm-gcc-4.2/lib/gcc/arm-none
-linux-gnueabi/4.2.1" "-Lc:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnueab
i/llvm-gcc-4.2/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-
linux-gnueabi/lib" "-LC:/MinGW/msys/1.0/local/crosstool/arm-none-linux-gnueabi/l
lvm-gcc-4.2/lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnue
abi/lib" "-LC:/MinGW/msys/1.0/local/crosstool/codesourcery/arm-2010q1/arm-none-l
inux-gnueabi/libc/lib" "-LC:/MinGW/msys/1.0/local/crosstool/codesourcery/arm-201
0q1/arm-none-linux-gnueabi/libc/usr/lib" "D:/DOCUME~2/AZIM/LOCALS~1/Temp/ccs3L4r
X.o" "-lgcc" "-lc" "-lgcc" "c:/mingw/msys/1.0/local/crosstool/arm-none-linux-gnu
eabi/llvm-gcc-4.2/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/crtend.o" "C:/MinG
W/msys/1.0/local/crosstool/codesourcery/arm-2010q1/arm-none-linux-gnueabi/libc/u
sr/lib/crtn.o"
?
I also use the following commands to see where is linker and assembler. 
?
$ which as
?
/mingw/bin/as.exe
?
$ which ld
?
/mingw/bin/ld.exe
?
It will be great if I get any suggestions or comments. Will a symbolic link to the cross assembler and linker to these native assembler and linker solve the problem?
?
Thanks?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/d5ba6b07/attachment.html 

From samuraileumas at yahoo.com  Mon Jan 24 10:22:25 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Mon, 24 Jan 2011 08:22:25 -0800 (PST)
Subject: [LLVMdev] LLVM grammar for ANTLR
In-Reply-To: <AANLkTikv=LQiXL3ZQHAdgQ68kVN_L0Q7PpibVKxeP4VU@mail.gmail.com>
References: <AANLkTikv=LQiXL3ZQHAdgQ68kVN_L0Q7PpibVKxeP4VU@mail.gmail.com>
Message-ID: <875786.55375.qm@web62005.mail.re1.yahoo.com>

Hello Surinder,

The existing hand-written parser is callable from almost anywhere so the only 
reason you'd need to have a parser for it would be to extend it.  Originally it 
was written using Flex and Bison but Chris Lattner rewrote it from scratch to 
catch more errors at the parsing stage.

The only feature I've found to be missing from the existing LLVM-AS utility was 
an include function with automatic unique detection.  This would allow the use 
of headers instead of having to manually copy and paste them into the source. 
 What were you planning on doing with your LLVM parser, if I may ask?

--Sam 


----- Original Message ----
> From: Surinder <surifilms at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Sun, January 23, 2011 10:35:38 PM
> Subject: [LLVMdev] LLVM grammar for ANTLR
> 
> Has anyone written a grammar for LLVM for ANTLR.  I mean an  ANTLR
> grammar that parses LLVM instructions.  Is an LLVM grammar  available
> for any other parsing  tool?
> 
> Surinder


      

From criswell at illinois.edu  Mon Jan 24 11:03:43 2011
From: criswell at illinois.edu (John Criswell)
Date: Mon, 24 Jan 2011 11:03:43 -0600
Subject: [LLVMdev] Pointers in Load and Store
In-Reply-To: <AANLkTimQxB8DcHg7RT0DWyNai_3obRTTCgvZgMOrXv3y@mail.gmail.com>
References: <AANLkTimM-c3qK7xJxg6K7tABjuyZd98A8YoqPa7ZRsL4@mail.gmail.com>	<4D3907A8.6080205@illinois.edu>	<AANLkTinQvssjgK4h9AYC+upgT4AMM9g_3u3evE63Vv+O@mail.gmail.com>	<4D3A6631.60601@illinois.edu>
	<AANLkTimQxB8DcHg7RT0DWyNai_3obRTTCgvZgMOrXv3y@mail.gmail.com>
Message-ID: <4D3DB0EF.1060904@illinois.edu>

On 1/22/11 7:19 PM, Surinder wrote:
> John,
>
> I have looked at the real code (instead of the obsolete one) and it
> appears to be easy to find if an operand is a getelementptr
> instruction.
>
>    if (ConstantExpr * CE = dyn_cast<ConstantExpr>(I.getOperand(0)))
>      { Out<<   "*** operand 0 is a constant Expr******";
>         if (CE->getOpcode() == Instruction::GetElementPtr)
>           { Out<<   "*** operand 0 is a gep instruction ********";
>             if (const ArrayType *ar =
> dyn_cast<ArrayType>(CE->getPointerOperandType()->getElementType()))
>                hi=ar->getNumElements();
>
> Thank you for that.

You're welcome.

> I would like to use safecode programs rather than write my own code.
> However, the website of safecode says that it works only with version
> 2.6 or 2.7 of llvm whereas I use version 2.8 of llvm.

SAFECode already does all the things you mention below.  Unless you have 
a pressing need to use LLVM 2.8, I recommend switching to LLVM 2.7 so 
that you can re-use the SAFECode passes unmodified.

If you must use LLVM 2.8 or mainline LLVM, then I have the following 
suggestions below:

> To get around the problem, I plan to do as follows :
>
> (1)  Do not install safecode with llvm 2.8 (as it may or may not work)
>
> (2)  Create a new pass named "unGep", "Breaks Constant GEPs"

The BreakConstantGEP pass is self-contained and should be trivial to 
update to work with LLVM 2.8.  There is no need for you to go through 
the effort to rewrite it.

> (3) The new pass derives from FunctionPass (because safecode does so,
> if I had to write it, ModulePass would have been good enough.)
>
> (4) The RunOnFunction method of the unGep pass invokes
> addPoolChecks(F) passing it the function F.  I will modify
> addGetElementPtrChecks so that it produces array bounds in the way I
> need. (I need a check that array bounds are being voilated for my
> reaserch to detect overflows.)

First, passes should do just one thing.  The BreakConstantGEP pass 
should convert ConstantExpr GEPs into GEP instructions and not do 
anything else.  A separate pass should insert bounds checks.  Calling 
addPoolChecks() from the BreakConstantGEP pass is a bad idea; it 
prevents the BreakConstantGEP pass from being reusable.

I'm currently in the process of making SAFECode follow this philosophy.  
For example, for LLVM 2.6, the InsertPoolChecks pass added load/store 
checks, array bounds checks, and indirect function call checks.  I've 
moved the code that inserts load/store checks into a separate pass in 
mainline SAFECode and intend to do the same for indirect function call 
checks.  We have also moved various array bounds check optimizations 
into separate passes.

Second, the code in InsertPoolChecks that inserts checks on GEP 
instructions is pretty straightforward.  If you take the mainline 
version and remove the call to isGEPSafe(), it should not have any other 
pass dependencies, and you should be able to easily update it to LLVM 2.8.

As for the implementation of the run-time check, the interface is pretty 
generic: it takes a pool handle, the source of the GEP, and the result 
of the GEP and does the run-time check.  The only extraneous parameter 
is the pool handle, and your run-time check can just ignore it if it 
doesn't need it.  You only need to specialize the code for your run-time 
array bounds check implementation if you require parameters other than 
these.


> I will then run opt as
>
> opt -load../unGep.so

Yes, this is how you could run the passes.  We built the SAFECode tool 
(sc) because SAFECode uses several different libraries; creating a 
separate tool was easier than trying to load all the libraries into opt.

-- John T.

> to produce llvm code without geps as operands.
>
> Please advise if this will work or if there is an easier way.
>
> Thanks.
>
> Surinder Kumar Jain
>
>
> On Sat, Jan 22, 2011 at 4:08 PM, John Criswell<criswell at illinois.edu>  wrote:
>> On 1/21/2011 10:46 PM, Surinder wrote:
>>> John,
>>>
>>> I have looked at the SAFECode and thought following sould work
>>>
>>>         if (isa<Constant>(I.getOperand(0)))
>>>         { Out<<    "*** operand 0 is a constant ******";
>>>           if (Instruction *operandI =
>>> dyn_cast<Instruction>(I.getOperand(0)))
>>>             { Out<<    "********operand is an instruction ****";
>>>               if (GetElementPtrInst *gepI =
>>> dyn_cast<GetElementPtrInst>(operandI))
>>>                 { Out<<    "*** operand is a gep instruction ********";
>>>                   if (const ArrayType *ar =
>>> dyn_cast<ArrayType>(gepI->getPointerOperandType()->getElementType()))
>>>                     hi=ar->getNumElements();
>>> But this does not recognize that operand(0) of instruction I is even
>>> an instruction, let alone a get element pointer instruction.  I have
>>> taken the code from line 632 and line 757 of
>>> safecode/lib/ArrayBoundsChecks/ArrayBoundCheck.cpp
>>>
>>> I must be doing something wrong, what is it?
>> The problem is simple: you're looking at the wrong source file.
>> :)
>>
>> More specifically, you're looking at the very antiquated static array bounds
>> checking pass (it hasn't compiled in several years now).  The file you want
>> to look at is in lib/InsertPoolChecks/insert.cpp.  This file contains the
>> InsertPoolChecks pass which, in mainline SAFECode, is responsible for
>> inserting array bounds checks and indirect function call checks.  In
>> particular, you want to look at the addGetElementPtrChecks() method.
>>
>> As for Constant Expression GEPs, you want to look at the BreakConstGEP pass,
>> located in lib/ArrayBoundsChecks/BreakConstantGEPs.cpp.
>>
>> The BreakConstantGEP pass is run first.  All it does is find instructions
>> that use constant expression GEPs and replaces the Constant Expression GEP
>> with a GEP instruction.  All of the other SAFECode passes that worry about
>> array bounds checks (i.e., the static array bounds checking passes in
>> lib/ArrayBoundsCheck and the run-time instrumentation pass in
>> lib/InsertPoolChecks/insert.cpp) only look for GEP instructions.
>>
>> -- John T.
>>
>>
>>> Surinder Kumar Jain
>>>
>>>
>>> PS: Yes, I will be using safecode but still I want to know why above
>>> code does not work.  I am posting a separate mail wioth the title "OPT
>>> optimizations"
>>
>>> On Fri, Jan 21, 2011 at 3:12 PM, John Criswell<criswell at illinois.edu>
>>>   wrote:
>>>> On 1/20/2011 10:02 PM, Surinder wrote:
>>>>> When I compile C programs into llvm, it produces load instructions in
>>>>> two different flavours.
>>>>>
>>>>> (1)    %8 = load i8** %bp, align 8
>>>>>
>>>>> (2)    %1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0,
>>>>> i64 0), align 1
>>>>>
>>>>> I know that %bp in first case and the entire "getelementptr inbounds
>>>>> ([4 x i8]* @.str, i64 0, i64 0)" in second case can be obtained by
>>>>> dump'ing I.getOperand(0)
>>>>>
>>>>> However, I want to find out which of the two forms of load have been
>>>>> produced because in the second case, I want to insert checks for array
>>>>> bounds.
>>>>>
>>>>> How can I find out when I am in Instruction object I and I.getOpcode()
>>>>> == 29 whether I am dealing with type (1) or type (2) above.
>>>> The second load instruction is not really a "special" load instruction.
>>>> Rather, its pointer argument is an LLVM constant expression (class
>>>> llvm::ConstExpr).  The Getelementptr (GEP), which would normally be a
>>>> GEP instruction, is instead a constant expression that will be converted
>>>> into a constant numeric value at code generation time.
>>>>
>>>> So, what you need to do is to examine the LoadInst's operand and see if
>>>> its a ConstExpr, and then see whether the ConstExpr's opcode is a GEP
>>>> opcode.
>>>>
>>>> However, there's an easier way to handle this.  SAFECode
>>>> (http://safecode.cs.illinois.edu) has an LLVM pass which converts
>>>> constant expression GEPs into GEP instructions.  If you run it on your
>>>> code first, you'll get the following instruction sequence:
>>>>
>>>> %tmp = getelementptr inbounds ([4 x i8]* @.str, i64 0,i64 0), align 1
>>>> %1 = load i8* %tmp
>>>>
>>>> You then merely search for GEP instructions and put run-time checks on
>>>> those (which you have to do anyway if you're adding array bounds
>>>> checking).  The only ConstantExpr GEPs that aren't converted, I think,
>>>> are those in global variable initializers.
>>>>
>>>> Now, regarding the insertion of array bounds checks, SAFECode does that,
>>>> too (it is a memory safety compiler for C code).  It also provides a
>>>> simple static array bounds checker and some array bounds check
>>>> optimization passes.
>>>>
>>>> I can direct you to the relevant portions of the source code if you're
>>>> interested.
>>>>
>>>> -- John T.
>>>>
>>>>> Thanks.
>>>>>
>>>>> Surinder Kumar Jain
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>


From nicholas at mxc.ca  Mon Jan 24 11:01:58 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 24 Jan 2011 09:01:58 -0800
Subject: [LLVMdev] How to change the type of an Instruction?
In-Reply-To: <AANLkTimhSrOBSm+iLQU=VAnAnr03S+CHdMBaip28a9z1@mail.gmail.com>
References: <AANLkTinckvZACezY4AFENa4co+_jhS3cWc+37OUMZqwY@mail.gmail.com>	<AANLkTin1=uaisjUyBz2rTRxS4pWK3=Ek-ikyHYRC3oYw@mail.gmail.com>
	<AANLkTimhSrOBSm+iLQU=VAnAnr03S+CHdMBaip28a9z1@mail.gmail.com>
Message-ID: <4D3DB086.6090409@mxc.ca>

On 01/24/2011 04:41 AM, Douglas do Couto Teixeira wrote:
> Hi,
>
> Nick, thanks for the reply.
> I still have a problem: I only need to "clone" an Instruction, changing
> its type. That is, I would like to keep all characteristics of the old
> Instruction and create a new one only with a different type.

Sure, but what about its operands? An "add" instruction must have the 
same type as its operands, what do you want to do with them? Suppose 
you're going from a 32-bit add to a 64-bit add, do the old operands get 
zero extended? Sign extended? You'll need to insert instructions for 
that (unless they're constants in which case you can use constant 
expressions). Similarly, what if the old type is a float and the new one 
is an int? float to signed int, float to unsigned int, or bitcast (only 
legal sometimes)?

  I am trying
> create a new Instruction thus:
>
> %3 = add nsw i32 %1, %2 ; <i16> [#uses=2]  //Old Instruction
>
> Value* Op0 = I->getOperand(0);
> Value* Op1 = I->getOperand(1);
> Value* V0 = new Value(Type::getInt16Ty(Op0->getContext()),
> Op0->getValueID());

Hunh, Value's constructor is protected.

In any event, Value is pure base. Constructing one this way will never 
get you what you want. If the ValueID indicates an Instruction, go 
through Instruction to create one.

> Value* V1 = new Value(Type::getInt16Ty(Op1->getContext()),
> Op1->getValueID());
> Instruction* newInst = BinaryOperator::CreateNSWAdd(V0, V1, "test");
> errs() << "NewInst:\n" << *newInst << "\n";
>
>
> But I get something like this:
>
> %test = add nsw i16 <badref>, <badref> ; <i16> [#uses=0]

The two instructions V0 and V1 you created were never inserted into the 
BasicBlock so they can't be numbered, and also they don't have names.

> What I am doing wrong?

Suppose that you're going from i32 to i16. Your only choice with that 
particular pair of types is a truncate. So:

   IRBuilder builder(OldInst);
   Value *V0 = builder.CreateTrunc(Op0, Type::getInt16Ty());
   Value *V1 = builder.CreateTrunc(Op1, Type::getInt16Ty());
   Value *Add = builder.CreateNSWAdd(V0, V1, "test");

The IRBuilder will take care of the distinction between instructions and 
constants for you. Note that I have not tested the above code, it may 
need some fixing before it compiles.

Nick

>
>
> Best,
>
> Douglas
>
> On Fri, Jan 21, 2011 at 8:25 PM, Nick Lewycky <nlewycky at google.com
> <mailto:nlewycky at google.com>> wrote:
>
>     On 21 January 2011 12:56, Douglas do Couto Teixeira
>     <douglasdocouto at gmail.com <mailto:douglasdocouto at gmail.com>> wrote:
>
>         Hello guys,
>
>         I wonder how I can change the type of an integer variable. For
>         instance, given the instruction "%3 = add i32 %1, %2" I would
>         like to alter the instruction to "%3 = add i16 %1, %2". Is there
>         any way to do this?
>
>
>     No. Instead you create a new Instruction, in this case with
>     BinaryOperator::CreateAdd, then OldInst->replaceAllUsesWith(NewInst)
>     to update all the users, then OldInst->eraseFromParent() since it's
>     now dead code.
>
>     Also, all values have types immutably assigned at creation, so
>     you'll need to insert casts (trunc instructions in your case) to
>     cast %1 and %2 from i32 to i16 for the smaller add.
>
>     Nick
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From douglasdocouto at gmail.com  Mon Jan 24 12:05:16 2011
From: douglasdocouto at gmail.com (Douglas do Couto Teixeira)
Date: Mon, 24 Jan 2011 16:05:16 -0200
Subject: [LLVMdev] How to change the type of an Instruction?
In-Reply-To: <4D3DB086.6090409@mxc.ca>
References: <AANLkTinckvZACezY4AFENa4co+_jhS3cWc+37OUMZqwY@mail.gmail.com>
	<AANLkTin1=uaisjUyBz2rTRxS4pWK3=Ek-ikyHYRC3oYw@mail.gmail.com>
	<AANLkTimhSrOBSm+iLQU=VAnAnr03S+CHdMBaip28a9z1@mail.gmail.com>
	<4D3DB086.6090409@mxc.ca>
Message-ID: <AANLkTikzDF2iJe4PqORmJ21JBxNfgWEzLEHfVfCYjGTD@mail.gmail.com>

On Mon, Jan 24, 2011 at 3:01 PM, Nick Lewycky <nicholas at mxc.ca> wrote:

> On 01/24/2011 04:41 AM, Douglas do Couto Teixeira wrote:
>
>> Hi,
>>
>> Nick, thanks for the reply.
>> I still have a problem: I only need to "clone" an Instruction, changing
>> its type. That is, I would like to keep all characteristics of the old
>> Instruction and create a new one only with a different type.
>>
>
> Sure, but what about its operands? An "add" instruction must have the same
> type as its operands, what do you want to do with them?


I also need to convert the type of the operands. But I want to do this when
they are created instead of inserting "trunc" instructions before performing
an operation. But it seems hard to me.


> Suppose you're going from a 32-bit add to a 64-bit add, do the old operands
> get zero extended? Sign extended? You'll need to insert instructions for
> that (unless they're constants in which case you can use constant
> expressions). Similarly, what if the old type is a float and the new one is
> an int? float to signed int, float to unsigned int, or bitcast (only legal
> sometimes)?


I believe I don't need worry about it because I only create smaller
instructions. So I never convert a 32-bit instruction in a 64-bit
instruction.


>
>
>  I am trying
>
>> create a new Instruction thus:
>>
>> %3 = add nsw i32 %1, %2 ; <i16> [#uses=2]  //Old Instruction
>>
>> Value* Op0 = I->getOperand(0);
>> Value* Op1 = I->getOperand(1);
>> Value* V0 = new Value(Type::getInt16Ty(Op0->getContext()),
>> Op0->getValueID());
>>
>
> Hunh, Value's constructor is protected.
>
> In any event, Value is pure base. Constructing one this way will never get
> you what you want. If the ValueID indicates an Instruction, go through
> Instruction to create one.
>
>
>  Value* V1 = new Value(Type::getInt16Ty(Op1->getContext()),
>> Op1->getValueID());
>> Instruction* newInst = BinaryOperator::CreateNSWAdd(V0, V1, "test");
>> errs() << "NewInst:\n" << *newInst << "\n";
>>
>>
>> But I get something like this:
>>
>> %test = add nsw i16 <badref>, <badref> ; <i16> [#uses=0]
>>
>
> The two instructions V0 and V1 you created were never inserted into the
> BasicBlock so they can't be numbered, and also they don't have names.
>
>
>  What I am doing wrong?
>>
>
> Suppose that you're going from i32 to i16. Your only choice with that
> particular pair of types is a truncate. So:
>
>  IRBuilder builder(OldInst);
>  Value *V0 = builder.CreateTrunc(Op0, Type::getInt16Ty());
>  Value *V1 = builder.CreateTrunc(Op1, Type::getInt16Ty());
>  Value *Add = builder.CreateNSWAdd(V0, V1, "test");
>
> The IRBuilder will take care of the distinction between instructions and
> constants for you. Note that I have not tested the above code, it may need
> some fixing before it compiles.
>
> Nick
>
>
>>
>> Best,
>>
>> Douglas
>>
>> On Fri, Jan 21, 2011 at 8:25 PM, Nick Lewycky <nlewycky at google.com
>> <mailto:nlewycky at google.com>> wrote:
>>
>>    On 21 January 2011 12:56, Douglas do Couto Teixeira
>>    <douglasdocouto at gmail.com <mailto:douglasdocouto at gmail.com>> wrote:
>>
>>        Hello guys,
>>
>>        I wonder how I can change the type of an integer variable. For
>>        instance, given the instruction "%3 = add i32 %1, %2" I would
>>        like to alter the instruction to "%3 = add i16 %1, %2". Is there
>>        any way to do this?
>>
>>
>>    No. Instead you create a new Instruction, in this case with
>>    BinaryOperator::CreateAdd, then OldInst->replaceAllUsesWith(NewInst)
>>    to update all the users, then OldInst->eraseFromParent() since it's
>>    now dead code.
>>
>>    Also, all values have types immutably assigned at creation, so
>>    you'll need to insert casts (trunc instructions in your case) to
>>    cast %1 and %2 from i32 to i16 for the smaller add.
>>
>>    Nick
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/be5f9cd8/attachment.html 

From nlewycky at google.com  Mon Jan 24 12:21:13 2011
From: nlewycky at google.com (Nick Lewycky)
Date: Mon, 24 Jan 2011 10:21:13 -0800
Subject: [LLVMdev] How to change the type of an Instruction?
In-Reply-To: <AANLkTikzDF2iJe4PqORmJ21JBxNfgWEzLEHfVfCYjGTD@mail.gmail.com>
References: <AANLkTinckvZACezY4AFENa4co+_jhS3cWc+37OUMZqwY@mail.gmail.com>
	<AANLkTin1=uaisjUyBz2rTRxS4pWK3=Ek-ikyHYRC3oYw@mail.gmail.com>
	<AANLkTimhSrOBSm+iLQU=VAnAnr03S+CHdMBaip28a9z1@mail.gmail.com>
	<4D3DB086.6090409@mxc.ca>
	<AANLkTikzDF2iJe4PqORmJ21JBxNfgWEzLEHfVfCYjGTD@mail.gmail.com>
Message-ID: <AANLkTimOS89CV5nYYbA+JyhyNeWSnJtiiEaiWB2chO8L@mail.gmail.com>

On 24 January 2011 10:05, Douglas do Couto Teixeira <
douglasdocouto at gmail.com> wrote:

>
>
> On Mon, Jan 24, 2011 at 3:01 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
>
>> On 01/24/2011 04:41 AM, Douglas do Couto Teixeira wrote:
>>
>>> Hi,
>>>
>>> Nick, thanks for the reply.
>>> I still have a problem: I only need to "clone" an Instruction, changing
>>> its type. That is, I would like to keep all characteristics of the old
>>> Instruction and create a new one only with a different type.
>>>
>>
>> Sure, but what about its operands? An "add" instruction must have the same
>> type as its operands, what do you want to do with them?
>
>
> I also need to convert the type of the operands. But I want to do this when
> they are created instead of inserting "trunc" instructions before performing
> an operation. But it seems hard to me.
>

It is. You can walk upwards in a chain:
 a) if it's a constant, use ConstantExpr::getTrunc which will return another
constant.
 b) if it's a memory load you can try to replace the pointer type too and
recurse on that. But then what do you do if it's a load of a global
variable?
 c) what if it's the type returned by a function call? Do you have a
different function you can call instead? Are you going to recursively
transform that function too?
 d) what if it's an Argument? You'll have to change the function's type
which means creating a new function and splicing all the basic blocks from
the old one into a new one -- then updating every call site.
And don't forget that for each instruction you touch, you need to update all
of their users too.

Nick

Suppose you're going from a 32-bit add to a 64-bit add, do the old operands
>> get zero extended? Sign extended? You'll need to insert instructions for
>> that (unless they're constants in which case you can use constant
>> expressions). Similarly, what if the old type is a float and the new one is
>> an int? float to signed int, float to unsigned int, or bitcast (only legal
>> sometimes)?
>
>
> I believe I don't need worry about it because I only create smaller
> instructions. So I never convert a 32-bit instruction in a 64-bit
> instruction.
>
>
>>
>>
>>  I am trying
>>
>>> create a new Instruction thus:
>>>
>>> %3 = add nsw i32 %1, %2 ; <i16> [#uses=2]  //Old Instruction
>>>
>>> Value* Op0 = I->getOperand(0);
>>> Value* Op1 = I->getOperand(1);
>>> Value* V0 = new Value(Type::getInt16Ty(Op0->getContext()),
>>> Op0->getValueID());
>>>
>>
>> Hunh, Value's constructor is protected.
>>
>> In any event, Value is pure base. Constructing one this way will never get
>> you what you want. If the ValueID indicates an Instruction, go through
>> Instruction to create one.
>>
>>
>>  Value* V1 = new Value(Type::getInt16Ty(Op1->getContext()),
>>> Op1->getValueID());
>>> Instruction* newInst = BinaryOperator::CreateNSWAdd(V0, V1, "test");
>>> errs() << "NewInst:\n" << *newInst << "\n";
>>>
>>>
>>> But I get something like this:
>>>
>>> %test = add nsw i16 <badref>, <badref> ; <i16> [#uses=0]
>>>
>>
>> The two instructions V0 and V1 you created were never inserted into the
>> BasicBlock so they can't be numbered, and also they don't have names.
>>
>>
>>  What I am doing wrong?
>>>
>>
>> Suppose that you're going from i32 to i16. Your only choice with that
>> particular pair of types is a truncate. So:
>>
>>  IRBuilder builder(OldInst);
>>  Value *V0 = builder.CreateTrunc(Op0, Type::getInt16Ty());
>>  Value *V1 = builder.CreateTrunc(Op1, Type::getInt16Ty());
>>  Value *Add = builder.CreateNSWAdd(V0, V1, "test");
>>
>> The IRBuilder will take care of the distinction between instructions and
>> constants for you. Note that I have not tested the above code, it may need
>> some fixing before it compiles.
>>
>> Nick
>>
>>
>>>
>>> Best,
>>>
>>> Douglas
>>>
>>> On Fri, Jan 21, 2011 at 8:25 PM, Nick Lewycky <nlewycky at google.com
>>> <mailto:nlewycky at google.com>> wrote:
>>>
>>>    On 21 January 2011 12:56, Douglas do Couto Teixeira
>>>    <douglasdocouto at gmail.com <mailto:douglasdocouto at gmail.com>> wrote:
>>>
>>>        Hello guys,
>>>
>>>        I wonder how I can change the type of an integer variable. For
>>>        instance, given the instruction "%3 = add i32 %1, %2" I would
>>>        like to alter the instruction to "%3 = add i16 %1, %2". Is there
>>>        any way to do this?
>>>
>>>
>>>    No. Instead you create a new Instruction, in this case with
>>>    BinaryOperator::CreateAdd, then OldInst->replaceAllUsesWith(NewInst)
>>>    to update all the users, then OldInst->eraseFromParent() since it's
>>>    now dead code.
>>>
>>>    Also, all values have types immutably assigned at creation, so
>>>    you'll need to insert casts (trunc instructions in your case) to
>>>    cast %1 and %2 from i32 to i16 for the smaller add.
>>>
>>>    Nick
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/d1b072c4/attachment.html 

From criswell at illinois.edu  Mon Jan 24 12:24:16 2011
From: criswell at illinois.edu (John Criswell)
Date: Mon, 24 Jan 2011 12:24:16 -0600
Subject: [LLVMdev] How to change the type of an Instruction?
In-Reply-To: <AANLkTikzDF2iJe4PqORmJ21JBxNfgWEzLEHfVfCYjGTD@mail.gmail.com>
References: <AANLkTinckvZACezY4AFENa4co+_jhS3cWc+37OUMZqwY@mail.gmail.com>	<AANLkTin1=uaisjUyBz2rTRxS4pWK3=Ek-ikyHYRC3oYw@mail.gmail.com>	<AANLkTimhSrOBSm+iLQU=VAnAnr03S+CHdMBaip28a9z1@mail.gmail.com>	<4D3DB086.6090409@mxc.ca>
	<AANLkTikzDF2iJe4PqORmJ21JBxNfgWEzLEHfVfCYjGTD@mail.gmail.com>
Message-ID: <4D3DC3D0.4030005@illinois.edu>

On 1/24/11 12:05 PM, Douglas do Couto Teixeira wrote:
>
>
> On Mon, Jan 24, 2011 at 3:01 PM, Nick Lewycky <nicholas at mxc.ca 
> <mailto:nicholas at mxc.ca>> wrote:
>
>     On 01/24/2011 04:41 AM, Douglas do Couto Teixeira wrote:
>
>         Hi,
>
>         Nick, thanks for the reply.
>         I still have a problem: I only need to "clone" an Instruction,
>         changing
>         its type. That is, I would like to keep all characteristics of
>         the old
>         Instruction and create a new one only with a different type.
>
>
>     Sure, but what about its operands? An "add" instruction must have
>     the same type as its operands, what do you want to do with them? 
>
>
> I also need to convert the type of the operands. But I want to do this 
> when they are created instead of inserting "trunc" instructions before 
> performing an operation. But it seems hard to me.

Actually, I don't think it will be that difficult.  You basically need 
to do the following:

1) Take the backwards, intra-procedural slice of the instruction (i.e., 
find the instructions, operands, the operands' operands, the operands' 
operands' operands, etc.).

2) Visit all of the instructions in the slice and convert them.  You 
want to visit definitions before uses.  To do that,
      a) Make new phi instructions for all phis in the slice.  The 
operands of the phis should be the Undef value.
     b) Use the dominator tree analysis and traverse basic blocks in 
dominator tree order (i.e., start at the top of the dominator tree and 
process each node breadth first).  Convert all of the instructions in 
each basic block (except phis).
     c) Revisit all the phis and plug in their new operands.

3) Delete all the old instructions.

This is a variation of the SSA construction algorithm in Zadeck et. 
al.'s paper (Effeciently Computing Single Static Assignment Form and the 
Control Dependence Graph).

The only tricky part is handling non-instruction operands (e.g., 
function arguments, global variables, etc.).  Some might be trivial to 
convert.  Others may be difficult.  You should look over all the classes 
derived from llvm::Value and decide how difficult it would be to convert 
them.

-- John T.


>     Suppose you're going from a 32-bit add to a 64-bit add, do the old
>     operands get zero extended? Sign extended? You'll need to insert
>     instructions for that (unless they're constants in which case you
>     can use constant expressions). Similarly, what if the old type is
>     a float and the new one is an int? float to signed int, float to
>     unsigned int, or bitcast (only legal sometimes)?
>
>
> I believe I don't need worry about it because I only create smaller 
> instructions. So I never convert a 32-bit instruction in a 64-bit 
> instruction.
>
>
>
>      I am trying
>
>         create a new Instruction thus:
>
>         %3 = add nsw i32 %1, %2 ; <i16> [#uses=2]  //Old Instruction
>
>         Value* Op0 = I->getOperand(0);
>         Value* Op1 = I->getOperand(1);
>         Value* V0 = new Value(Type::getInt16Ty(Op0->getContext()),
>         Op0->getValueID());
>
>
>     Hunh, Value's constructor is protected.
>
>     In any event, Value is pure base. Constructing one this way will
>     never get you what you want. If the ValueID indicates an
>     Instruction, go through Instruction to create one.
>
>
>         Value* V1 = new Value(Type::getInt16Ty(Op1->getContext()),
>         Op1->getValueID());
>         Instruction* newInst = BinaryOperator::CreateNSWAdd(V0, V1,
>         "test");
>         errs() << "NewInst:\n" << *newInst << "\n";
>
>
>         But I get something like this:
>
>         %test = add nsw i16 <badref>, <badref> ; <i16> [#uses=0]
>
>
>     The two instructions V0 and V1 you created were never inserted
>     into the BasicBlock so they can't be numbered, and also they don't
>     have names.
>
>
>         What I am doing wrong?
>
>
>     Suppose that you're going from i32 to i16. Your only choice with
>     that particular pair of types is a truncate. So:
>
>      IRBuilder builder(OldInst);
>      Value *V0 = builder.CreateTrunc(Op0, Type::getInt16Ty());
>      Value *V1 = builder.CreateTrunc(Op1, Type::getInt16Ty());
>      Value *Add = builder.CreateNSWAdd(V0, V1, "test");
>
>     The IRBuilder will take care of the distinction between
>     instructions and constants for you. Note that I have not tested
>     the above code, it may need some fixing before it compiles.
>
>     Nick
>
>
>
>         Best,
>
>         Douglas
>
>         On Fri, Jan 21, 2011 at 8:25 PM, Nick Lewycky
>         <nlewycky at google.com <mailto:nlewycky at google.com>
>         <mailto:nlewycky at google.com <mailto:nlewycky at google.com>>> wrote:
>
>            On 21 January 2011 12:56, Douglas do Couto Teixeira
>         <douglasdocouto at gmail.com <mailto:douglasdocouto at gmail.com>
>         <mailto:douglasdocouto at gmail.com
>         <mailto:douglasdocouto at gmail.com>>> wrote:
>
>                Hello guys,
>
>                I wonder how I can change the type of an integer
>         variable. For
>                instance, given the instruction "%3 = add i32 %1, %2" I
>         would
>                like to alter the instruction to "%3 = add i16 %1, %2".
>         Is there
>                any way to do this?
>
>
>            No. Instead you create a new Instruction, in this case with
>            BinaryOperator::CreateAdd, then
>         OldInst->replaceAllUsesWith(NewInst)
>            to update all the users, then OldInst->eraseFromParent()
>         since it's
>            now dead code.
>
>            Also, all values have types immutably assigned at creation, so
>            you'll need to insert casts (trunc instructions in your
>         case) to
>            cast %1 and %2 from i32 to i16 for the smaller add.
>
>            Nick
>
>
>
>
>         _______________________________________________
>         LLVM Developers mailing list
>         LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>         http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/acf9bc56/attachment.html 

From Hendrix_ at gmx.net  Mon Jan 24 12:36:42 2011
From: Hendrix_ at gmx.net (Hendrix_ at gmx.net)
Date: Mon, 24 Jan 2011 19:36:42 +0100
Subject: [LLVMdev] recreate optimized clang output
Message-ID: <F8064757-F4DB-44D8-A042-0C834DF7365E@gmx.net>

Hi,

I was using "clang  -O3 -S -emit-llvm" got some very optimized output.

Then I did "clang -S -emit-llvm" (without optimization) and wanted to optimized the code in a
separate pass. The llvm program "opt" did not do anything.

How can I invoke the optimizer on some un-optimized program, possibly showing the output of each optimizer stage?
I would like to get a deeper understanding of the optimization pass.

Best,
Patrick

From andrewl at lenharth.org  Mon Jan 24 12:45:51 2011
From: andrewl at lenharth.org (Andrew Lenharth)
Date: Mon, 24 Jan 2011 12:45:51 -0600
Subject: [LLVMdev] Undoing SSA and Phi instructions
In-Reply-To: <4D3BCE78.6010301@mxc.ca>
References: <AANLkTimZWe3BqnRSp-bn_UGkr84_k9kxFH_nr-4ja7UK@mail.gmail.com>
	<4D3BCE78.6010301@mxc.ca>
Message-ID: <AANLkTinUWc0yNgd6ZypTnFMMY1+RZWFfxvX3T6yZPC1i@mail.gmail.com>

On Sun, Jan 23, 2011 at 12:45 AM, Nick Lewycky <nicholas at mxc.ca> wrote:
> On 01/22/2011 10:30 PM, Surinder wrote:
>> Hi,
>>
>> I am emitting llvm bit code using
>>
>> llvm-gcc -c -emit-llvm -O0 -o test.bc test.c
>>
>> and then optimizing it with
>>
>> opt -O3 -print-module test.bc
>>
>> in order to obtain a dump of generated IR.
>>
>>
>> The resulting code has Phi nodes and is perhaps in SSA form. ?I want
>> to undo the SSA form while retaining all the other optimizations. ?Is
>> mem2reg the right optimization to be added after -O3, i.e.,
>>
>> opt -O3 -mem2reg -print-module test.bc
>>
>> will print the llvm in non-SSA form with no Phi nodes.
>
> I think you're looking for "opt -O3 -reg2mem -S test.bc" though I don't
> think it *guarantees* that it will remove all phi nodes. I don't think
> we have anything besides codegen that does.

reg2mem inserts allocas to store values going into phis.  It doesn't
exactly undo SSA, but it should remove all phis.

Andrew


From samuraileumas at yahoo.com  Mon Jan 24 12:55:55 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Mon, 24 Jan 2011 10:55:55 -0800 (PST)
Subject: [LLVMdev] recreate optimized clang output
In-Reply-To: <F8064757-F4DB-44D8-A042-0C834DF7365E@gmx.net>
References: <F8064757-F4DB-44D8-A042-0C834DF7365E@gmx.net>
Message-ID: <669171.42615.qm@web62006.mail.re1.yahoo.com>

Hi Patrick,

You have to tell opt which optimizations you want it to do.  The 
-std-compile-opts option for opt may be what you're looking for.

--Sam


----- Original Message ----
> From: "Hendrix_ at gmx.net" <Hendrix_ at gmx.net>
> To: llvmdev at cs.uiuc.edu
> Sent: Mon, January 24, 2011 12:36:42 PM
> Subject: [LLVMdev] recreate optimized clang output
> 
> Hi,
> 
> I was using "clang  -O3 -S -emit-llvm" got some very optimized  output.
> 
> Then I did "clang -S -emit-llvm" (without optimization) and  wanted to 
>optimized the code in a
> separate pass. The llvm program "opt" did  not do anything.
> 
> How can I invoke the optimizer on some un-optimized  program, possibly showing 
>the output of each optimizer stage?
> I would like to  get a deeper understanding of the optimization  pass.
> 
> Best,
> Patrick
> _______________________________________________
> LLVM  Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


      

From vmle at ucdavis.edu  Mon Jan 24 13:05:05 2011
From: vmle at ucdavis.edu (Vu Le)
Date: Mon, 24 Jan 2011 11:05:05 -0800
Subject: [LLVMdev] CodeExtractor.cpp potential bug?
In-Reply-To: <AANLkTikeZ_8d_utTEozg+=UtQ-u4SchPLXZZvmVN9nCQ@mail.gmail.com>
References: <AANLkTimr4kspHOmzAhO=tHyxAZbmDyEmfBa3Um7kupJ-@mail.gmail.com>
	<194BC6F9-70CA-4120-8DA8-5041C302BFE9@apple.com>
	<AANLkTikeZ_8d_utTEozg+=UtQ-u4SchPLXZZvmVN9nCQ@mail.gmail.com>
Message-ID: <AANLkTi=CrYf_sjq5GLxx9CFJ3BYoU5F3jULBOJhHA-J-@mail.gmail.com>

I forgot to cc llvmdev.
Here is my original message.

I'm a bit confused on DominatorTreeBase::Split() (
http://llvm.org/docs/doxygen/html/Dominators_8h_source.html#l00229)
If a basic block A splits into A->B, when I call Split(), which is NewBB? A
or B?

The semantics shows that NewBB is the newly split basic block B.
But the assertion at line 229 doesn't seem right.

00229     assert(std::distance(GraphT::child_begin(NewBB),
00230                          GraphT::child_end(NewBB)) == 1 &&
00231            "NewBB should have a single successor!");

If A has 2 successors C, D, after it split to A->NewBB, NewBB should have 2
successors.
Hope anyone could explain this to me.
Thanks,
Vu

On Sat, Jan 22, 2011 at 10:28 PM, Vu Le <vmle at ucdavis.edu> wrote:

> Hi Cameron,
> I'm a bit confused on DominatorTreeBase::Split() (
> http://llvm.org/docs/doxygen/html/Dominators_8h_source.html#l00229)
> If a basic block A splits into A->B, when I call Split(), which is NewBB?
> A or B.
> Thanks,
> Vu
>
>
> On Mon, Jan 3, 2011 at 1:25 PM, Cameron Zwarich <zwarich at apple.com> wrote:
>
>> On Dec 31, 2010, at 11:20 AM, Vu Le wrote:
>>
>> > There might be a misuse of DominatorTree::splitBasicBlock in
>> CodeExtractor.cpp, line 145.
>> > Header is splited into two (OldPred->NewBB).
>> >
>> > Line 145 updates the dominator tree by calling
>> DT->splitBasicBlock(NewBB).
>> > I think it should be DT->splitBasicBlock(OldPred).
>> >
>> > When I tried to extract a code region whose header has 2 successors, my
>> pass crashed.
>> > It was because header (or OldPred) is the block that was splited, not
>> NewBB.
>> > DominatorTree::splitBasicBlock(BB) requires BB to have one successor.
>>
>>
>> The code in Dominator::splitBasicBlock() looks correct, but I think the
>> comment and assert may not be. I was writing a patch where I hit the same
>> issue.
>>
>> Cameron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/6266c0ec/attachment.html 

From greened at obbligato.org  Mon Jan 24 13:21:38 2011
From: greened at obbligato.org (David A. Greene)
Date: Mon, 24 Jan 2011 13:21:38 -0600
Subject: [LLVMdev] Question about porting LLVM - code selection without
	assembler feature
In-Reply-To: <AANLkTikzW3GpL5a8h59Pr7eMcK897NSR60Krw6M8o-2R@mail.gmail.com>
	(Lu Mitnick's message of "Sat, 22 Jan 2011 15:09:54 +0800")
References: <AANLkTikzW3GpL5a8h59Pr7eMcK897NSR60Krw6M8o-2R@mail.gmail.com>
Message-ID: <nng4o8ykszh.fsf@royale.us.cray.com>

Lu Mitnick <king19880326 at gmail.com> writes:

> Hello all,
>
> I am adding a new target into LLVM. However there is a assembler for
> that target and I just want LLVM to generate assembly. I read the
> document "Writing an LLVM Backend". I am wondering to know whether I
> can ignore the Inst field in the following example:

I'm not an expert here so I'll defer to others.

> Second, I have read the documentation of "TableGen Fundamentals" and
> "The LLVM Target Independent Code Generator". But I don't know how to
> fill the dag filed of instruction. like?[(store IntRegs:$src,
> ADDRrr:$addr)] of the following example:
>
> def STrr  : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
>
>                "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]>;
>
> Would anyone mind to tell me where to find the documentation of the
> dag in Independent Code Generator??

Think of the DAG pattern as a LISP expression.  Each level of parens is
a subtree in the DAG, so

             +
            / \
           /   \
          a     *
               / \
              b   c

Becomes:

[(add REGCLASS:$a, (mul REGCLASS:&b, REGCLASS:$c))]

That's the pattern your codegen will match and turn into the asm string
you provide (The "st $src, [$addr]" in your example).

Does that help?

                               -Dave


From wendling at apple.com  Mon Jan 24 13:34:47 2011
From: wendling at apple.com (Bill Wendling)
Date: Mon, 24 Jan 2011 11:34:47 -0800
Subject: [LLVMdev] Question about porting LLVM - code selection without
	assembler feature
In-Reply-To: <AANLkTikzW3GpL5a8h59Pr7eMcK897NSR60Krw6M8o-2R@mail.gmail.com>
References: <AANLkTikzW3GpL5a8h59Pr7eMcK897NSR60Krw6M8o-2R@mail.gmail.com>
Message-ID: <E2416420-429F-4B43-9F84-3C3F0360EB27@apple.com>

On Jan 21, 2011, at 11:09 PM, Lu Mitnick wrote:

> I am adding a new target into LLVM. However there is a assembler for that target and I just want LLVM to generate assembly. I read the document "Writing an LLVM Backend". I am wondering to know whether I can ignore the Inst field in the following example:
> 
> class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction {
>   field bits<32> Inst;
>   let Namespace = "SP";
>   bits<2> op;
>   let Inst{31-30} = op;       
>   dag OutOperandList = outs;
>   dag InOperandList = ins;
>   let AsmString   = asmstr;
>   let Pattern = pattern;
> }
> And define the instruction class of ported target as:
> class Instxxx<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction {
>   let Namespace = "xxx";      
>   dag OutOperandList = outs;
>   dag InOperandList = ins;
>   let AsmString   = asmstr;
>   let Pattern = pattern;
> }
Hi Yi-Hong,

Yes, you may go ahead and omit the Inst field. That's used to represent the instruction encoding.

-bw

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/c8d8967b/attachment.html 

From housel at acm.org  Mon Jan 24 14:25:09 2011
From: housel at acm.org (Peter Housel)
Date: Mon, 24 Jan 2011 12:25:09 -0800
Subject: [LLVMdev] LLVM grammar for ANTLR
In-Reply-To: <AANLkTikv=LQiXL3ZQHAdgQ68kVN_L0Q7PpibVKxeP4VU@mail.gmail.com>
References: <AANLkTikv=LQiXL3ZQHAdgQ68kVN_L0Q7PpibVKxeP4VU@mail.gmail.com>
Message-ID: <1295900709.6978.14.camel@eng-phousel-ubuntu>

On Mon, 2011-01-24 at 15:35 +1100, Surinder wrote:
> Has anyone written a grammar for LLVM for ANTLR.  I mean an ANTLR
> grammar that parses LLVM instructions.  Is an LLVM grammar available
> for any other parsing tool?

http://www.opendylan.org/cgi-bin/viewvc.cgi/trunk/fundev/sources/lib/llvm/llvm-asm-parser.dylgram

is a grammar for LLVM assembly language written for a YACC-like LALR(1)
parser generator. (The actual grammar rules start at the "define parser
llvm-parser" line and continue to the end of the file.) This was
constructed by starting from the original YACC-based parser for llvm-as
(using a script that extracted raw grammar rules from the output of
bison -v), and then augmenting it to disambiguate several shift/reduce
conflicts and to handle changes to LLVM assembly language after the
lib/AsmParser parser was re-implemented as a recursive-descent parser.

Note that as usual with LR grammars, it contains a fair amount of
left-recursion and would not be directly suitable for ANTLR, which
implements LL(k).

-Peter-



From king19880326 at gmail.com  Mon Jan 24 14:44:12 2011
From: king19880326 at gmail.com (Lu Mitnick)
Date: Tue, 25 Jan 2011 04:44:12 +0800
Subject: [LLVMdev] Question about porting LLVM - code selection without
 assembler feature
In-Reply-To: <nng4o8ykszh.fsf@royale.us.cray.com>
References: <AANLkTikzW3GpL5a8h59Pr7eMcK897NSR60Krw6M8o-2R@mail.gmail.com>
	<nng4o8ykszh.fsf@royale.us.cray.com>
Message-ID: <AANLkTimph-7r0jVdvfufjdQvQL5dsS3ZX+yU4z8cf_9Q@mail.gmail.com>

Hello David,

Thanks for your example. Is that means that DAG pattern is consist of LLVM
IR instruction?? I met an example  [(set CPURegs:$dst, (OpNode CPURegs:$b,
CPURegs:$c))] of MipsInstrInfo.td, but I can't find correspond LLVM IR
instruction of "set" in "LLVM Language Reference Manual". Is that correspond
to $dst = op $b, $c?? Would you mind to tell me whether there is a reference
of all possible element of DAG??

thanks a lot

yi-hong

2011/1/25 David A. Greene <greened at obbligato.org>

> Lu Mitnick <king19880326 at gmail.com> writes:
>
> > Hello all,
> >
> > I am adding a new target into LLVM. However there is a assembler for
> > that target and I just want LLVM to generate assembly. I read the
> > document "Writing an LLVM Backend". I am wondering to know whether I
> > can ignore the Inst field in the following example:
>
> I'm not an expert here so I'll defer to others.
>
> > Second, I have read the documentation of "TableGen Fundamentals" and
> > "The LLVM Target Independent Code Generator". But I don't know how to
> > fill the dag filed of instruction. like [(store IntRegs:$src,
> > ADDRrr:$addr)] of the following example:
> >
> > def STrr  : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
> >
> >                "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]>;
> >
> > Would anyone mind to tell me where to find the documentation of the
> > dag in Independent Code Generator??
>
> Think of the DAG pattern as a LISP expression.  Each level of parens is
> a subtree in the DAG, so
>
>             +
>            / \
>           /   \
>          a     *
>               / \
>              b   c
>
> Becomes:
>
> [(add REGCLASS:$a, (mul REGCLASS:&b, REGCLASS:$c))]
>
> That's the pattern your codegen will match and turn into the asm string
> you provide (The "st $src, [$addr]" in your example).
>
> Does that help?
>
>                               -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110125/15578469/attachment.html 

From viridia at gmail.com  Mon Jan 24 15:23:11 2011
From: viridia at gmail.com (Talin)
Date: Mon, 24 Jan 2011 13:23:11 -0800
Subject: [LLVMdev] Rolling my own appending linkage
Message-ID: <AANLkTikK9Fzu3W2d4KHqDkgq-7arN357Kx53AutR9dBq@mail.gmail.com>

Hey all, it's been a while since I have posted on llvm-dev, but that's
mainly because I have been making good progress with my LLVM project. :)

In any case, I'd like some advice on implementing my own version of
appending linkage as a linker plugin. As I have pointed out on this list
before, the existing appending linkage type isn't useful for me for two
reasons:

1) There's no way for the compiled code to determine the length of the
combined array. Appending linkage concatenates all of the array fragments
with the same name together, but there's no simple way to get a count of the
number of elements, or even to insert a sentinel value at the end of the
list (Some have suggested solutions involving mucking about with linker
sections, but that's too complicated and fragile IMHO).

2) If your appended array contains pointer references to globals that would
otherwise be dead and stripped from the code, having them in the array will
keep them alive. In other words, what I need for my use case is to eliminate
dead globals, and then only afterward take the live globals remaining and
put them into the array.

To give an example of my use case, suppose I want to create an array of
static roots for the garbage collector - that is, I want an array of
pointers to all statically-allocated data structures which themselves
contains object references. Ideally, the way this would work is as follows:
Each time the compiler outputs a static data structure, it would check the
type information to see if that structure contains any object references
that need to be traced. If so, it would "mark" that structure somehow (how,
I am not certain). Then at link time, after dead global elimination, it
would collect all of the marked structures and create an array of pointers
to those structures, with a NULL pointer at the end of the list. The address
of this array would then be passed into the garbage collector when it is
first initialized.

Really, all I need to make this work is some way to 'mark' a global so that
my custom pass can query for all marked globals. Any ideas on this?

-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/d860fd02/attachment.html 

From dg at cowlark.com  Mon Jan 24 16:01:15 2011
From: dg at cowlark.com (David Given)
Date: Mon, 24 Jan 2011 22:01:15 +0000
Subject: [LLVMdev] LLVM targeting HLLs
Message-ID: <4D3DF6AB.9020103@cowlark.com>

I am interested in using LLVM to translate C and C++ into high-level
language code. (As an update to an earlier project of mine, Clue, which
used the Sparse compiler library to do this: it targets Lua, Javascript,
Perl 5, C, Java and Common Lisp, with a disturbing amount of success.
See http://cluecc.sourceforge.net for details.)

The obvious place to start on this is the C backend, except in these 2.8
days the C backend is so hedged about with caveats I'm rather wary of
basing anything on it. I also recall seeing comments here that it's due
for a rewrite from scratch, and that various people were looking into
it. Can anyone go into more detail as to what exactly is wrong with the
C backend, and whether this rewrite is happening?

The other thing I could do is to use the LLVMTargetMachine and treat my
HLL as a low-level machine; this gets me a certain amount of good stuff
like register allocation and more optimisations, but the documentation
is still pretty basic (e.g.
http://wiki.llvm.org/Absolute_Minimum_Backend is three short paragraphs)
and I'm not certain as to whether LLVMTargetMachine is suitable. For
example: my HLL can largely be treated as a register machine with an
arbitrary number of registers. Can LLVMTargetMachine handle this?

-- 
???? ?????????????? ????? http://www.cowlark.com ?????
?
? "I have a mind like a steel trap. It's rusty and full of dead mice."
? --- Anonymous, on rasfc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/81d3dfc5/attachment.bin 

From echristo at apple.com  Mon Jan 24 16:04:13 2011
From: echristo at apple.com (Eric Christopher)
Date: Mon, 24 Jan 2011 14:04:13 -0800
Subject: [LLVMdev] LLVM targeting HLLs
In-Reply-To: <4D3DF6AB.9020103@cowlark.com>
References: <4D3DF6AB.9020103@cowlark.com>
Message-ID: <BCFACC5B-DEAE-4D7F-B4B2-4CB974F18805@apple.com>


On Jan 24, 2011, at 2:01 PM, David Given wrote:

> I am interested in using LLVM to translate C and C++ into high-level
> language code. (As an update to an earlier project of mine, Clue, which
> used the Sparse compiler library to do this: it targets Lua, Javascript,
> Perl 5, C, Java and Common Lisp, with a disturbing amount of success.
> See http://cluecc.sourceforge.net for details.)
> 
> The obvious place to start on this is the C backend, except in these 2.8
> days the C backend is so hedged about with caveats I'm rather wary of
> basing anything on it. I also recall seeing comments here that it's due
> for a rewrite from scratch, and that various people were looking into
> it. Can anyone go into more detail as to what exactly is wrong with the
> C backend, and whether this rewrite is happening?
> 
> The other thing I could do is to use the LLVMTargetMachine and treat my
> HLL as a low-level machine; this gets me a certain amount of good stuff
> like register allocation and more optimisations, but the documentation
> is still pretty basic (e.g.
> http://wiki.llvm.org/Absolute_Minimum_Backend is three short paragraphs)
> and I'm not certain as to whether LLVMTargetMachine is suitable. For
> example: my HLL can largely be treated as a register machine with an
> arbitrary number of registers. Can LLVMTargetMachine handle this?

You could create a different code generator from clang or use the rewriting
machinery?

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/247da82c/attachment-0001.html 

From clattner at apple.com  Mon Jan 24 16:11:20 2011
From: clattner at apple.com (Chris Lattner)
Date: Mon, 24 Jan 2011 14:11:20 -0800
Subject: [LLVMdev] LLVM targeting HLLs
In-Reply-To: <4D3DF6AB.9020103@cowlark.com>
References: <4D3DF6AB.9020103@cowlark.com>
Message-ID: <75DD5DCB-BC76-4B6C-AEFB-C7D0415A2E3C@apple.com>


On Jan 24, 2011, at 2:01 PM, David Given wrote:

> I am interested in using LLVM to translate C and C++ into high-level
> language code. (As an update to an earlier project of mine, Clue, which
> used the Sparse compiler library to do this: it targets Lua, Javascript,
> Perl 5, C, Java and Common Lisp, with a disturbing amount of success.
> See http://cluecc.sourceforge.net for details.)

If you're familiar with Sparse, then I strongly recommend basing this project on Clang ASTs, not basing it on LLVM IR.

-Chris

From csdavec at swan.ac.uk  Mon Jan 24 16:35:29 2011
From: csdavec at swan.ac.uk (David Chisnall)
Date: Mon, 24 Jan 2011 22:35:29 +0000
Subject: [LLVMdev] [cfe-dev]  LLVM targeting HLLs
In-Reply-To: <BCFACC5B-DEAE-4D7F-B4B2-4CB974F18805@apple.com>
References: <4D3DF6AB.9020103@cowlark.com>
	<BCFACC5B-DEAE-4D7F-B4B2-4CB974F18805@apple.com>
Message-ID: <ACC3D6F5-18B2-4769-856B-070E8F5BABCB@swan.ac.uk>

On 24 Jan 2011, at 22:04, Eric Christopher wrote:

> On Jan 24, 2011, at 2:01 PM, David Given wrote:
> 
>> I am interested in using LLVM to translate C and C++ into high-level
>> language code. (As an update to an earlier project of mine, Clue, which
>> used the Sparse compiler library to do this: it targets Lua, Javascript,
>> Perl 5, C, Java and Common Lisp, with a disturbing amount of success.
>> See http://cluecc.sourceforge.net for details.)
>> 
>> The obvious place to start on this is the C backend, except in these 2.8
>> days the C backend is so hedged about with caveats I'm rather wary of
>> basing anything on it. I also recall seeing comments here that it's due
>> for a rewrite from scratch, and that various people were looking into
>> it. Can anyone go into more detail as to what exactly is wrong with the
>> C backend, and whether this rewrite is happening?
>> 
>> The other thing I could do is to use the LLVMTargetMachine and treat my
>> HLL as a low-level machine; this gets me a certain amount of good stuff
>> like register allocation and more optimisations, but the documentation
>> is still pretty basic (e.g.
>> http://wiki.llvm.org/Absolute_Minimum_Backend is three short paragraphs)
>> and I'm not certain as to whether LLVMTargetMachine is suitable. For
>> example: my HLL can largely be treated as a register machine with an
>> arbitrary number of registers. Can LLVMTargetMachine handle this?
> 
> You could create a different code generator from clang or use the rewriting
> machinery?

-- Send from my Jacquard Loom

A better approach would probably be to use Clang's CodeGen lib as inspiration, and write an equivalent that emitted your high-level language code instead of LLVM IR.  For example, consider C++ classes:

When you convert these to LLVM IR, you lose all of the information about them other than their structure, and the vtable is explicitly created for the target ABI.  Mapping them to something like JavaScript, you'd actually want to create a new prototype object for each class, with one slot for each field and another slot for each method (and some extra mixin-style stuff if you wanted to support multiple inheritance).  

The same is true even for pure C structures - you'd want to represent these as objects with named fields.  This information is in the Clang AST, but it's lost by the time you get to LLVM IR.  Taking an example from Apple's Foundation framework, you have two structures:

typedef
{
	CGFloat x, y;
} NSPoint;

typedef
{
	CGFloat width, height;
} NSSize;

In LLVM IR, these are both something like {double, double}.  In JavaScript, you'd probably want something like:

function NSPoint()
{
	this.x = 0;
	this.y = 0;
}
function NSSize()
{
	this.width = 0;
	this.width = 0;
}

This is pretty simple to generate from the Clang AST, but will be a huge amount of effort to generate from LLVM IR.

David

-- Sent from my PDP-11

From greened at obbligato.org  Mon Jan 24 18:14:39 2011
From: greened at obbligato.org (David A. Greene)
Date: Mon, 24 Jan 2011 18:14:39 -0600
Subject: [LLVMdev] Question about porting LLVM - code selection without
	assembler feature
In-Reply-To: <AANLkTimph-7r0jVdvfufjdQvQL5dsS3ZX+yU4z8cf_9Q@mail.gmail.com>
	(Lu Mitnick's message of "Tue, 25 Jan 2011 04:44:12 +0800")
References: <AANLkTikzW3GpL5a8h59Pr7eMcK897NSR60Krw6M8o-2R@mail.gmail.com>
	<nng4o8ykszh.fsf@royale.us.cray.com>
	<AANLkTimph-7r0jVdvfufjdQvQL5dsS3ZX+yU4z8cf_9Q@mail.gmail.com>
Message-ID: <nnghbcxj0uo.fsf@royale.us.cray.com>

Lu Mitnick <king19880326 at gmail.com> writes:

> Hello David,
>
> Thanks for your example.?Is that means that DAG pattern is consist of
> LLVM IR instruction?? I met an example ?[(set CPURegs:$dst, (OpNode
> CPURegs:$b, CPURegs:$c))] of?MipsInstrInfo.td, but I can't find
> correspond LLVM IR instruction of "set" in "LLVM Language Reference
> Manual". Is that correspond to $dst = op $b, $c?? Would you mind to
> tell me whether there is a reference of all possible element of DAG??

Ah.  No, it's not LLVM IR.  It's SelectionDAG IR.  The operations are
defined in include/llvm/CodeGen/ISDOpcodes.h.  Each target also has its
own set of operations.  For example, the x86 target has operators for
x86-ish things like odd shuffles and so forth.  Since you're writing
your own target, you may end up defining some.  If your target is simple
enough, you won't.

The actual nodes used in patterns are defined in
include/llvm/Target/TargetSelectionDAG.td.  You'll see an almost 1:1
correspondence between ISDOpcodes.h and TargetSelectionDAG.td.

In addition, there are some special operators that TableGen recognizes.
"set" is one of them.  It's pure syntactic sugar.  TableGen just throws
it away.  It's only there to make patterns look prettier.

To find these special operators, you can look in TargetSelectionDAG.td
for the stuff that doesn't have anything matching in ISDOpcodes.h.  To
know what they do, you have to read the TableGen source, currently.  :(

TableGen is confusing stuff, but really powerful once you grok it.

                      -Dave


From greened at obbligato.org  Mon Jan 24 18:17:04 2011
From: greened at obbligato.org (David A. Greene)
Date: Mon, 24 Jan 2011 18:17:04 -0600
Subject: [LLVMdev] LLVM targeting HLLs
In-Reply-To: <4D3DF6AB.9020103@cowlark.com> (David Given's message of "Mon, 24
	Jan 2011 22:01:15 +0000")
References: <4D3DF6AB.9020103@cowlark.com>
Message-ID: <nngd3nlj0qn.fsf@royale.us.cray.com>

David Given <dg at cowlark.com> writes:

> The obvious place to start on this is the C backend, except in these 2.8
> days the C backend is so hedged about with caveats I'm rather wary of
> basing anything on it. I also recall seeing comments here that it's due
> for a rewrite from scratch, and that various people were looking into
> it. Can anyone go into more detail as to what exactly is wrong with the
> C backend, and whether this rewrite is happening?

The rewrite is happening.  I've got the skeleton of the codegen done,
but I have to get it to build before I can check it in.  After that,
everyone can start adding patterns.

The main problem with the current C backend is that there is no legalize
phase.  So you end up seeing vector types and all sorts of non-C
nonsense.  It's just overall much cleaner to generate code using the
generic framework.

> The other thing I could do is to use the LLVMTargetMachine and treat my
> HLL as a low-level machine; this gets me a certain amount of good stuff
> like register allocation and more optimisations, but the documentation
> is still pretty basic (e.g.
> http://wiki.llvm.org/Absolute_Minimum_Backend is three short paragraphs)
> and I'm not certain as to whether LLVMTargetMachine is suitable. For
> example: my HLL can largely be treated as a register machine with an
> arbitrary number of registers. Can LLVMTargetMachine handle this?

Once I get the new C backend checked in (next week, hopefully), it may
be helpful as a guide.

                            -Dave

From greened at obbligato.org  Mon Jan 24 18:18:17 2011
From: greened at obbligato.org (David A. Greene)
Date: Mon, 24 Jan 2011 18:18:17 -0600
Subject: [LLVMdev] LLVM targeting HLLs
In-Reply-To: <75DD5DCB-BC76-4B6C-AEFB-C7D0415A2E3C@apple.com> (Chris Lattner's
	message of "Mon, 24 Jan 2011 14:11:20 -0800")
References: <4D3DF6AB.9020103@cowlark.com>
	<75DD5DCB-BC76-4B6C-AEFB-C7D0415A2E3C@apple.com>
Message-ID: <nng8vy9j0om.fsf@royale.us.cray.com>

Chris Lattner <clattner at apple.com> writes:

> On Jan 24, 2011, at 2:01 PM, David Given wrote:
>
>> I am interested in using LLVM to translate C and C++ into high-level
>> language code. (As an update to an earlier project of mine, Clue, which
>> used the Sparse compiler library to do this: it targets Lua, Javascript,
>> Perl 5, C, Java and Common Lisp, with a disturbing amount of success.
>> See http://cluecc.sourceforge.net for details.)
>
> If you're familiar with Sparse, then I strongly recommend basing this
> project on Clang ASTs, not basing it on LLVM IR.

I completely agree.  I forgot to add this to the end of my previous
response.  :) LLVM IR throws too much information away to target a HLL
effectively.

                            -Dave

From tek_phy at yahoo.com  Mon Jan 24 20:13:37 2011
From: tek_phy at yahoo.com (Teklu kebede)
Date: Mon, 24 Jan 2011 18:13:37 -0800 (PST)
Subject: [LLVMdev] install and add backend to llvm.
Message-ID: <989513.22420.qm@web59509.mail.ac4.yahoo.com>

Hi I am new to llvm and Linux (I am using ubuntu 10)

My aim is to add backend to llvm. 

I install llvm using 

$ sudo apt-get install llvm

and I am able to understand what I read about Writing an LLVM Compiler Backend.

I have seen the assembly codes of the targets on llvm using llc. What I need now is to change some of the TableGen files of one of the target like SparcInstrInfo.td.? So I uninstall llvm and I try to build it manually as specified in Getting Started with the LLVM System. http://llvm.org/releases/2.7/docs/GettingStarted.html. 

The building finish with out error (I didn\t include LLVM Test Suite).
I use default for all of the options!! 

But when I use all of tools? for example 
$ lli hello.bc

I get

The program 'lli' is currently not installed.? You can install it by typing:
sudo apt-get install llvm-2.7-runtime

Any help please.

I just need to see the effect of a changes in TableGen files, when i print the assembly code.
like name of register, or name of Instruction. 

thanks





      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110124/b65330ff/attachment.html 

From raghu at cs.ucla.edu  Mon Jan 24 20:51:41 2011
From: raghu at cs.ucla.edu (Raghu Prabhakar)
Date: Mon, 24 Jan 2011 18:51:41 -0800 (PST)
Subject: [LLVMdev] install and add backend to llvm.
In-Reply-To: <989513.22420.qm@web59509.mail.ac4.yahoo.com>
Message-ID: <629020747.55505.1295923900960.JavaMail.root@mail.cs.ucla.edu>

Have you added the $LLVM_INSTALL_DIR/bin to your PATH environment variable?

Regarding changing a particular backend, check the documentation in 
http://llvm.org/docs/WritingAnLLVMBackend.html
http://llvm.org/docs/CodeGenerator.html

A few LLVMdev meetings have good talks to give you a good enough idea.
http://llvm.org/devmtg/

Cheers,
Raghu.

----- Original Message -----
From: "Teklu kebede" <tek_phy at yahoo.com>
To: llvmdev at cs.uiuc.edu
Sent: Monday, January 24, 2011 6:13:37 PM
Subject: [LLVMdev] install and add backend to llvm.


Hi I am new to llvm and Linux (I am using ubuntu 10) 

My aim is to add backend to llvm. 

I install llvm using 

$ sudo apt-get install llvm 

and I am able to understand what I read about Writing an LLVM Compiler Backend. 

I have seen the assembly codes of the targets on llvm using llc. What I need now is to change some of the TableGen files of one of the target like SparcInstrInfo.td. So I uninstall llvm and I try to build it manually as specified in Getting Started with the LLVM System. http://llvm.org/releases/2.7/docs/GettingStarted.html. 

The building finish with out error (I didn\t include LLVM Test Suite ). 
I use default for all of the options!! 

But when I use all of tools for example 
$ lli hello.bc 

I get 

The program 'lli' is currently not installed. You can install it by typing: 
sudo apt-get install llvm-2.7-runtime 

Any help please. 

I just need to see the effect of a changes in TableGen files, when i print the assembly code. 
like name of register, or name of Instruction. 

thanks 




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

From surifilms at gmail.com  Tue Jan 25 00:00:42 2011
From: surifilms at gmail.com (Surinder)
Date: Tue, 25 Jan 2011 17:00:42 +1100
Subject: [LLVMdev] LLVM grammar for ANTLR
In-Reply-To: <875786.55375.qm@web62005.mail.re1.yahoo.com>
References: <AANLkTikv=LQiXL3ZQHAdgQ68kVN_L0Q7PpibVKxeP4VU@mail.gmail.com>
	<875786.55375.qm@web62005.mail.re1.yahoo.com>
Message-ID: <AANLkTi=ZEP0Ni+PcWzqQf-t0R6wr9B7uprOyvKhRSAAm@mail.gmail.com>

Hi Sam,

Thanks for your reply.

I am implementing my research
(http://www.it.usyd.edu.au/~suri/Detecting%20Buffer%20Over.pdf), a
translation of LLVM to a simple non-deterministic language to detect
buffer overflows.  It involves

(1) printing a control flow graph of basic blocks of a function (easily done)
(2) translating each llvm statement to a corresponding data flow
language (needs ASTs to traverse)
(3) translating control flow graph to a regular expression
(4) translating data flow language statements to non-deterministic language
(5) translating non-deterministic language to CLP (Prolog like solver)
(6) finding a Prolog solution as proof of or absence of buffer overflows

I have implemented Step (1) & (2) above by writing a transform pass.
Remaining steps (3) to (6) have been written in Haskell.  Step (2),
translation from llvm to dfl language has been done by implementing an
AnnotationWriter and it emits dfl format of each llvm statement.  This
is rather crude and causes crashes between llvm/haskell interface.  I
am considering to dump llvm as it is into Haskell program and then use
a parser tool to do llvm statement translation to dfl.  The
translation is a set of simple rewrite tools.

You can get further details from my website
http://it.usyd.edu.au/~suri or you can ask me.

Thank you for your interest.

Surinder

On Tue, Jan 25, 2011 at 3:22 AM, Samuel Crow <samuraileumas at yahoo.com> wrote:
> Hello Surinder,
>
> The existing hand-written parser is callable from almost anywhere so the only
> reason you'd need to have a parser for it would be to extend it. ?Originally it
> was written using Flex and Bison but Chris Lattner rewrote it from scratch to
> catch more errors at the parsing stage.
>
> The only feature I've found to be missing from the existing LLVM-AS utility was
> an include function with automatic unique detection. ?This would allow the use
> of headers instead of having to manually copy and paste them into the source.
> ?What were you planning on doing with your LLVM parser, if I may ask?
>
> --Sam
>
>
> ----- Original Message ----
>> From: Surinder <surifilms at gmail.com>
>> To: llvmdev at cs.uiuc.edu
>> Sent: Sun, January 23, 2011 10:35:38 PM
>> Subject: [LLVMdev] LLVM grammar for ANTLR
>>
>> Has anyone written a grammar for LLVM for ANTLR. ?I mean an ?ANTLR
>> grammar that parses LLVM instructions. ?Is an LLVM grammar ?available
>> for any other parsing ?tool?
>>
>> Surinder
>
>
>
>


From heming at cs.columbia.edu  Tue Jan 25 01:10:09 2011
From: heming at cs.columbia.edu (Heming Cui)
Date: Tue, 25 Jan 2011 02:10:09 -0500
Subject: [LLVMdev] Can CallGraphSCCPass distinguish different function
	pointer types in CallGraphNode?
Message-ID: <AANLkTinJ-UYX-0iWXJZo25s_0g0N7NWe=0Lz_rLaSK8E@mail.gmail.com>

Dear folks,
    I am trying to handle function pointers at call graph, and I found that
the CallGraphSCCPass makes function pointers as external node, which is
actually an empty CallGraphNode (NULL pointer)?
    If I want to distinguish the function pointer types in the call graph
(and I also want the SCC order in CallGraphSCCPass), can I do that easily?
Or I have to inheritate the CallGraphSCCPass and handle function pointer
types in the call graph by myself?

   For example,

int aa(int i);

int main() {
int (*foo)(int);
foo = &aa;
foo(1);
}

     If I want to use the CallGraphSCCPass to get to know that the "foo"
pointer, which is an external node in the CallGraphSCCPass, actually has the
same function type the same as aa(int), how could I get this type
information from CallGraphSCCPass?

-- 
Regards,
Heming Cui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110125/128c2ae7/attachment.html 

From baldrick at free.fr  Tue Jan 25 01:57:09 2011
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 25 Jan 2011 08:57:09 +0100
Subject: [LLVMdev] Rolling my own appending linkage
In-Reply-To: <AANLkTikK9Fzu3W2d4KHqDkgq-7arN357Kx53AutR9dBq@mail.gmail.com>
References: <AANLkTikK9Fzu3W2d4KHqDkgq-7arN357Kx53AutR9dBq@mail.gmail.com>
Message-ID: <4D3E8255.6000301@free.fr>

Hi Talin,

> Really, all I need to make this work is some way to 'mark' a global so that my
> custom pass can query for all marked globals. Any ideas on this?

metadata maybe?

Ciao, Duncan.

From vmle at ucdavis.edu  Tue Jan 25 02:33:28 2011
From: vmle at ucdavis.edu (Vu Le)
Date: Tue, 25 Jan 2011 00:33:28 -0800
Subject: [LLVMdev] Update PHINode after extracting code
Message-ID: <AANLkTinORMUXaPcECi+=756vkKAm2fzHeQC=Ssusg6k1@mail.gmail.com>

Hi all,
I have problem with ExtractCodeRegion (CodeExtractor.cpp).
My original program is as follows.
bb:
  ...
  %tmp.15 = load %struct.MYSQL_ROWS** %3, align 4
  ...
bb1:
  ...
  %tmp.1 = load %struct.MYSQL_ROWS** %6, align 4
  ...
bb4:                                              ; preds = %bb1, %bb,
%entry
  %tmp.0 = phi %struct.MYSQL_ROWS* [ null, %entry ], [ %tmp.15, %bb ], [
%tmp.1, %bb1 ]

%tmp.0 is the PHINode whose value is from entry, bb and bb1.
After extracting bb and bb1 into new function, the program becomes

codeRepl:                                         ; preds = %entry
  call void @mysql_data_seek_bb(%struct.MYSQL_DATA* %1, i64 %row,
%struct.MYSQL_ROWS** %tmp.15.loc, %struct.MYSQL_ROWS** %tmp.1.loc)
*  %tmp.15.reload = load %struct.MYSQL_ROWS** %tmp.15.loc
  %tmp.1.reload = load %struct.MYSQL_ROWS** %tmp.1.loc
*  br label %bb4

bb4:                                              ; preds = %codeRepl,
%entry
*  %tmp.0 = phi %struct.MYSQL_ROWS* [ null, %entry ], [ %tmp.15.reload,
%codeRepl ], [ %tmp.1.reload, %codeRepl ]

*bb4 now has only 2 predecessors since bb and bb1 are replaced by codeRepl.
The PHINode in bb4, on the other hand, still has 3 incoming values and that
make the assertion failed.
I do want to extract this code region into function. Does anyone have a
solution for this?
Thanks a lot.
Vu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110125/52155bdb/attachment.html 

From junk at giantblob.com  Tue Jan 25 03:04:08 2011
From: junk at giantblob.com (James Williams)
Date: Tue, 25 Jan 2011 09:04:08 +0000
Subject: [LLVMdev] Compile function with limited set of registers? Jump to
	another function?
Message-ID: <AANLkTim_iGYZjkqLemcoczor1L+E=iH3d8aJiFWEm6Qn@mail.gmail.com>

Hi,

Can anyone tell me, is it possible to express in LLVM IR:
  - that, for a specific function, register allocator can use only limited
set of registers? (specifically, cannot touch any registers that might
contain parameters)
  - that stack can't be touched? (or at least must balance on exit from
thunk)
  - jump, not call, to another function leaving any received parameters
unchanged in registers and on stack?

Thanks,
-- James Williams

Background:

I'm looking for some advice on implementing thunks required by my language's
interface call mechanism. This is a fairly conventional arrangement where
method selectors in interfaces are hashed to determine their index within a
vtable and hash collisions are disambiguated at runtime by a thunk, which
determines which method to call from a selector id passed as the first
method parameter.

I'm currently using a single thunk (written in assembly) for all collisions
that walks a table to determine what method to call. This works but it's
inefficient and requires the a hand written thunk for each supported target.

I'd like to instead generate IR for a specific thunk for each vtable
collisoin that does a binary search of possible selectors because this will
avoid some pointer dereferences and an additional indirect call.

The problem is that a thunk may need to decide between methods with
different signatures without disturbing parameters in registers and on the
stack and then jump to, rather than call, another function:

interface X:
  method A(a, b)

interface Y:
  method B(c, d, e)

class Z implements X, y:
  method A(a, b) ...
  method B(c, d, e) ...

X.A + Y.B happen to hash to same vtable index, say -3

This would require a thunk something like:

vtable[-3] =
  thunk_Z_AorB(selector_id, ...)
    // binary search for matching selector id:
    if selector_id <= selector_Z_A then
      Z.A(selector_id, ...)
    else
      Z.B(selector_id, ...)
    fi

which would ideally would compile on x64 to something like:

thunk_Z_AorB:
  cmp $selector_Z_A, %rdi
  jle Z.A
  jmp Z.B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110125/46ac62a3/attachment.html 

From per.fagrell at coresonic.com  Tue Jan 25 05:09:28 2011
From: per.fagrell at coresonic.com (Per Fagrell)
Date: Tue, 25 Jan 2011 12:09:28 +0100
Subject: [LLVMdev]  Trouble with virtual registers
Message-ID: <AANLkTim_OzeumWZOcKota1vzoC-yyQrA0yAveU-8MXy2@mail.gmail.com>

I'm having trouble with virtual registers/register allocation in my
back-end. Basically the FastRegAlloc pass is generating calls to
storeToStackSlot and loadFromStackSlot, in which we build new machine
instructions, which are then _not_ processed by the reg allocator. I
understand that BuildMI is changing the list of MachInst. that the allocator
is iterating over, but we need to have a new virtual register as part of the
stack store process since we don't have indirect adressing. Should we be
creating a physical register directly somehow, or can we perhaps signal to
the allocator that the basic block's contents are updated?

Below is our storeRegToStackSlot, the ADDri instruction is transformed into
a copy-add pair in eliminateFrameIndex.

void OurTargetInstrInfo::storeRegToStackSlot(MachineBasicBlock &MBB,
                                          MachineBasicBlock::iterator MI,
                                          unsigned SrcReg, bool isKill, int
FrameIdx,
                                          const TargetRegisterClass *RC,
                                          const llvm::TargetRegisterInfo*)
const {
  DebugLoc DL;
  if (MI != MBB.end()) DL = MI->getDebugLoc();
  MachineFunction &MF = *MBB.getParent();
  MachineFrameInfo &MFI = *MF.getFrameInfo();

  MachineMemOperand *MMO =
    MF.getMachineMemOperand(PseudoSourceValue::getFixedStack(FrameIdx),
                            MachineMemOperand::MOStore, 0,
                            MFI.getObjectSize(FrameIdx),
                            MFI.getObjectAlignment(FrameIdx));

  unsigned tmpVReg =
MF.getRegInfo().createVirtualRegister(OURTARGET::IntRegsRegisterClass);
  MachineInstr* mi = BuildMI(MBB, MI, DL, get(OURTARGET::ADDri),
tmpVReg).addFrameIndex(FrameIdx).addImm(0);
  BuildMI(MBB, MI, DL,
get(OURTARGET::STORE)).addReg(tmpVReg).addReg(SrcReg).addMemOperand(MMO);
}

Thanks a lot!
Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110125/72f21fed/attachment.html 

From dg at cowlark.com  Tue Jan 25 05:15:29 2011
From: dg at cowlark.com (David Given)
Date: Tue, 25 Jan 2011 11:15:29 +0000
Subject: [LLVMdev] LLVM targeting HLLs
In-Reply-To: <nngd3nlj0qn.fsf@royale.us.cray.com>
References: <4D3DF6AB.9020103@cowlark.com> <nngd3nlj0qn.fsf@royale.us.cray.com>
Message-ID: <4D3EB0D1.7000702@cowlark.com>

On 25/01/11 00:17, David A. Greene wrote:
[...]
> The rewrite is happening.  I've got the skeleton of the codegen done,
> but I have to get it to build before I can check it in.  After that,
> everyone can start adding patterns.

Is the new C backend 'register' based, that is, generating lots of
little statements operating on lots of variables, rather than producing
the huge mangled expressions that the old one does? If so, that would be
ideal for what I want.

[...]
> Once I get the new C backend checked in (next week, hopefully), it may
> be helpful as a guide.

Excellent --- I'll wait for that, then. Will it be announced here?

[...]
> LLVM IR throws too much information away to target a HLL
> effectively.

The thing is, I explicitly don't want to use the Clang AST --- I'm not
interested in producing an idiomatic translation, merely a
fast-performing one. Clue in its current lousy state has proven that
this is possible; without any optimisation I'm getting C-to-Java at 60%
of native, and C-to-Luajit at 10%. I now want to see what sort of
results I get when applying LLVM's optimisations and some more
intelligence to the code generation. (Plus, Sparse is buggy and really
awkward to work with.)

For giggles, here's some example Javascript produced by Clue.

function _dtime(fp, stack) {
var sp;
var H0;
var H1;
var H2;
var H3;
var H4;
var state = 0;
for (;;) {
switch (state) {
case 0:
sp = 2;
sp = fp + sp;
H1 = null;
H0 = 0;
H2 = fp;
H3 = _gettimeofday;
H4 = H3(sp, stack, H2, stack, H0, H1);
H0 = fp;
H1 = stack[H0 + 0];
H0 = fp;
H2 = stack[H0 + 1];
H0 = 1000000.000000;
H3 = H2 / H0;
H0 = H1 + H3;
return H0;
} } }


(PS. Can people please reply to the list instead of to me directly?)

-- 
???? ?????????????? ????? http://www.cowlark.com ?????
?
? life?{ ?1 ??.^3 4=+/,?1 0 1?.??1 0 1?.??? }
? --- Conway's Game Of Life, in one line of APL

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110125/7f73256c/attachment.bin 

From tek_phy at yahoo.com  Tue Jan 25 05:35:10 2011
From: tek_phy at yahoo.com (Teklu kebede)
Date: Tue, 25 Jan 2011 03:35:10 -0800 (PST)
Subject: [LLVMdev] install and add backend to llvm.
In-Reply-To: <629020747.55505.1295923900960.JavaMail.root@mail.cs.ucla.edu>
Message-ID: <370239.85219.qm@web59503.mail.ac4.yahoo.com>

Thanks Raghu

It is working fine now!!!!

I change the name of the instruction "add" to "newadd" in 
root/llvm/lib/Target/XCore/XCoreInstrInfo.td. Then I go to objllvm/lib/Target/XCore/

then I run

$ make
$ cd
$ cd objllvm
$ sudo make install

I can see the new name *newadd" in the assembly code now but Is this the shortest way?
I mean I change only one file :)

thanks again!!!!

--- On Tue, 1/25/11, Raghu Prabhakar <raghu at cs.ucla.edu> wrote:

From: Raghu Prabhakar <raghu at cs.ucla.edu>
Subject: Re: [LLVMdev] install and add backend to llvm.
To: "Teklu kebede" <tek_phy at yahoo.com>
Cc: llvmdev at cs.uiuc.edu
Date: Tuesday, January 25, 2011, 2:51 AM

Have you added the $LLVM_INSTALL_DIR/bin to your PATH environment variable?

Regarding changing a particular backend, check the documentation in 
http://llvm.org/docs/WritingAnLLVMBackend.html
http://llvm.org/docs/CodeGenerator.html

A few LLVMdev meetings have good talks to give you a good enough idea.
http://llvm.org/devmtg/

Cheers,
Raghu.

----- Original Message -----
From: "Teklu kebede" <tek_phy at yahoo.com>
To: llvmdev at cs.uiuc.edu
Sent: Monday, January 24, 2011 6:13:37 PM
Subject: [LLVMdev] install and add backend to llvm.


Hi I am new to llvm and Linux (I am using ubuntu 10) 

My aim is to add backend to llvm. 

I install llvm using 

$ sudo apt-get install llvm 

and I am able to understand what I read about Writing an LLVM Compiler Backend. 

I have seen the assembly codes of the targets on llvm using llc. What I need now is to change some of the TableGen files of one of the target like SparcInstrInfo.td. So I uninstall llvm and I try to build it manually as specified in Getting Started with the LLVM System. http://llvm.org/releases/2.7/docs/GettingStarted.html. 

The building finish with out error (I didn\t include LLVM Test Suite ). 
I use default for all of the options!! 

But when I use all of tools for example 
$ lli hello.bc 

I get 

The program 'lli' is currently not installed. You can install it by typing: 
sudo apt-get install llvm-2.7-runtime 

Any help please. 

I just need to see the effect of a changes in TableGen files, when i print the assembly code. 
like name of register, or name of Instruction. 

thanks 




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



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110125/278cb1c4/attachment.html 

From xiaolong.snake at gmail.com  Tue Jan 25 10:31:07 2011
From: xiaolong.snake at gmail.com (Xiaolong Tang)
Date: Tue, 25 Jan 2011 10:31:07 -0600
Subject: [LLVMdev] Does LLVM Makefile provide a "tags" target for LLVM?
Message-ID: <m0aaipaqt0.wl%xiaolong.snake@gmail.com>


Hi all, 

As described in LLVM Makefile guide, LLVM Makefile does have a "tags"
target. However, I failed to find such a target in LLVM Makefile (I am
using the revision 114955.) So, I am wondering if there is a provided
way to build tags for LLVM source code?

Best, 
Xiaolong

From dpatel at apple.com  Tue Jan 25 11:14:30 2011
From: dpatel at apple.com (Devang Patel)
Date: Tue, 25 Jan 2011 09:14:30 -0800
Subject: [LLVMdev] Rolling my own appending linkage
In-Reply-To: <4D3E8255.6000301@free.fr>
References: <AANLkTikK9Fzu3W2d4KHqDkgq-7arN357Kx53AutR9dBq@mail.gmail.com>
	<4D3E8255.6000301@free.fr>
Message-ID: <EDC76F7C-57F2-4AD4-A74D-D7EDC8AD605E@apple.com>


On Jan 24, 2011, at 11:57 PM, Duncan Sands wrote:

> Hi Talin,
> 
>> Really, all I need to make this work is some way to 'mark' a global so that my
>> custom pass can query for all marked globals. Any ideas on this?
> 
> metadata maybe?

A better approach would be to create an global array of strings to hold names of marked globals. You know the name of this special array and use it to query all marked globals. This is the trick llvm-gcc uses to support PCH.

-
Devang



From viridia at gmail.com  Tue Jan 25 11:50:33 2011
From: viridia at gmail.com (Talin)
Date: Tue, 25 Jan 2011 09:50:33 -0800
Subject: [LLVMdev] Rolling my own appending linkage
In-Reply-To: <EDC76F7C-57F2-4AD4-A74D-D7EDC8AD605E@apple.com>
References: <AANLkTikK9Fzu3W2d4KHqDkgq-7arN357Kx53AutR9dBq@mail.gmail.com>
	<4D3E8255.6000301@free.fr>
	<EDC76F7C-57F2-4AD4-A74D-D7EDC8AD605E@apple.com>
Message-ID: <AANLkTimLdhOj_iBV3Ww1569g2Pw6Bd=sg9rk-ZfekwpS@mail.gmail.com>

On Tue, Jan 25, 2011 at 9:14 AM, Devang Patel <dpatel at apple.com> wrote:

>
> On Jan 24, 2011, at 11:57 PM, Duncan Sands wrote:
>
> > Hi Talin,
> >
> >> Really, all I need to make this work is some way to 'mark' a global so
> that my
> >> custom pass can query for all marked globals. Any ideas on this?
> >
> > metadata maybe?
>
> A better approach would be to create an global array of strings to hold
> names of marked globals. You know the name of this special array and use it
> to query all marked globals. This is the trick llvm-gcc uses to support PCH.
>

OK thanks, I'll try that :)

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



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110125/bec3c3e5/attachment.html 

From samuraileumas at yahoo.com  Tue Jan 25 12:19:35 2011
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Tue, 25 Jan 2011 10:19:35 -0800 (PST)
Subject: [LLVMdev] LLVM grammar for ANTLR
In-Reply-To: <AANLkTi=ZEP0Ni+PcWzqQf-t0R6wr9B7uprOyvKhRSAAm@mail.gmail.com>
References: <AANLkTikv=LQiXL3ZQHAdgQ68kVN_L0Q7PpibVKxeP4VU@mail.gmail.com>
	<875786.55375.qm@web62005.mail.re1.yahoo.com>
	<AANLkTi=ZEP0Ni+PcWzqQf-t0R6wr9B7uprOyvKhRSAAm@mail.gmail.com>
Message-ID: <662632.48234.qm@web62005.mail.re1.yahoo.com>

Hello Surinder,

I understand now what you are trying to do.  Unfortunately what I was going to 
suggest takes things in exactly the opposite direction of what you need.

I have a parsing expression grammar-based parser generator that generates LLVM 
bitcode by using the LLVM assembly parser to generate all rules.  I was 
considering adding an LLVM assembly parser to it to simplify the parsing of 
actions.  This would be exactly the opposite of what you need since you 
essentially need an LLVM backend to generate code in your nondeterministic 
language.

Also, I'm unfamiliar with ANTLR since the unusual platforms I support oftentimes 
don't have a Java VM to run ANTLR on.  The PEG parser generator I use generates 
C rather than Haskell.  I'm not interested in making another parser generator to 
generate Haskell parsing code.  If you need a parser in C I might be able to get 
something set up for you using PEG.

I'm sorry I wasn't able to help you more,

--Sam


----- Original Message ----
> From: Surinder <surifilms at gmail.com>
> To: Samuel Crow <samuraileumas at yahoo.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Tue, January 25, 2011 12:00:42 AM
> Subject: Re: [LLVMdev] LLVM grammar for ANTLR
> 
> Hi Sam,
> 
> Thanks for your reply.
> 
> I am implementing my  research
> (http://www.it.usyd.edu.au/~suri/Detecting%20Buffer%20Over.pdf),  a
> translation of LLVM to a simple non-deterministic language to  detect
> buffer overflows.  It involves
> 
> (1) printing a control flow  graph of basic blocks of a function (easily done)
> (2) translating each llvm  statement to a corresponding data flow
> language (needs ASTs to  traverse)
> (3) translating control flow graph to a regular expression
> (4)  translating data flow language statements to non-deterministic language
> (5)  translating non-deterministic language to CLP (Prolog like solver)
> (6)  finding a Prolog solution as proof of or absence of buffer overflows
> 
> I  have implemented Step (1) & (2) above by writing a transform  pass.
> Remaining steps (3) to (6) have been written in Haskell.  Step  (2),
> translation from llvm to dfl language has been done by implementing  an
> AnnotationWriter and it emits dfl format of each llvm statement.   This
> is rather crude and causes crashes between llvm/haskell interface.   I
> am considering to dump llvm as it is into Haskell program and then use
> a  parser tool to do llvm statement translation to dfl.  The
> translation is  a set of simple rewrite tools.
> 
> You can get further details from my  website
> http://it.usyd.edu.au/~suri or you can ask me.
> 
> Thank you for  your interest.
> 
> Surinder
> 
> On Tue, Jan 25, 2011 at 3:22 AM, Samuel  Crow <samuraileumas at yahoo.com>  
wrote:
> > Hello Surinder,
> >
> > The existing hand-written parser  is callable from almost anywhere so the 
>only
> > reason you'd need to have a  parser for it would be to extend it.  Originally 
>it
> > was written using  Flex and Bison but Chris Lattner rewrote it from scratch 
>to
> > catch more  errors at the parsing stage.
> >
> > The only feature I've found to be  missing from the existing LLVM-AS utility 
>was
> > an include function with  automatic unique detection.  This would allow the 
>use
> > of headers instead  of having to manually copy and paste them into the 
>source.
> >  What were  you planning on doing with your LLVM parser, if I may ask?
> >
> >  --Sam
> >
> >
> > ----- Original Message ----
> >> From:  Surinder <surifilms at gmail.com>
> >> To: llvmdev at cs.uiuc.edu
> >> Sent: Sun,  January 23, 2011 10:35:38 PM
> >> Subject: [LLVMdev] LLVM grammar for  ANTLR
> >>
> >> Has anyone written a grammar for LLVM for ANTLR.   I mean an  ANTLR
> >> grammar that parses LLVM instructions.  Is an LLVM  grammar  available
> >> for any other parsing   tool?
> >>
> >> Surinder
> >
> >
> >
> >
> 


      

From greened at obbligato.org  Tue Jan 25 14:53:59 2011
From: greened at obbligato.org (David A. Greene)
Date: Tue, 25 Jan 2011 14:53:59 -0600
Subject: [LLVMdev] LLVM targeting HLLs
In-Reply-To: <4D3EB0D1.7000702@cowlark.com> (David Given's message of "Tue, 25
	Jan 2011 11:15:29 +0000")
References: <4D3DF6AB.9020103@cowlark.com>
	<nngd3nlj0qn.fsf@royale.us.cray.com> <4D3EB0D1.7000702@cowlark.com>
Message-ID: <nngpqrkg0wo.fsf@royale.us.cray.com>

David Given <dg at cowlark.com> writes:

> On 25/01/11 00:17, David A. Greene wrote:

> Is the new C backend 'register' based, that is, generating lots of
> little statements operating on lots of variables, rather than producing
> the huge mangled expressions that the old one does? If so, that would be
> ideal for what I want.

It will probably end up looking that way.  I've considered adding a pass
to expand expressions but it's only benefit would be aesthetic, so it's
not a high priority for me.

>> Once I get the new C backend checked in (next week, hopefully), it may
>> be helpful as a guide.
>
> Excellent --- I'll wait for that, then. Will it be announced here?

Absolutely.  I will send it for a pre-checking code review.

                        -Dave

From stoklund at 2pi.dk  Tue Jan 25 15:23:12 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Tue, 25 Jan 2011 13:23:12 -0800
Subject: [LLVMdev] Trouble with virtual registers
In-Reply-To: <AANLkTim_OzeumWZOcKota1vzoC-yyQrA0yAveU-8MXy2@mail.gmail.com>
References: <AANLkTim_OzeumWZOcKota1vzoC-yyQrA0yAveU-8MXy2@mail.gmail.com>
Message-ID: <441F8770-341B-47C0-90FA-C87C02998F59@2pi.dk>


On Jan 25, 2011, at 3:09 AM, Per Fagrell wrote:

> I'm having trouble with virtual registers/register allocation in my back-end. Basically the FastRegAlloc pass is generating calls to storeToStackSlot and loadFromStackSlot, in which we build new machine instructions, which are then _not_ processed by the reg allocator. I understand that BuildMI is changing the list of MachInst. that the allocator is iterating over, but we need to have a new virtual register as part of the stack store process since we don't have indirect adressing. Should we be creating a physical register directly somehow, or can we perhaps signal to the allocator that the basic block's contents are updated? 

The fast allocator could be spilling because it has run out of registers, so that is a really bad time to be creating new virtual registers.

You have two options:

1. Reserve a scratch register for use in spill code, or

2. Emit a pseudo-instruction for the spill, and get a register from the register scavenger during eliminateFrameIndex().

Look at the Blackfin and ARM targets for how to use the register scavenger.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110125/e5160336/attachment.html 

From gclayton at apple.com  Tue Jan 25 16:52:07 2011
From: gclayton at apple.com (Greg Clayton)
Date: Tue, 25 Jan 2011 14:52:07 -0800
Subject: [LLVMdev] LLDB Summer Internship at Apple
Message-ID: <910282B3-2A24-4962-B73B-88993791FAF2@apple.com>

We are currently looking for a great intern to define and implement a meaningful summer project in LLDB (we have lots of ideas too!). This is a paid internship and the internship will be at Apple in Cupertino, CA.

If anyone is currently a student and is interested in applying for an intership position, please send your resume to gclayton at apple.com.

I look forward to hearing from any interested students!

Greg Clayton
Senior LLDB Architect



From rjmccall at apple.com  Tue Jan 25 21:39:14 2011
From: rjmccall at apple.com (John McCall)
Date: Tue, 25 Jan 2011 19:39:14 -0800
Subject: [LLVMdev] recreate optimized clang output
In-Reply-To: <F8064757-F4DB-44D8-A042-0C834DF7365E@gmx.net>
References: <F8064757-F4DB-44D8-A042-0C834DF7365E@gmx.net>
Message-ID: <A69BCA25-B21E-4D73-90FA-BE6EBD2AE464@apple.com>

On Jan 24, 2011, at 10:36 AM, Hendrix_ at gmx.net wrote:
> I was using "clang  -O3 -S -emit-llvm" got some very optimized output.
> 
> Then I did "clang -S -emit-llvm" (without optimization) and wanted to optimized the code in a
> separate pass. The llvm program "opt" did not do anything.
> 
> How can I invoke the optimizer on some un-optimized program, possibly showing the output of each optimizer stage?
> I would like to get a deeper understanding of the optimization pass.

In addition to Sam's advice, I want to point out that clang's IR generator doesn't necessarily emit the same code when compiling for optimization and not.  Most obviously, we never emit available_externally function definitions at -O0 because we assume that would just waste compile time.

John.

From jdkunk3 at gmail.com  Wed Jan 26 11:41:44 2011
From: jdkunk3 at gmail.com (Jeff Kunkel)
Date: Wed, 26 Jan 2011 12:41:44 -0500
Subject: [LLVMdev] [LLVMDev] Where can I find the LLVM instruction to target
	instruction transformation
Message-ID: <AANLkTik0E-raLp7UPjGs_kFc7p0GWDZU7UPrFK=+tiYp@mail.gmail.com>

Where can I find the LLVM instruction to target instruction transformation.
I would like to see if this can be further optimized.

- Thanks
Jeff Kunkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110126/0e4d379b/attachment.html 

From asb at asbradbury.org  Wed Jan 26 12:00:58 2011
From: asb at asbradbury.org (Alex Bradbury)
Date: Wed, 26 Jan 2011 18:00:58 +0000
Subject: [LLVMdev] clang/LLVM cross testing environment
In-Reply-To: <4D341A34.3000109@pennware.com>
References: <4D341A34.3000109@pennware.com>
Message-ID: <AANLkTikbEObbnRsH4W50N4w8YcqfXXWcmCwwUWUJBxfx@mail.gmail.com>

On 17 January 2011 10:30, Richard Pennington <rich at pennware.com> wrote:
> * It is currently based on a fairly recent version of LLVM/clang: r122956.

This is great. I've noticed that you've made some fixes or additions
that haven't made it upstream yet, such as the Microblaze parameter
fix in rev 2337 (CCed Wesley Peck as he seems to have done a lot of
work on the MBlaze stack code recently) and va_arg support for
Microblaze in rev 2350. Do you intend to push such fixes upstream?

Regards,

Alex

From kirk.beitz at nokia.com  Wed Jan 26 13:42:49 2011
From: kirk.beitz at nokia.com (kirk.beitz at nokia.com)
Date: Wed, 26 Jan 2011 19:42:49 +0000
Subject: [LLVMdev] building llvm :: host_os==mingw
In-Reply-To: <0528FCC5-501C-4BD7-B759-60D8E2E0BBDD@apple.com>
References: <E9DF1AF9-D157-41C9-8B15-F561508F6446@nokia.com>
	<0528FCC5-501C-4BD7-B759-60D8E2E0BBDD@apple.com>
Message-ID: <4F1A9F8D-21DF-4F62-B0FA-BDA90C3C0154@nokia.com>

i am interested in getting lldb build using mingw (which i don't think has yet been done).

to do so requires first building llvm in order to get the depended-upon clang library, et al.

after installing mingw, i have performed the following steps, as these are what have been used to build lldb on linux (with the targets being my targets of interest):

svn co http://llvm.org/svn/llvm-project/llvm/trunk -r 123723 llvm
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/trunk -r 123723 clang
svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb
cd ..
./configure --enable-optimized --disable-assertions \
 --enable-targets=host,x86,x86_64,arm,cpp
make


upon invoking make, the following error was reported:


make[2]: Leaving directory `/x/lldb-win/tools/llvm-config'
llvm-config: unknown component name: bitreader
make[2]: Entering directory `/x/lldb-win/tools/opt'
/x/lldb-win/Makefile.rules:939: *** llvm-config --libs failed.  Stop.
make[2]: Leaving directory `/x/lldb-win/tools/opt'
make[1]: *** [opt/.makeall] Error 2
make[1]: Leaving directory `/x/lldb-win/tools'
make: *** [all] Error 1


being unfamiliar with llvm and thus where i might find a component 'bitreader', i browsed around in http://llvm.org/svn/llvm-project ; i don't see anything obvious.  i fgrep'ed for bitreader through what i did get co from svn, and i see some stuff under "bindings", and various dependencies in some of the clang Makefiles , but the source of these dependencies is not clear to me in attempting to follow the makefile tree.

i browsed the last 6 months of archives for the list, and the only messages with subject lines containing mingw seemed to involve making certain perl is part of the msys distribution.  'which perl' tells me '/bin/perl' and 'perl --version' tells me 'This is perl, v5.6.1 built for msys', so i assume i have the right thing there.

is there something else i have to check out to get the bitreader module (et al ? presuming that bitreader might not be the only unknown component, just the first encountered in the attempt to make in lldb-win/tools )?

any information or help in regard to this topic would be greatly appreciated.

++ kirk



++ kirk beitz : nokia : austin + san diego : kirk.beitz at nokia.com<mailto:kirk.beitz at nokia.com> ++



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110126/ceaf31e3/attachment.html 

From songlh at cs.wisc.edu  Wed Jan 26 14:07:54 2011
From: songlh at cs.wisc.edu (songlh at cs.wisc.edu)
Date: Wed, 26 Jan 2011 14:07:54 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this situation?
Message-ID: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>

Hi:

  My llvm code is:

  for( BasicBlock::iterator i = b->begin() , ie = b->end();
       b != be ; b ++ ){
       if( CallInst * pCall = dyn_cast<CallInst>(i)){

          pCall->dump(); //
          Function * pFunction = pCall->getCalledFunction();
          if( !pFunction ){

          }
          std::string fname = pFunction->getName();
       }
  }

  The dump result of the function call I want to find is :

  call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !1565

  it returns null from pCall->getCalledFunction(), and I cannot get the
function name.

  How could I get the function name in this situation?

  thanks a lot!

                                        Linhai


From criswell at illinois.edu  Wed Jan 26 14:11:42 2011
From: criswell at illinois.edu (John Criswell)
Date: Wed, 26 Jan 2011 14:11:42 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this
	situation?
In-Reply-To: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
References: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
Message-ID: <4D407FFE.1030305@illinois.edu>

On 1/26/11 2:07 PM, songlh at cs.wisc.edu wrote:
> Hi:
>
>    My llvm code is:
>
>    for( BasicBlock::iterator i = b->begin() , ie = b->end();
>         b != be ; b ++ ){
>         if( CallInst * pCall = dyn_cast<CallInst>(i)){
>
>            pCall->dump(); //
>            Function * pFunction = pCall->getCalledFunction();
>            if( !pFunction ){
>
>            }
>            std::string fname = pFunction->getName();
>         }
>    }
>
>    The dump result of the function call I want to find is :
>
>    call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !1565

This is a call using a function pointer.  There is no function name to 
retrieve.  You can check the called value (pcall->getCalledValue()) and 
see if it's something like a cast instruction that casts a constant 
function value, but that case is probably unlikely.

-- John T.

>    it returns null from pCall->getCalledFunction(), and I cannot get the
> function name.
>
>    How could I get the function name in this situation?
>
>    thanks a lot!
>
>                                          Linhai
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From songlh at cs.wisc.edu  Wed Jan 26 14:40:15 2011
From: songlh at cs.wisc.edu (songlh at cs.wisc.edu)
Date: Wed, 26 Jan 2011 14:40:15 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this
 situation?
In-Reply-To: <4D407FFE.1030305@illinois.edu>
References: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
	<4D407FFE.1030305@illinois.edu>
Message-ID: <369d1b1c61b675087655b34486721238.squirrel@webmail.cs.wisc.edu>

thanks!

After I check the ll file, I find this:

%1 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
%2 = getelementptr inbounds %struct.nsAString* %1, i32 0, i32 0, !dbg !2048
%3 = getelementptr inbounds %struct.nsISupports* %2, i32 0, i32 0, !dbg !2048
%4 = load i32 (...)*** %3, align 4, !dbg !2048
%5 = getelementptr inbounds i32 (...)** %4, i32 10, !dbg !2048
%6 = load i32 (...)** %5, align 1, !dbg !2048
%7 = bitcast i32 (...)* %6 to void (%struct.nsAString*, i32)*, !dbg !2048
%8 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !2048

The last line is the CallInst I find.

I feel it is using memory address to get the function. Is there someway I
can do this in my c++ code??

thanks a lot!

> On 1/26/11 2:07 PM, songlh at cs.wisc.edu wrote:
>> Hi:
>>
>>    My llvm code is:
>>
>>    for( BasicBlock::iterator i = b->begin() , ie = b->end();
>>         b != be ; b ++ ){
>>         if( CallInst * pCall = dyn_cast<CallInst>(i)){
>>
>>            pCall->dump(); //
>>            Function * pFunction = pCall->getCalledFunction();
>>            if( !pFunction ){
>>
>>            }
>>            std::string fname = pFunction->getName();
>>         }
>>    }
>>
>>    The dump result of the function call I want to find is :
>>
>>    call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !1565
>
> This is a call using a function pointer.  There is no function name to
> retrieve.  You can check the called value (pcall->getCalledValue()) and
> see if it's something like a cast instruction that casts a constant
> function value, but that case is probably unlikely.
>
> -- John T.
>
>>    it returns null from pCall->getCalledFunction(), and I cannot get the
>> function name.
>>
>>    How could I get the function name in this situation?
>>
>>    thanks a lot!
>>
>>                                          Linhai
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From baldrick at free.fr  Wed Jan 26 14:53:10 2011
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 26 Jan 2011 21:53:10 +0100
Subject: [LLVMdev] [LLVMDev] Where can I find the LLVM instruction to
 target	instruction transformation
In-Reply-To: <AANLkTik0E-raLp7UPjGs_kFc7p0GWDZU7UPrFK=+tiYp@mail.gmail.com>
References: <AANLkTik0E-raLp7UPjGs_kFc7p0GWDZU7UPrFK=+tiYp@mail.gmail.com>
Message-ID: <4D4089B6.8060204@free.fr>

Hi Jeff,

> Where can I find the LLVM instruction to target instruction transformation. I
> would like to see if this can be further optimized.

it starts with SelectionDAGBuilder.cpp, if I correctly understood what you are
asking.

Ciao, Duncan.

From kirk.beitz at nokia.com  Wed Jan 26 14:54:31 2011
From: kirk.beitz at nokia.com (kirk.beitz at nokia.com)
Date: Wed, 26 Jan 2011 20:54:31 +0000
Subject: [LLVMdev] building llvm :: host_os==mingw
In-Reply-To: <4F1A9F8D-21DF-4F62-B0FA-BDA90C3C0154@nokia.com>
References: <E9DF1AF9-D157-41C9-8B15-F561508F6446@nokia.com>
	<0528FCC5-501C-4BD7-B759-60D8E2E0BBDD@apple.com>
	<4F1A9F8D-21DF-4F62-B0FA-BDA90C3C0154@nokia.com>
Message-ID: <7126625D-C79E-4DAC-BB3C-B872D05D6316@nokia.com>

after digging into this further in my build logs, i saw that i did not clean up properly after a previous interim failure (due to an environment variable name collision that i resolved and attempted to re-configure, but did not properly clean up).

after a full 'make clean', the libclang .a files all appear to have been built as necessary, and i'm moving on to getting lldb to build.

++ kirk

On 2011-Jan-26, at 11:42 AM,  i wrote:

i am interested in getting lldb build using mingw (which i don't think has yet been done).

to do so requires first building llvm in order to get the depended-upon clang library, et al.

after installing mingw, i have performed the following steps, as these are what have been used to build lldb on linux (with the targets being my targets of interest):

svn co http://llvm.org/svn/llvm-project/llvm/trunk -r 123723 llvm
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/trunk -r 123723 clang
svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb
cd ..
./configure --enable-optimized --disable-assertions \
 --enable-targets=host,x86,x86_64,arm,cpp
make


upon invoking make, the following error was reported:


make[2]: Leaving directory `/x/lldb-win/tools/llvm-config'
llvm-config: unknown component name: bitreader
make[2]: Entering directory `/x/lldb-win/tools/opt'
/x/lldb-win/Makefile.rules:939: *** llvm-config --libs failed.  Stop.
make[2]: Leaving directory `/x/lldb-win/tools/opt'
make[1]: *** [opt/.makeall] Error 2
make[1]: Leaving directory `/x/lldb-win/tools'
make: *** [all] Error 1


being unfamiliar with llvm and thus where i might find a component 'bitreader', i browsed around in http://llvm.org/svn/llvm-project ; i don't see anything obvious.  i fgrep'ed for bitreader through what i did get co from svn, and i see some stuff under "bindings", and various dependencies in some of the clang Makefiles , but the source of these dependencies is not clear to me in attempting to follow the makefile tree.

i browsed the last 6 months of archives for the list, and the only messages with subject lines containing mingw seemed to involve making certain perl is part of the msys distribution.  'which perl' tells me '/bin/perl' and 'perl --version' tells me 'This is perl, v5.6.1 built for msys', so i assume i have the right thing there.

is there something else i have to check out to get the bitreader module (et al ? presuming that bitreader might not be the only unknown component, just the first encountered in the attempt to make in lldb-win/tools )?

any information or help in regard to this topic would be greatly appreciated.

++ kirk


++ kirk beitz : nokia : austin + san diego : kirk.beitz at nokia.com<mailto:kirk.beitz at nokia.com> ++



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110126/2a181831/attachment.html 

From criswell at illinois.edu  Wed Jan 26 14:55:35 2011
From: criswell at illinois.edu (John Criswell)
Date: Wed, 26 Jan 2011 14:55:35 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this
	situation?
In-Reply-To: <369d1b1c61b675087655b34486721238.squirrel@webmail.cs.wisc.edu>
References: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
	<4D407FFE.1030305@illinois.edu>
	<369d1b1c61b675087655b34486721238.squirrel@webmail.cs.wisc.edu>
Message-ID: <4D408A47.4050100@illinois.edu>

On 1/26/11 2:40 PM, songlh at cs.wisc.edu wrote:
> thanks!
>
> After I check the ll file, I find this:
>
> %1 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
> %2 = getelementptr inbounds %struct.nsAString* %1, i32 0, i32 0, !dbg !2048
> %3 = getelementptr inbounds %struct.nsISupports* %2, i32 0, i32 0, !dbg !2048
> %4 = load i32 (...)*** %3, align 4, !dbg !2048
> %5 = getelementptr inbounds i32 (...)** %4, i32 10, !dbg !2048
> %6 = load i32 (...)** %5, align 1, !dbg !2048
> %7 = bitcast i32 (...)* %6 to void (%struct.nsAString*, i32)*, !dbg !2048
> %8 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
> call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !2048
>
> The last line is the CallInst I find.
>
> I feel it is using memory address to get the function. Is there someway I
> can do this in my c++ code??

Yes, the code is loading a pointer to a function from memory and calling it.

I don't understand your question, though.

-- John T.

> thanks a lot!
>
>> On 1/26/11 2:07 PM, songlh at cs.wisc.edu wrote:
>>> Hi:
>>>
>>>     My llvm code is:
>>>
>>>     for( BasicBlock::iterator i = b->begin() , ie = b->end();
>>>          b != be ; b ++ ){
>>>          if( CallInst * pCall = dyn_cast<CallInst>(i)){
>>>
>>>             pCall->dump(); //
>>>             Function * pFunction = pCall->getCalledFunction();
>>>             if( !pFunction ){
>>>
>>>             }
>>>             std::string fname = pFunction->getName();
>>>          }
>>>     }
>>>
>>>     The dump result of the function call I want to find is :
>>>
>>>     call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !1565
>> This is a call using a function pointer.  There is no function name to
>> retrieve.  You can check the called value (pcall->getCalledValue()) and
>> see if it's something like a cast instruction that casts a constant
>> function value, but that case is probably unlikely.
>>
>> -- John T.
>>
>>>     it returns null from pCall->getCalledFunction(), and I cannot get the
>>> function name.
>>>
>>>     How could I get the function name in this situation?
>>>
>>>     thanks a lot!
>>>
>>>                                           Linhai
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>


From rich at pennware.com  Wed Jan 26 14:55:53 2011
From: rich at pennware.com (Richard Pennington)
Date: Wed, 26 Jan 2011 14:55:53 -0600
Subject: [LLVMdev] clang/LLVM cross testing environment
In-Reply-To: <AANLkTikbEObbnRsH4W50N4w8YcqfXXWcmCwwUWUJBxfx@mail.gmail.com>
References: <4D341A34.3000109@pennware.com>
	<AANLkTikbEObbnRsH4W50N4w8YcqfXXWcmCwwUWUJBxfx@mail.gmail.com>
Message-ID: <4D408A59.1050509@pennware.com>

Alex Bradbury wrote:
> This is great. I've noticed that you've made some fixes or additions
> that haven't made it upstream yet, such as the Microblaze parameter
> fix in rev 2337 (CCed Wesley Peck as he seems to have done a lot of
> work on the MBlaze stack code recently) and va_arg support for
> Microblaze in rev 2350. Do you intend to push such fixes upstream?

Hi Alex,

I have been in contact with Wesley and he has been a great help. I 
believe I've sent him all my Microblaze fixes already.
I do plan to push all the fixes upstream. I was planning to do it after 
I'd completed the library port, but since my day job has been consuming 
a lot of my time. I'll probably do it sooner. I was planning to sync 
with TOT this weekend, I'll start submitting fixes after that.

-Rich

From songlh at cs.wisc.edu  Wed Jan 26 15:00:48 2011
From: songlh at cs.wisc.edu (songlh at cs.wisc.edu)
Date: Wed, 26 Jan 2011 15:00:48 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this
 situation?
In-Reply-To: <4D408A47.4050100@illinois.edu>
References: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
	<4D407FFE.1030305@illinois.edu>
	<369d1b1c61b675087655b34486721238.squirrel@webmail.cs.wisc.edu>
	<4D408A47.4050100@illinois.edu>
Message-ID: <9fbcf1cef5bbe3116fd62ef6f86f6623.squirrel@webmail.cs.wisc.edu>

> On 1/26/11 2:40 PM, songlh at cs.wisc.edu wrote:
>> thanks!
>>
>> After I check the ll file, I find this:
>>
>> %1 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
>> %2 = getelementptr inbounds %struct.nsAString* %1, i32 0, i32 0, !dbg
>> !2048
>> %3 = getelementptr inbounds %struct.nsISupports* %2, i32 0, i32 0, !dbg
>> !2048
>> %4 = load i32 (...)*** %3, align 4, !dbg !2048
>> %5 = getelementptr inbounds i32 (...)** %4, i32 10, !dbg !2048
>> %6 = load i32 (...)** %5, align 1, !dbg !2048
>> %7 = bitcast i32 (...)* %6 to void (%struct.nsAString*, i32)*, !dbg
>> !2048
>> %8 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
>> call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !2048
>>
>> The last line is the CallInst I find.
>>
>> I feel it is using memory address to get the function. Is there someway
>> I
>> can do this in my c++ code??
>
> Yes, the code is loading a pointer to a function from memory and calling
> it.
>
> I don't understand your question, though.
>
> -- John T.
>

I mean how do I realize this in a c++ pass code?

thanks a lot!

           Linhai

>> thanks a lot!
>>
>>> On 1/26/11 2:07 PM, songlh at cs.wisc.edu wrote:
>>>> Hi:
>>>>
>>>>     My llvm code is:
>>>>
>>>>     for( BasicBlock::iterator i = b->begin() , ie = b->end();
>>>>          b != be ; b ++ ){
>>>>          if( CallInst * pCall = dyn_cast<CallInst>(i)){
>>>>
>>>>             pCall->dump(); //
>>>>             Function * pFunction = pCall->getCalledFunction();
>>>>             if( !pFunction ){
>>>>
>>>>             }
>>>>             std::string fname = pFunction->getName();
>>>>          }
>>>>     }
>>>>
>>>>     The dump result of the function call I want to find is :
>>>>
>>>>     call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !1565
>>> This is a call using a function pointer.  There is no function name to
>>> retrieve.  You can check the called value (pcall->getCalledValue()) and
>>> see if it's something like a cast instruction that casts a constant
>>> function value, but that case is probably unlikely.
>>>
>>> -- John T.
>>>
>>>>     it returns null from pCall->getCalledFunction(), and I cannot get
>>>> the
>>>> function name.
>>>>
>>>>     How could I get the function name in this situation?
>>>>
>>>>     thanks a lot!
>>>>
>>>>                                           Linhai
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>
>



From criswell at illinois.edu  Wed Jan 26 15:03:04 2011
From: criswell at illinois.edu (John Criswell)
Date: Wed, 26 Jan 2011 15:03:04 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this
	situation?
In-Reply-To: <9fbcf1cef5bbe3116fd62ef6f86f6623.squirrel@webmail.cs.wisc.edu>
References: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
	<4D407FFE.1030305@illinois.edu>
	<369d1b1c61b675087655b34486721238.squirrel@webmail.cs.wisc.edu>
	<4D408A47.4050100@illinois.edu>
	<9fbcf1cef5bbe3116fd62ef6f86f6623.squirrel@webmail.cs.wisc.edu>
Message-ID: <4D408C08.605@illinois.edu>

On 1/26/11 3:00 PM, songlh at cs.wisc.edu wrote:
>> On 1/26/11 2:40 PM, songlh at cs.wisc.edu wrote:
>>> thanks!
>>>
>>> After I check the ll file, I find this:
>>>
>>> %1 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
>>> %2 = getelementptr inbounds %struct.nsAString* %1, i32 0, i32 0, !dbg
>>> !2048
>>> %3 = getelementptr inbounds %struct.nsISupports* %2, i32 0, i32 0, !dbg
>>> !2048
>>> %4 = load i32 (...)*** %3, align 4, !dbg !2048
>>> %5 = getelementptr inbounds i32 (...)** %4, i32 10, !dbg !2048
>>> %6 = load i32 (...)** %5, align 1, !dbg !2048
>>> %7 = bitcast i32 (...)* %6 to void (%struct.nsAString*, i32)*, !dbg
>>> !2048
>>> %8 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
>>> call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !2048
>>>
>>> The last line is the CallInst I find.
>>>
>>> I feel it is using memory address to get the function. Is there someway
>>> I
>>> can do this in my c++ code??
>> Yes, the code is loading a pointer to a function from memory and calling
>> it.
>>
>> I don't understand your question, though.
>>
>> -- John T.
>>
> I mean how do I realize this in a c++ pass code?

You're still not making sense.  Are you asking what sort of C++ code 
will generate the use of a function pointer when compiled into LLVM IR, 
or are you asking how to determine, within an LLVM pass, what the 
possible target(s) of an indirect function call might be?

-- John T.

> thanks a lot!
>
>             Linhai
>
>>> thanks a lot!
>>>
>>>> On 1/26/11 2:07 PM, songlh at cs.wisc.edu wrote:
>>>>> Hi:
>>>>>
>>>>>      My llvm code is:
>>>>>
>>>>>      for( BasicBlock::iterator i = b->begin() , ie = b->end();
>>>>>           b != be ; b ++ ){
>>>>>           if( CallInst * pCall = dyn_cast<CallInst>(i)){
>>>>>
>>>>>              pCall->dump(); //
>>>>>              Function * pFunction = pCall->getCalledFunction();
>>>>>              if( !pFunction ){
>>>>>
>>>>>              }
>>>>>              std::string fname = pFunction->getName();
>>>>>           }
>>>>>      }
>>>>>
>>>>>      The dump result of the function call I want to find is :
>>>>>
>>>>>      call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !1565
>>>> This is a call using a function pointer.  There is no function name to
>>>> retrieve.  You can check the called value (pcall->getCalledValue()) and
>>>> see if it's something like a cast instruction that casts a constant
>>>> function value, but that case is probably unlikely.
>>>>
>>>> -- John T.
>>>>
>>>>>      it returns null from pCall->getCalledFunction(), and I cannot get
>>>>> the
>>>>> function name.
>>>>>
>>>>>      How could I get the function name in this situation?
>>>>>
>>>>>      thanks a lot!
>>>>>
>>>>>                                            Linhai
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>


From songlh at cs.wisc.edu  Wed Jan 26 15:06:06 2011
From: songlh at cs.wisc.edu (songlh at cs.wisc.edu)
Date: Wed, 26 Jan 2011 15:06:06 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this
 situation?
In-Reply-To: <4D408C08.605@illinois.edu>
References: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
	<4D407FFE.1030305@illinois.edu>
	<369d1b1c61b675087655b34486721238.squirrel@webmail.cs.wisc.edu>
	<4D408A47.4050100@illinois.edu>
	<9fbcf1cef5bbe3116fd62ef6f86f6623.squirrel@webmail.cs.wisc.edu>
	<4D408C08.605@illinois.edu>
Message-ID: <cebc8c07ba977befd50e9e0dcda68835.squirrel@webmail.cs.wisc.edu>

> On 1/26/11 3:00 PM, songlh at cs.wisc.edu wrote:
>>> On 1/26/11 2:40 PM, songlh at cs.wisc.edu wrote:
>>>> thanks!
>>>>
>>>> After I check the ll file, I find this:
>>>>
>>>> %1 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
>>>> %2 = getelementptr inbounds %struct.nsAString* %1, i32 0, i32 0, !dbg
>>>> !2048
>>>> %3 = getelementptr inbounds %struct.nsISupports* %2, i32 0, i32 0,
>>>> !dbg
>>>> !2048
>>>> %4 = load i32 (...)*** %3, align 4, !dbg !2048
>>>> %5 = getelementptr inbounds i32 (...)** %4, i32 10, !dbg !2048
>>>> %6 = load i32 (...)** %5, align 1, !dbg !2048
>>>> %7 = bitcast i32 (...)* %6 to void (%struct.nsAString*, i32)*, !dbg
>>>> !2048
>>>> %8 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048
>>>> call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !2048
>>>>
>>>> The last line is the CallInst I find.
>>>>
>>>> I feel it is using memory address to get the function. Is there
>>>> someway
>>>> I
>>>> can do this in my c++ code??
>>> Yes, the code is loading a pointer to a function from memory and
>>> calling
>>> it.
>>>
>>> I don't understand your question, though.
>>>
>>> -- John T.
>>>
>> I mean how do I realize this in a c++ pass code?
>
> You're still not making sense.  Are you asking what sort of C++ code
> will generate the use of a function pointer when compiled into LLVM IR,
> or are you asking how to determine, within an LLVM pass, what the
> possible target(s) of an indirect function call might be?
>
> -- John T.

Sorry, I am asking the second question.
"
how to determine, within an LLVM pass, what the
possible target(s) of an indirect function call might be?
"

thanks a lot!

Linhai
>
>> thanks a lot!
>>
>>             Linhai
>>
>>>> thanks a lot!
>>>>
>>>>> On 1/26/11 2:07 PM, songlh at cs.wisc.edu wrote:
>>>>>> Hi:
>>>>>>
>>>>>>      My llvm code is:
>>>>>>
>>>>>>      for( BasicBlock::iterator i = b->begin() , ie = b->end();
>>>>>>           b != be ; b ++ ){
>>>>>>           if( CallInst * pCall = dyn_cast<CallInst>(i)){
>>>>>>
>>>>>>              pCall->dump(); //
>>>>>>              Function * pFunction = pCall->getCalledFunction();
>>>>>>              if( !pFunction ){
>>>>>>
>>>>>>              }
>>>>>>              std::string fname = pFunction->getName();
>>>>>>           }
>>>>>>      }
>>>>>>
>>>>>>      The dump result of the function call I want to find is :
>>>>>>
>>>>>>      call void %7(%struct.nsAString* %8, i32 0) nounwind, !dbg !1565
>>>>> This is a call using a function pointer.  There is no function name
>>>>> to
>>>>> retrieve.  You can check the called value (pcall->getCalledValue())
>>>>> and
>>>>> see if it's something like a cast instruction that casts a constant
>>>>> function value, but that case is probably unlikely.
>>>>>
>>>>> -- John T.
>>>>>
>>>>>>      it returns null from pCall->getCalledFunction(), and I cannot
>>>>>> get
>>>>>> the
>>>>>> function name.
>>>>>>
>>>>>>      How could I get the function name in this situation?
>>>>>>
>>>>>>      thanks a lot!
>>>>>>
>>>>>>                                            Linhai
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>
>



From criswell at illinois.edu  Wed Jan 26 15:15:32 2011
From: criswell at illinois.edu (John Criswell)
Date: Wed, 26 Jan 2011 15:15:32 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this
	situation?
In-Reply-To: <cebc8c07ba977befd50e9e0dcda68835.squirrel@webmail.cs.wisc.edu>
References: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
	<4D407FFE.1030305@illinois.edu>
	<369d1b1c61b675087655b34486721238.squirrel@webmail.cs.wisc.edu>
	<4D408A47.4050100@illinois.edu>
	<9fbcf1cef5bbe3116fd62ef6f86f6623.squirrel@webmail.cs.wisc.edu>
	<4D408C08.605@illinois.edu>
	<cebc8c07ba977befd50e9e0dcda68835.squirrel@webmail.cs.wisc.edu>
Message-ID: <4D408EF4.6060407@illinois.edu>

On 1/26/11 3:06 PM, songlh at cs.wisc.edu wrote:
>> [snip]
>> -- John T.
> Sorry, I am asking the second question.
> "
> how to determine, within an LLVM pass, what the
> possible target(s) of an indirect function call might be?

There are at least two solutions.

The first is to use the CallGraph analysis pass.  It constructs a 
conservative call graph, meaning that any indirect function call is 
assumed to call any address-taken function.  For some applications, this 
is good enough, and for others, it isn't.

If you need more precise results, you can use DSA.  It is part of the 
poolalloc project.  It is a points-to analysis that attempts to build a 
more accurate call-graph.  In some cases, it probably works well; in 
other cases, it may not do any better than the LLVM CallGraph analysis.

You can get DSA by doing the following check-out:

svn co https://llvm.org/svn/llvm-project/poolalloc/trunk poolalloc

Directions on configuring it and examples of how to use it can be found 
in the SAFECode project: http://safecode.cs.illinois.edu.

If you want to use DSA, please let me know, and I can point you to an 
example in SAFECode or the Poolalloc source code that uses the 
DSCallGraph interface.

-- John T.

> "
>
> thanks a lot!
>
> Linhai
>>


From songlh at cs.wisc.edu  Wed Jan 26 15:28:10 2011
From: songlh at cs.wisc.edu (songlh at cs.wisc.edu)
Date: Wed, 26 Jan 2011 15:28:10 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this
 situation?
In-Reply-To: <4D408EF4.6060407@illinois.edu>
References: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
	<4D407FFE.1030305@illinois.edu>
	<369d1b1c61b675087655b34486721238.squirrel@webmail.cs.wisc.edu>
	<4D408A47.4050100@illinois.edu>
	<9fbcf1cef5bbe3116fd62ef6f86f6623.squirrel@webmail.cs.wisc.edu>
	<4D408C08.605@illinois.edu>
	<cebc8c07ba977befd50e9e0dcda68835.squirrel@webmail.cs.wisc.edu>
	<4D408EF4.6060407@illinois.edu>
Message-ID: <10f303e08f74b12b683c7edf86b50693.squirrel@webmail.cs.wisc.edu>

> On 1/26/11 3:06 PM, songlh at cs.wisc.edu wrote:
>>> [snip]
>>> -- John T.
>> Sorry, I am asking the second question.
>> "
>> how to determine, within an LLVM pass, what the
>> possible target(s) of an indirect function call might be?
>
> There are at least two solutions.
>
> The first is to use the CallGraph analysis pass.  It constructs a
> conservative call graph, meaning that any indirect function call is
> assumed to call any address-taken function.  For some applications, this
> is good enough, and for others, it isn't.
>
> If you need more precise results, you can use DSA.  It is part of the
> poolalloc project.  It is a points-to analysis that attempts to build a
> more accurate call-graph.  In some cases, it probably works well; in
> other cases, it may not do any better than the LLVM CallGraph analysis.
>
> You can get DSA by doing the following check-out:
>
> svn co https://llvm.org/svn/llvm-project/poolalloc/trunk poolalloc
>
> Directions on configuring it and examples of how to use it can be found
> in the SAFECode project: http://safecode.cs.illinois.edu.
>
> If you want to use DSA, please let me know, and I can point you to an
> example in SAFECode or the Poolalloc source code that uses the
> DSCallGraph interface.
>
> -- John T.
>

Could you please point me the DSA example in poolalloc project? I just
check that code out.

Thanks a lot!

linhai

>> "
>>
>> thanks a lot!
>>
>> Linhai
>>>
>
>



From criswell at illinois.edu  Wed Jan 26 15:33:06 2011
From: criswell at illinois.edu (John Criswell)
Date: Wed, 26 Jan 2011 15:33:06 -0600
Subject: [LLVMdev] [LLVMDEV]How could I get function name in this
 situation?
In-Reply-To: <10f303e08f74b12b683c7edf86b50693.squirrel@webmail.cs.wisc.edu>
References: <21b4e022d059ebdab16948d65456dbc5.squirrel@webmail.cs.wisc.edu>
	<4D407FFE.1030305@illinois.edu>
	<369d1b1c61b675087655b34486721238.squirrel@webmail.cs.wisc.edu>
	<4D408A47.4050100@illinois.edu>
	<9fbcf1cef5bbe3116fd62ef6f86f6623.squirrel@webmail.cs.wisc.edu>
	<4D408C08.605@illinois.edu>
	<cebc8c07ba977befd50e9e0dcda68835.squirrel@webmail.cs.wisc.edu>
	<4D408EF4.6060407@illinois.edu>
	<10f303e08f74b12b683c7edf86b50693.squirrel@webmail.cs.wisc.edu>
Message-ID: <4D409312.7050208@illinois.edu>

On 1/26/11 3:28 PM, songlh at cs.wisc.edu wrote:
>> On 1/26/11 3:06 PM, songlh at cs.wisc.edu wrote:
>>>> [snip]
>>>> -- John T.
>>> Sorry, I am asking the second question.
>>> "
>>> how to determine, within an LLVM pass, what the
>>> possible target(s) of an indirect function call might be?
>> There are at least two solutions.
>>
>> The first is to use the CallGraph analysis pass.  It constructs a
>> conservative call graph, meaning that any indirect function call is
>> assumed to call any address-taken function.  For some applications, this
>> is good enough, and for others, it isn't.
>>
>> If you need more precise results, you can use DSA.  It is part of the
>> poolalloc project.  It is a points-to analysis that attempts to build a
>> more accurate call-graph.  In some cases, it probably works well; in
>> other cases, it may not do any better than the LLVM CallGraph analysis.
>>
>> You can get DSA by doing the following check-out:
>>
>> svn co https://llvm.org/svn/llvm-project/poolalloc/trunk poolalloc
>>
>> Directions on configuring it and examples of how to use it can be found
>> in the SAFECode project: http://safecode.cs.illinois.edu.
>>
>> If you want to use DSA, please let me know, and I can point you to an
>> example in SAFECode or the Poolalloc source code that uses the
>> DSCallGraph interface.
>>
>> -- John T.
>>
> Could you please point me the DSA example in poolalloc project? I just
> check that code out.

Line 914 of lib/PoolAllocate/TransformFunctionBody.cpp.  You basically 
get the DSGraph of the function, then get the DSCallGraph from the 
DSGraph, and then query the DSCallGraph for the call instruction.

Note that you should use dsa-td (the Top-Down DSA pass).

-- John T.

> Thanks a lot!
>
> linhai
>
>>> "
>>>
>>> thanks a lot!
>>>
>>> Linhai
>>
>


From haohui.mai at gmail.com  Wed Jan 26 18:21:34 2011
From: haohui.mai at gmail.com (Haohui Mai)
Date: Wed, 26 Jan 2011 18:21:34 -0600
Subject: [LLVMdev] Missing some passes in llvm-ld
In-Reply-To: <8285a75e191c231030f87197aee5ac54.squirrel@webmail.cs.wisc.edu>
References: <89e0944507495fc8eb3f14dae3633306.squirrel@webmail.cs.wisc.edu>
	<4D34D996.1030806@mxc.ca>
	<7221226ddb884b77fdf4c4525421299c.squirrel@webmail.cs.wisc.edu>
	<4D351751.1030607@illinois.edu>
	<8285a75e191c231030f87197aee5ac54.squirrel@webmail.cs.wisc.edu>
Message-ID: <4FEB04A6-E925-4B14-BE82-9FD2F81CAAC2@gmail.com>

Hi All,

It seems that I can't force some passes to run in llvm-ld as what I can do with opt.

$ ~/opt/bin/llvm-ld -reassociate
llvm-ld: Unknown command line argument '-reassociate.  Try: 'opt/bin/llvm-ld -help'

llvm-ld definitely linked with scalaropts, and RegisterPass<ReassociatePass> is in the library.

Running with these passes with opt definitely work, but it'll take some time as my .bc is big (~40M).

I'll appreciate any ideas how to make llvm-ld run these passes.

Thanks.

Cheers,
Haohui

From vmle at ucdavis.edu  Wed Jan 26 18:50:14 2011
From: vmle at ucdavis.edu (Vu Le)
Date: Wed, 26 Jan 2011 16:50:14 -0800
Subject: [LLVMdev] Update PHINode after extracting code
In-Reply-To: <AANLkTinORMUXaPcECi+=756vkKAm2fzHeQC=Ssusg6k1@mail.gmail.com>
References: <AANLkTinORMUXaPcECi+=756vkKAm2fzHeQC=Ssusg6k1@mail.gmail.com>
Message-ID: <AANLkTinoReGZhmJJN40F+kUE_mwPzcdOK5BTdx=LemnS@mail.gmail.com>

I guess I didn't have a clear question.

Suppose we have BB1 and BB2 both point to BB3.
BB1 has variable x. BB2 also as variable x.
BB3 will have PHINode for x with 2 value from BB1 and BB2.
BB1   BB2
   \       /
     BB3

Now if BB1 and BB2 is extracted into a function
(using ExtractCodeRegion), they will be replaced by
a basic block called codeRepl (which has a call to the extracted
function).
codeRepl
     |
    BB3

The problem is that the PHINode in BB3 still has 2 values x,
both from codeRepl. That's wrong because BB3 has only 1 successors,
which is codeRepl. In fact, there is NO way to update PhiNode,
because all the x are from ONE node, codeRepl.
So the function ExtractCodeRegion doesn't work in this example.

My solution for this is before extracting BB1 and BB2, I split the PHINode
in BB3 into another basic block
BB1   BB2
   \       /
   PhiBB
       |
      BB
And extract BB1, BB2 and PhiBB.
If you have any ideas or if you think this will not work, please let me
know.
Thanks.
Vu


On Tue, Jan 25, 2011 at 12:33 AM, Vu Le <vmle at ucdavis.edu> wrote:

> Hi all,
> I have problem with ExtractCodeRegion (CodeExtractor.cpp).
> My original program is as follows.
> bb:
>   ...
>   %tmp.15 = load %struct.MYSQL_ROWS** %3, align 4
>   ...
> bb1:
>   ...
>   %tmp.1 = load %struct.MYSQL_ROWS** %6, align 4
>   ...
> bb4:                                              ; preds = %bb1, %bb,
> %entry
>   %tmp.0 = phi %struct.MYSQL_ROWS* [ null, %entry ], [ %tmp.15, %bb ], [
> %tmp.1, %bb1 ]
>
> %tmp.0 is the PHINode whose value is from entry, bb and bb1.
> After extracting bb and bb1 into new function, the program becomes
>
> codeRepl:                                         ; preds = %entry
>   call void @mysql_data_seek_bb(%struct.MYSQL_DATA* %1, i64 %row,
> %struct.MYSQL_ROWS** %tmp.15.loc, %struct.MYSQL_ROWS** %tmp.1.loc)
> *  %tmp.15.reload = load %struct.MYSQL_ROWS** %tmp.15.loc
>   %tmp.1.reload = load %struct.MYSQL_ROWS** %tmp.1.loc
> *  br label %bb4
>
> bb4:                                              ; preds = %codeRepl,
> %entry
> *  %tmp.0 = phi %struct.MYSQL_ROWS* [ null, %entry ], [ %tmp.15.reload,
> %codeRepl ], [ %tmp.1.reload, %codeRepl ]
>
> *bb4 now has only 2 predecessors since bb and bb1 are replaced by
> codeRepl.
> The PHINode in bb4, on the other hand, still has 3 incoming values and that
> make the assertion failed.
> I do want to extract this code region into function. Does anyone have a
> solution for this?
> Thanks a lot.
> Vu
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110126/b66106fb/attachment.html 

From grosser at fim.uni-passau.de  Wed Jan 26 21:26:26 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Wed, 26 Jan 2011 22:26:26 -0500
Subject: [LLVMdev] Update PHINode after extracting code
In-Reply-To: <AANLkTinoReGZhmJJN40F+kUE_mwPzcdOK5BTdx=LemnS@mail.gmail.com>
References: <AANLkTinORMUXaPcECi+=756vkKAm2fzHeQC=Ssusg6k1@mail.gmail.com>
	<AANLkTinoReGZhmJJN40F+kUE_mwPzcdOK5BTdx=LemnS@mail.gmail.com>
Message-ID: <4D40E5E2.6010609@fim.uni-passau.de>

On 01/26/2011 07:50 PM, Vu Le wrote:
> I guess I didn't have a clear question.
>
> Suppose we have BB1 and BB2 both point to BB3.
> BB1 has variable x. BB2 also as variable x.
> BB3 will have PHINode for x with 2 value from BB1 and BB2.
> BB1   BB2
>     \       /
>       BB3
>
> Now if BB1 and BB2 is extracted into a function
> (using ExtractCodeRegion), they will be replaced by
> a basic block called codeRepl (which has a call to the extracted
> function).
> codeRepl
>       |
>      BB3
>
> The problem is that the PHINode in BB3 still has 2 values x,
> both from codeRepl. That's wrong because BB3 has only 1 successors,
> which is codeRepl. In fact, there is NO way to update PhiNode,
> because all the x are from ONE node, codeRepl.
> So the function ExtractCodeRegion doesn't work in this example.
>
> My solution for this is before extracting BB1 and BB2, I split the PHINode
> in BB3 into another basic block
> BB1   BB2
>     \       /
>     PhiBB
>         |
>        BB
> And extract BB1, BB2 and PhiBB.
> If you have any ideas or if you think this will not work, please let me
> know.
> Thanks.
> Vu

Hi Vu,

I believe this is the right approach. If I am right and you work on the 
RegionInfo pass I believe what you want is only to extract so called 
simpleRegions that have just a single entry and exit edge.

Have a look at the email from Andreas Simbuerger two weeks ago:

[llvm-commits] [PATCH] Add SeSeRegionInfo transform pass

This should contain the functions needed to transform a refined region 
into a simple region. Either we get this patch committed and you could 
just use this pass or we add the corresponding functions to RegionInfo 
and you translate just the regions that you finally will extract.

Cheers
Tobi

From rgomes1997 at yahoo.co.uk  Wed Jan 26 23:33:11 2011
From: rgomes1997 at yahoo.co.uk (Richard Gomes)
Date: Thu, 27 Jan 2011 05:33:11 +0000
Subject: [LLVMdev] Newbie question on Clang
Message-ID: <4D410397.9090402@yahoo.co.uk>

Hi ALL,

This is my first post here.
I'd like to ask for directions in regards to Clang.

This is what I'd like to do:

I'd like to extract function prototypes from a large C++ code base.
I dont need to generate code for any target platform; I just need 
function prototypes.

I know I can use ctags, like this:

     find ~/sources/cpp-library -name '*.*pp' > files.lst
     ctags -x --c++-kinds=pf --language-force=c++ -h .hpp -L files.lst

... but the output is not very convenient, because ctags only does a 
textual extraction.

Ideally, I'd like to extract information from the AST so that all 
typedefs and template types would be already resolved. Something like this:


class C
	double function
		double argument
	double operator+
		double op


Note: any recommendation in regards to typedefs and templates?


My aim is (later!) to do more or less the same with a large Java library 
and compare output of these two things, so that I can guarantee that the 
Java library implements properly the C++ APIs.

Any help is much appreciated.

Thanks a lot :)

-- 
Richard Gomes
http://www.jquantlib.org/index.php/User:RichardGomes
twitter: frgomes

JQuantLib is a library for Quantitative Finance written in Java.
http://www.jquantlib.com/
twitter: jquantlib

From vmle at ucdavis.edu  Wed Jan 26 23:48:28 2011
From: vmle at ucdavis.edu (Vu Le)
Date: Wed, 26 Jan 2011 21:48:28 -0800
Subject: [LLVMdev] Update PHINode after extracting code
In-Reply-To: <4D40E5E2.6010609@fim.uni-passau.de>
References: <AANLkTinORMUXaPcECi+=756vkKAm2fzHeQC=Ssusg6k1@mail.gmail.com>
	<AANLkTinoReGZhmJJN40F+kUE_mwPzcdOK5BTdx=LemnS@mail.gmail.com>
	<4D40E5E2.6010609@fim.uni-passau.de>
Message-ID: <AANLkTintk2HDnm5CTFR-05yEjaWa7pCuZ9oxJ080OwZJ@mail.gmail.com>

Hi Tobias,
If the PHI node at exit block of region R has multiple inputs from the R,
I split the exit block into 2.
The first block contains all PHI nodes whose input are all from the region.
The second is the new exit node.

All branches (outside R) to the old exit now point the new exit.
All regions whose exit is the old exit are also updated with the new exit
node.

It works like a charm.
Thanks.
Vu
On Wed, Jan 26, 2011 at 7:26 PM, Tobias Grosser
<grosser at fim.uni-passau.de>wrote:

> On 01/26/2011 07:50 PM, Vu Le wrote:
>
>> I guess I didn't have a clear question.
>>
>> Suppose we have BB1 and BB2 both point to BB3.
>> BB1 has variable x. BB2 also as variable x.
>> BB3 will have PHINode for x with 2 value from BB1 and BB2.
>> BB1   BB2
>>    \       /
>>      BB3
>>
>> Now if BB1 and BB2 is extracted into a function
>> (using ExtractCodeRegion), they will be replaced by
>> a basic block called codeRepl (which has a call to the extracted
>> function).
>> codeRepl
>>      |
>>     BB3
>>
>> The problem is that the PHINode in BB3 still has 2 values x,
>> both from codeRepl. That's wrong because BB3 has only 1 successors,
>> which is codeRepl. In fact, there is NO way to update PhiNode,
>> because all the x are from ONE node, codeRepl.
>> So the function ExtractCodeRegion doesn't work in this example.
>>
>> My solution for this is before extracting BB1 and BB2, I split the PHINode
>> in BB3 into another basic block
>> BB1   BB2
>>    \       /
>>    PhiBB
>>        |
>>       BB
>> And extract BB1, BB2 and PhiBB.
>> If you have any ideas or if you think this will not work, please let me
>> know.
>> Thanks.
>> Vu
>>
>
> Hi Vu,
>
> I believe this is the right approach. If I am right and you work on the
> RegionInfo pass I believe what you want is only to extract so called
> simpleRegions that have just a single entry and exit edge.
>
> Have a look at the email from Andreas Simbuerger two weeks ago:
>
> [llvm-commits] [PATCH] Add SeSeRegionInfo transform pass
>
> This should contain the functions needed to transform a refined region into
> a simple region. Either we get this patch committed and you could just use
> this pass or we add the corresponding functions to RegionInfo and you
> translate just the regions that you finally will extract.
>
> Cheers
> Tobi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110126/5d76bad3/attachment-0001.html 

From grosser at fim.uni-passau.de  Thu Jan 27 00:10:48 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Thu, 27 Jan 2011 01:10:48 -0500
Subject: [LLVMdev] Update PHINode after extracting code
In-Reply-To: <AANLkTintk2HDnm5CTFR-05yEjaWa7pCuZ9oxJ080OwZJ@mail.gmail.com>
References: <AANLkTinORMUXaPcECi+=756vkKAm2fzHeQC=Ssusg6k1@mail.gmail.com>	<AANLkTinoReGZhmJJN40F+kUE_mwPzcdOK5BTdx=LemnS@mail.gmail.com>	<4D40E5E2.6010609@fim.uni-pa